Por que é que o Jellyfin faz buffering num servidor doméstico?

O Jellyfin faz buffering quando uma parte do caminho de reprodução não consegue entregar, converter ou decodificar vídeo mais rápido do que o avanço da linha temporal. A transcodificação de vídeo é uma causa comum, mas não é a única. Um fluxo também pode parar devido a limites do codec do cliente, processamento de legendas, Wi-Fi instável, largura de banda insuficiente para upload remoto, contenção de armazenamento ou um diretório de transcodificação que não pode aceitar mais dados temporários.

A forma mais rápida de encontrar o gargalo é verificar o modo de reprodução atual antes de alterar as configurações de hardware. Depois, compare se o problema afeta todos os ficheiros, apenas mídia 4K ou HDR, um cliente, utilizadores remotos, reprodução com legendas ativadas ou várias transmissões simultâneas.

Verifique o Modo de Reprodução Antes de Alterar Qualquer Coisa

Abra o Painel do Jellyfin enquanto o vídeo afetado está a ser reproduzido e inspecione a sessão ativa. Isto estabelece se o servidor está a entregar o ficheiro original ou a converter ativamente parte dele.

O Jellyfin separa a reprodução em quatro caminhos de reprodução com carga progressivamente maior no servidor: Direct Play, Remux, Direct Stream e Transcode de vídeo. O Direct Play envia a mídia original com quase nenhum processamento. O Remux altera o contentor, o Direct Stream converte o áudio preservando o vídeo, e o Transcode reencoda o fluxo de vídeo.

Este primeiro resultado altera toda a direção da resolução de problemas. Se o Direct Play fizer buffering, comece pela rede, armazenamento, cliente e ficheiro de mídia. Se a transcodificação de vídeo fizer buffering, verifique por que foi solicitada a conversão e se o servidor consegue completar todo o processo rapidamente.

Descubra Por Que o Jellyfin Solicitou uma Transcodificação

Um ficheiro não faz Direct Play apenas porque o cliente suporta o seu codec de vídeo. O Jellyfin avalia a combinação completa de contentor, codec de vídeo, perfil do codec, profundidade de bits, resolução, formato de áudio, disposição dos canais, legendas, taxa de bits e restrições de reprodução do cliente.

Por exemplo, o cliente pode suportar vídeo HEVC mas não a faixa de áudio TrueHD incluída. Outro cliente pode decodificar ambos os fluxos mas falhar ao renderizar o formato de legenda selecionado. Essas diferenças podem transformar o mesmo ficheiro em Reprodução Direta num dispositivo, conversão de áudio noutro e transcodificação completa de vídeo num navegador.

Registe a razão da reprodução antes de alterar as definições. Teste também outra faixa de áudio, desative as legendas e reproduza o mesmo ficheiro através de outro cliente Jellyfin. Estes testes controlados são mais úteis do que ativar todas as caixas de codecs no menu de transcodificação.

A Transcodificação por Software Pode Sobrecarregar um Servidor Pequeno

A transcodificação por software usa a CPU para decodificar a fonte, aplicar filtros, redimensionar a imagem e codificar um novo fluxo em tempo real. Um processador de baixa potência pode lidar com uma conversão 1080p, mas falhar quando a fonte é vídeo 4K HEVC, 10 bits ou HDR.

Quando a conversão não consegue manter-se à frente da reprodução, o cliente acaba por consumir os segmentos de vídeo em buffer e pausa. O uso da CPU pode permanecer próximo do máximo enquanto o Jellyfin tenta repetidamente construir dados suficientes à frente da posição atual.

Se o servidor tiver uma GPU integrada ou dedicada suportada, a aceleração de hardware corretamente configurada é geralmente mais útil do que alterar o número de threads do FFmpeg. Se o servidor não tiver um codificador compatível, reduzir a resolução ou a taxa de bits solicitada pode confirmar que a capacidade de transcodificação é o fator limitante.

A Aceleração de Hardware é um Processo em Várias Etapas

Selecionar Intel Quick Sync, VA-API, NVIDIA NVENC ou AMD AMF no Painel não garante que todas as partes da conversão sejam executadas na GPU.

Uma transcodificação Jellyfin pode incluir decodificação, desentrelaçamento, redimensionamento, conversão de formato, mapeamento de tom HDR, incorporação de legendas e codificação. O Jellyfin nota que algumas etapas podem permanecer na CPU devido a limitações de hardware, driver ou software. A aceleração parcial pode, portanto, produzir um uso elevado da CPU mesmo quando a atividade da GPU é visível.

Verifique o trabalho completo em vez de apenas a presença de uma GPU. Force uma transcodificação previsível, observe os motores de decodificação e codificação de vídeo, inspecione o comando FFmpeg e procure filtros que tenham revertido para software.

Não Ative Formatos de Decodificação que a Sua GPU Não Suporta

A página de aceleração de hardware permite aos administradores selecionar formatos de vídeo que o Jellyfin pode tentar decodificar através da GPU. Ativar um formato não suportado não adiciona essa capacidade ao hardware.

Se a GPU não conseguir decodificar o perfil exato do codec ou a profundidade de bits, o Jellyfin pode recorrer à decodificação por software ou falhar na inicialização do caminho de hardware. É por isso que um ficheiro HEVC pode funcionar enquanto outro causa um uso inesperadamente elevado da CPU.

Confirme a geração da GPU e os perfis suportados, depois ative apenas os formatos que ela pode realmente processar. Teste ficheiros comuns H.264, HEVC Main 10 e HDR separadamente em vez de tratar todos os media 4K como uma única carga de trabalho.

O Docker Deve Ter Acesso à GPU

Uma GPU detetada pelo sistema operativo anfitrião não está automaticamente disponível dentro de um contentor Jellyfin. O contentor também precisa do mapeamento correto do dispositivo, runtime, drivers, grupos e permissões.

Para GPUs Intel e AMD no Linux, o anfitrião normalmente expõe dispositivos de renderização em /dev/dri. O utilizador do contentor deve poder aceder ao dispositivo de renderização relevante. As configurações NVIDIA requerem o driver do anfitrião e um runtime de contentor apropriado. Verificações práticas do Docker incluem verificar o dispositivo de renderização, mapeá-lo no contentor e adicionar o GID correto do grupo de renderização.

Não deixe o contentor em modo privilegiado como solução permanente. Pode ser usado brevemente para confirmar que o problema subjacente é o acesso ao dispositivo, mas a implementação final deve expor apenas os recursos e permissões da GPU necessários.

Verifique a Atividade da GPU Durante uma Transcodificação Real

O arranque bem-sucedido de um contentor não prova que a transcodificação por hardware funciona. O Jellyfin pode funcionar normalmente, digitalizar a biblioteca e reproduzir ficheiros diretamente enquanto não tem acesso utilizável à GPU.

Force uma transcodificação escolhendo temporariamente uma qualidade de cliente inferior à da fonte. Nos sistemas Intel, monitorize os motores de vídeo com uma ferramenta como intel_gpu_topNos sistemas NVIDIA, inspecione os processos ativos e a atividade do codificador através de nvidia-smiVerifique também se o uso da CPU diminui em comparação com a transcodificação por software.

Se não houver atividade da GPU, confirme o dispositivo mapeado, o utilizador do contentor, a pertença ao grupo de renderização, o método de aceleração de hardware e o registo do FFmpeg. Se a GPU estiver ativa mas a reprodução continuar lenta, outra etapa do pipeline pode ainda estar a ser executada em software.

As Legendas Podem Desencadear Uma Transcodificação Completa de Vídeo

Um sintoma comum é a reprodução suave até as legendas serem ativadas. Isto ocorre frequentemente com legendas baseadas em imagem ou formatos estilizados que o cliente selecionado não consegue renderizar diretamente.

Quando o Jellyfin tem de queimar as legendas na imagem, decodifica cada frame, renderiza a camada de legendas e codifica um novo fluxo de vídeo. Isso pode transformar uma sessão Direct Play de baixa carga numa das vias de reprodução mais dispendiosas do servidor.

Desative as legendas e reproduza a mesma cena. Se o buffering desaparecer, experimente uma faixa de legendas baseada em texto como SRT, teste outro cliente ou verifique se o caminho de hardware selecionado pode acelerar as operações de decodificação, filtragem e codificação envolventes.

O Tone Mapping HDR Pode Ser Mais Exigente Que a Transcodificação Normal

Se media 1080p e 4K SDR comum reproduzirem corretamente mas o conteúdo HDR fizer buffering num cliente SDR, o tone mapping é um forte candidato.

O servidor pode precisar decodificar uma fonte HDR de 10 bits, converter a sua gama de cor e brilho para SDR, escalá-la e codificar um novo fluxo de vídeo. Um sistema capaz de transcodificação normal H.264 pode ainda ser incapaz de realizar essa carga de trabalho completa em tempo real através de software.

Teste o mesmo ficheiro HDR num cliente com capacidade HDR, depois force uma transcodificação SDR e compare a atividade da CPU e GPU. O suporte de hardware para decodificação HEVC não prova automaticamente que o método de tone-mapping selecionado está totalmente acelerado.

O Cliente Determina Grande Parte do Caminho de Reprodução

O Jellyfin pode fazer Direct Play de um ficheiro num cliente de media de ambiente de trabalho enquanto o transcodifica numa aplicação de navegador ou televisão. Essa diferença não significa que a configuração do servidor mudou entre sessões.

Cada cliente reporta os codecs, contentores, formatos de áudio, legendas, resoluções e limites de bitrate suportados. Um leitor mais capaz pode evitar a conversão, enquanto um leitor restrito pode exigir conversão de áudio, remuxing ou transcodificação completa de vídeo.

Teste o mesmo ficheiro, faixa de áudio, faixa de legendas e ligação de rede em dois clientes. Se o problema seguir um cliente, investigue as capacidades de reprodução desse dispositivo e as definições da aplicação antes de modificar o servidor.

O Direct Play Pode Ainda Fazer Buffering

O Direct Play elimina a conversão de vídeo como o principal gargalo, mas não prova que todas as outras partes do caminho estão a funcionar corretamente.

O NAS ainda tem de ler o media, a rede deve entregá-lo continuamente, e o cliente deve decodificar e reproduzi-lo. Picos de bitrate elevados, Wi-Fi instável, uma interface de cliente lenta, tentativas de erro de armazenamento ou um leitor com pouca potência podem interromper um fluxo direto que seria de outra forma contínuo.

Copie o ficheiro problemático para o cliente e reproduza-o localmente. Se a reprodução local também falhar, investigue o ficheiro media ou o decodificador do cliente. Se a cópia local funcionar enquanto o Jellyfin Direct Play faz buffering, concentre-se na rede e no caminho de armazenamento do servidor.

Teste o caminho real da LAN em vez de um teste de velocidade de internet

Um resultado rápido de internet não mede o caminho do servidor Jellyfin até uma televisão, telefone ou box de streaming dentro de casa. Também não revela jitter do Wi-Fi, perda de pacotes, congestionamento do backhaul da rede mesh ou uma interface de dispositivo lenta.

Um diagnóstico local útil compara a taxa de transferência sustentada de cópia de ficheiros, um cliente com ligação por cabo, uma codificação com taxa de bits inferior e o ficheiro original de alta taxa de bits. Verificações práticas de streaming local também incluem testar Ethernet, verificar se o cliente está a forçar uma transcodificação e mover tarefas pesadas em segundo plano para fora do horário de visualização.

Procure desempenho sustentado em vez do valor mais alto mostrado por alguns segundos. Vídeo com picos grandes de taxa de bits precisa de margem suficiente para sobreviver a pequenas lentidões na rede sem esgotar o buffer do cliente.

O buffering remoto geralmente tem uma causa diferente

Se o mesmo media reproduz corretamente em casa, mas faz buffering através de uma ligação externa, a largura de banda de upload do servidor e a rota remota tornam-se os principais suspeitos.

A taxa utilizável é limitada pela velocidade de upload da ligação doméstica, pela velocidade de download do cliente remoto, pela sobrecarga do VPN ou proxy reverso, pelo tráfego concorrente na casa e pela taxa de bits do fluxo. Um grande remux pode exceder a capacidade de upload disponível, mesmo que reproduza diretamente perfeitamente na LAN.

Reduza temporariamente a qualidade de reprodução remota. Se isso resolver o buffering, defina uma taxa de bits remota sustentável ou use transcodificação por hardware para criar um fluxo menor. Considere a configuração inferior como evidência de um limite de largura de banda, não como prova de que o ficheiro original está defeituoso.

O armazenamento é mais propenso a falhar sob trabalho concorrente

Um disco rígido saudável geralmente consegue ler um fluxo de filme comum sem dificuldade. O armazenamento torna-se mais suspeito quando a reprodução se sobrepõe a downloads, backups, varreduras de biblioteca, geração de miniaturas, operações de paridade, verificações ou vários utilizadores.

Essas tarefas criam leituras, gravações e buscas concorrentes. Um disco pode mostrar uma velocidade sequencial aceitável num teste de desempenho, mas ainda assim desenvolver alta latência sob atividade mista.

Monitorize a utilização e a latência enquanto ocorre o armazenamento em buffer. Pause downloads e trabalhos de manutenção, depois reproduza o mesmo ficheiro novamente. Mantenha a base de dados, metadados e cache do Jellyfin em armazenamento de menor latência sempre que possível, enquanto ficheiros de media grandes podem permanecer em discos orientados para capacidade.

Um Diretório de Transcodificação Cheio Pode Parar a Reprodução

O vídeo transcodificado é escrito como segmentos temporários antes de ser consumido pelo cliente. Se o sistema de ficheiros, SSD, disco RAM ou volume Docker atribuído tiver espaço livre insuficiente, o FFmpeg não consegue produzir novos segmentos.

Um problema anterior do Jellyfin documentou como a reprodução só podia continuar até ao último segmento criado antes do diretório de transcodificação encher. O relatório é antigo e fechado, mas o sintoma continua a ser uma razão útil para inspecionar o espaço quando um fluxo transcodificado para após vários minutos.

Verifique o espaço livre, disponibilidade de inodes, mapeamento do contentor, permissões de escrita e limite de capacidade do caminho de transcodificação. Tenha especial cuidado com discos RAM pequenos ou sistemas de ficheiros temporários: usar memória pode reduzir a latência de armazenamento, mas um limite subdimensionado pode causar uma falha abrupta na reprodução.

Um Ficheiro Problemático Geralmente Aponta para o Media

Se muitos ficheiros com resolução e bitrate semelhantes reproduzem corretamente, é menos provável que um único título com falha prove que o servidor inteiro está subdimensionado.

O ficheiro pode conter um perfil de codec invulgar, frames danificados, uma disposição de áudio não suportada, uma faixa de legendas em imagem, timestamps incorretos ou um pico extremo de bitrate. Uma temporada de uma série pode também ter sido codificada de forma diferente das outras.

Teste outra faixa de áudio, desative as legendas, inspecione a informação do media e compare o ficheiro com outro título que use o mesmo codec. Um simples remux para um novo contentor pode ajudar a determinar se o contentor ou os timestamps estão envolvidos sem reencodar o vídeo inteiro.

Múltiplos Fluxos Revelam Limites de Recursos Partilhados

Um servidor doméstico pode lidar perfeitamente com um fluxo e começar a armazenar em buffer apenas quando outro utilizador inicia a reprodução. Compare o modo de reprodução de cada sessão ativa antes de assumir que apenas a rede é responsável.

Várias sessões de Reprodução Direta adicionam principalmente carga de armazenamento e rede. Várias transcodificações de vídeo também competem pela capacidade de codificação da GPU, filtros da CPU, largura de banda da memória e espaço no diretório de transcodificação.

Testar uma sessão, depois adicionar fluxos um a um enquanto observa o uso da CPU, GPU, disco e rede. Isto identifica se o limite prático é o número de conversões, a taxa de bits agregada da media ou a atividade mista de armazenamento.

Ler o registo FFmpeg antes de reinstalar o Jellyfin.

O Painel do servidor indica que tipo de reprodução está a ocorrer, enquanto o correspondente registo FFmpeg explica como o Jellyfin tentou processar o ficheiro.

Procurar falhas na inicialização do dispositivo de hardware, erros de permissões, perfis não suportados, fallback de software, filtros de legendas, filtros de mapeamento de tons, erros de entrada/saída, códigos de saída de processos e erros de espaço de armazenamento.

Capturar o registo da sessão exata que faz buffering. Um registo de um Direct Play não relacionado ou de uma transcodificação bem-sucedida pode levar a conclusões erradas. Reinstalar o servidor raramente resolve um limite de codec do cliente, um dispositivo GPU inacessível ou um diretório temporário cheio.

Usar o sintoma para escolher o próximo teste.

Seguir esta ordem de resolução de problemas.

1. Reproduzir o problema com o mesmo ficheiro e cliente.
2. Abrir o Painel Jellyfin e registar o modo de reprodução.
3. Registar a razão indicada para transcodificação ou compatibilidade.
4. Desativar legendas e testar outra faixa de áudio.
5. Reproduzir o mesmo ficheiro noutro cliente.
6. Verificar a atividade da CPU e GPU durante a sessão afetada.
7. Abrir o registo FFmpeg correspondente.
8. Verificar o espaço e permissões de escrita no diretório de transcodificação.
9. Testar a taxa de transferência LAN sustentada ou a capacidade de upload remoto.
10. Pausar transferências, backups, análises e manutenção de armazenamento.
11. Compare o ficheiro problemático com media semelhante.
12. Considere novo hardware apenas depois de as evidências mostrarem um limite de computação.

Esta ordem evita que alterações não relacionadas escondam a causa original. Altere uma variável de cada vez e reproduza a mesma cena para que os resultados sejam comparáveis.

Conclusão Final

O buffering no Jellyfin não significa automaticamente que o servidor doméstico precisa de uma CPU mais rápida. Comece pelo modo de reprodução ativo, porque o Direct Play e a transcodificação de vídeo apontam para partes diferentes do sistema.

Para sessões transcodificadas, identifique por que a conversão é necessária, verifique toda a cadeia de aceleração de hardware, teste sem legendas, inspecione o mapeamento de tons HDR e confirme que o caminho de transcodificação tem espaço gravável suficiente. No Docker, verifique a GPU a partir do interior do contentor em vez de confiar apenas na deteção do host.

Para o Direct Play, concentre-se na taxa de transferência sustentada da rede, decodificação do cliente, atividade de armazenamento e no ficheiro de mídia individual. A combinação do modo de reprodução, cliente, codec, legendas, atividade de recursos e registos FFmpeg fornece um diagnóstico mais fiável do que alterar definições aleatórias ou substituir hardware primeiro.

Perguntas Frequentes

Por que é que o Jellyfin faz buffering apenas quando as legendas estão ativadas?

O formato de legenda selecionado pode exigir burn-in. O Jellyfin tem então de decodificar o vídeo, renderizar as legendas em cada frame e codificar um novo fluxo. Experimente desativar as legendas, selecionar uma faixa baseada em texto ou usar um cliente que possa renderizar diretamente o formato de legenda.

Por que é que o Jellyfin faz transcodificação num dispositivo mas Direct Play noutro?

Os clientes suportam diferentes combinações de contentores, codecs de vídeo, formatos de áudio, tipos de legendas, perfis e taxas de bits. O dispositivo menos compatível pede ao servidor para converter a parte do ficheiro que não suporta.

Como posso confirmar que a aceleração de hardware do Jellyfin está a funcionar?

Force uma transcodificação de vídeo e depois inspecione os motores de decodificação e codificação GPU do servidor. Confirme também que o registo FFmpeg usa o dispositivo de hardware esperado e que o contentor pode aceder ao dispositivo sem erros de permissão.

Por que é que o Jellyfin faz buffering mesmo quando indica Direct Play?

O Direct Play elimina a transcodificação de vídeo do caminho, mas a rede, o armazenamento, o ficheiro de mídia e o decodificador do cliente ainda podem ser lentos ou instáveis. Teste o ficheiro localmente no mesmo cliente e compare a reprodução por cabo e sem fios.

Deve o Jellyfin usar um SSD para transcodificação?

Um SSD pode reduzir a latência dos segmentos temporários e é útil para a base de dados, metadados e cache do Jellyfin. O requisito mais importante é um caminho de transcodificação com espaço suficiente, gravações fiáveis e permissões corretas. Um disco RAM dimensionado corretamente também pode funcionar, mas um disco subdimensionado pode interromper a reprodução.