Um utilizador do ZimaOS que executava o Jellyfin num sistema Intel N100 com 16 GB de RAM relatou uma diferença clara no comportamento da reprodução: os conteúdos até 1080p funcionavam normalmente, mas uma transmissão 4K que necessitasse de transcodificação elevava a utilização do processador para 100% e tornava-se demasiado irregular para ver. O Jellyfin funcionava com rede Host e o servidor não tinha uma GPU dedicada.
A discussão da comunidade não produziu uma solução final única e confirmada. Em vez disso, evoluiu para uma investigação prática sobre transcodificação por software, gráficos integrados Intel, VA-API, compatibilidade de codecs, mapeamento de tons HDR e o local correto para verificar uma transcodificação ativa. O utilizador original acabou por ativar a aceleração por hardware e conseguiu reproduzir uma transmissão transcodificada, embora a utilização do processador continuasse nos 95–98%.
O problema original de transcodificação 4K no Jellyfin
O servidor utilizava um processador Intel N100 e 16 GB de memória. O Jellyfin funcionava como servidor multimédia local e o tipo de rede do Docker estava definido como Host. A reprodução normal em 1080p não apresentava problemas.
A falha ocorria apenas quando um ficheiro 4K necessitava de transcodificação. Nesse momento, a utilização do processador subia para 100%, a reprodução ficava aos soluços e a transmissão tornava-se, na prática, impossível de ver. O utilizador queria, por isso, saber que definições do Jellyfin poderiam melhorar o desempenho da transcodificação sem uma placa gráfica dedicada.
Esta diferença entre 1080p e 4K tornou-se a pista central nas respostas. Os membros da comunidade concentraram-se menos na rede e na memória e mais no que o Jellyfin estava a converter, em saber se os gráficos integrados do N100 estavam envolvidos e se o cliente selecionado conseguia reproduzir diretamente o formato da fonte.
Porque é que a compatibilidade entre codecs e clientes entrou na discussão
O goultron descreveu a transcodificação de conteúdos 4K num sistema da classe N100 como uma carga de trabalho exigente, sobretudo quando o servidor recorre ao processador. A sua própria abordagem consistia em evitar manter uma biblioteca 4K e preferir conteúdos H.264, por serem reproduzidos diretamente numa gama mais ampla de dispositivos.
A resposta também salientou um ponto prático importante: mesmo um vídeo H.264 pode continuar a exigir algum tipo de conversão. O dispositivo recetor, os formatos de áudio suportados e a velocidade de rede disponível podem afetar o percurso final de reprodução. O goultron suspeitava que a conversão de áudio fosse responsável por algumas transmissões que continuavam a ser transcodificadas apesar de utilizarem vídeo H.264.
Contrastaram esta situação com grande parte dos conteúdos 4K disponíveis, que utilizam normalmente H.265/HEVC. Alguns dispositivos de reprodução e televisores mais pequenos podem não suportar diretamente todos os perfis H.265. Nesses casos, o Jellyfin tem de converter a fonte para o cliente, devolvendo a carga de trabalho ao servidor.
Diagnóstico principal de gelbuilding: verifique primeiro a iGPU do N100
gelbuilding considerou esperado o comportamento do N100 se o Jellyfin estivesse a fazer transcodificação 4K por software. A explicação foi simples: esta carga de trabalho pode levar um CPU pequeno a uma utilização total, o que explica a reprodução 1080p fluida do utilizador original e a transcodificação 4K inutilizável.
A primeira verificação proposta consistia em confirmar se o Jellyfin estava realmente a utilizar o motor multimédia Intel integrado no N100. O N100 não precisa de uma placa gráfica separada para disponibilizar uma iGPU, mas o Jellyfin tem de ter a aceleração por hardware ativada e conseguir aceder a esse dispositivo a partir do respetivo contentor.
O caminho das definições partilhado na resposta era:
- Abra a interface de administração do Jellyfin.
- Abra Reprodução.
- Abra Transcodificação.
- Ative a aceleração por hardware.
- Selecione VA-API para a configuração discutida no tópico.
O resultado esperado era que o processamento deixasse de ser feito por software no CPU e passasse a ser efetuado pela iGPU Intel. gelbuilding também alertou para o facto de não ser possível esperar que a iGPU do N100 convertesse suavemente todas as fontes 4K. Identificou especificamente alguns ficheiros HEVC com taxa de bits elevada como cargas de trabalho que ainda poderiam recorrer ao processamento por software.
A comunidade corrigiu o local onde verificar o VA-API
A resposta inicial sugeria verificar em Dashboard → Activity a indicação VA-API para H.264 ou HEVC. goultron testou esse conselho no Jellyfin 10.10.7 e descobriu que a página Activity apenas apresentava eventos como VideoPlayback e VideoPlaybackStopped.
gelbuilding corrigiu então a instrução. Não era suposto que a página Activity mostrasse se a transcodificação utilizava VA-API ou software. A informação relevante deveria ser verificada enquanto o fluxo 4K estivesse a ser transcodificado ativamente em:
- Painel
- Reprodução
- Transcodificação
A sessão ativa deverá mostrar uma linha por baixo do codec. Uma indicação VA-API significa que a aceleração por hardware está a ser utilizada; uma indicação Software significa que é o CPU que está a fazer a conversão. Se a área de transcodificação estiver vazia, o ficheiro poderá estar a ser reproduzido diretamente ou transmitido diretamente, o que significa que não está a ocorrer nenhuma transcodificação de vídeo ativa.
Porque é que o btop não deu uma resposta clara ao tópico
goultron também tentou verificar a atividade da iGPU através do btop. A iGPU Intel não apareceu claramente na área da GPU, embora essa mesma iGPU já tivesse sido atribuída com êxito ao Frigate, que mostrou estar a utilizar o dispositivo.
gelbuilding respondeu que, neste contexto do ZimaOS, o btop expunha principalmente GPUs dedicadas e, por isso, poderia não apresentar a iGPU Intel mesmo quando esta estivesse ativa. Com base nisso, recomendou considerar a vista de Transcodificação ativa do Jellyfin como o método de confirmação direta.
Mais tarde, Zima-Jerry acrescentou que o btop podia ser utilizado para observar a utilização da GPU. Estas duas afirmações não foram conciliadas antes de a discussão terminar. Por conseguinte, o tópico da comunidade apoia a utilização do btop como ferramenta adicional de observação, mas não como única prova; as informações ativas de transcodificação do Jellyfin continuam a ser necessárias para identificar o processamento VA-API em vez do processamento por software.
Configuração de mapeamento de tons HDR do Zima-Jerry
Zima-Jerry partilhou uma ligação para outra configuração da comunidade, centrada na aceleração de hardware do Jellyfin e no mapeamento de tons HDR no Intel N100. Nesse caso anterior, foi referido que a versão do Jellyfin então disponível na App Store apresentava um problema de conversão de tons de cor.
A alternativa sugerida era a imagem de contentor Jellyfin do nyanmisaka, juntamente com uma configuração YAML personalizada. Esta era uma solução alternativa da comunidade associada às versões do Jellyfin e do ZimaOS utilizadas na altura, pelo que deve ser comparada com a versão atual da App Store antes de substituir uma instalação existente.
O resultado partilhado nessa publicação relacionada não correspondia a uma transcodificação 4K ilimitada. Zima-Jerry estimou que os gráficos integrados do N100 conseguiam converter vídeo Dolby Vision de forma fluida a aproximadamente 4K 30 fps ou inferior na configuração testada.
O que mudou depois de o utilizador original ativar a aceleração de hardware
Depois de analisar as respostas, Heimwerkerking ativou a aceleração de hardware para a transcodificação. Isto produziu uma melhoria significativa: pelo menos uma transmissão transcodificada tornou-se reproduzível.
As informações de reprodução ativas apresentadas no painel eram 48,7 Mbps MP4 H264 AAC. No entanto, a utilização da CPU manteve-se entre 95% e 98%, pelo que o utilizador continuava sem ter a certeza de que a iGPU Intel estava realmente a processar a conversão de vídeo.
Este resultado não provou que o problema tivesse sido totalmente resolvido. Demonstrou que a alteração da configuração melhorou a reprodução, mas o tópico continuava sem uma etiqueta VA-API confirmada, um resultado completo do FFmpeg ou uma leitura reconciliada da iGPU. A resposta final voltou a sugerir observar a utilização da GPU com o btop, e não foi publicada qualquer confirmação posterior.
O que esta discussão da comunidade realmente estabelece
A discussão apoia fortemente a transcodificação 4K por software como a primeira explicação para um N100 atingir 100% de utilização da CPU. Também estabelece um procedimento de verificação corrigido: iniciar uma transcodificação 4K e consultar a sessão ativa na área de Reprodução e Transcodificação do Jellyfin, em vez do histórico da Atividade.
As respostas acrescentam vários limites relacionados com a carga de trabalho. A compatibilidade do cliente com H.265, a conversão de áudio, um bitrate de fonte elevado, o mapeamento de tons HDR e o contentor específico do Jellyfin podem alterar o resultado. Ativar o VA-API melhorou a capacidade do utilizador original para reproduzir um fluxo transcodificado, mas a utilização da CPU manteve-se elevada.
O tópico não estabelece um número universal de fluxos no N100 nem prova que seja necessária uma GPU Intel Arc. gelbuilding apresentou dois passos seguintes possíveis para os utilizadores que ainda precisam de uma conversão 4K estável: reduzir o bitrate da fonte ou adicionar uma pequena GPU Intel Arc. A discussão terminou antes de qualquer uma das opções ser testada pelo autor original.
Perguntas frequentes da discussão da comunidade
Porque é que 1080p funcionou enquanto a transcodificação 4K apresentava interrupções?
A comunidade atribuiu a diferença à carga de trabalho de software muito mais pesada gerada quando o ficheiro 4K exigia conversão. O N100 original atingiu uma utilização total da CPU durante esse processo.
Onde deve ser verificado o VA-API no Jellyfin?
Inicie um fluxo 4K que force a transcodificação e, em seguida, consulte a sessão ativa em Painel de controlo, Reprodução e Transcodificação. Foi demonstrado que o histórico de eventos da Atividade não fornece a etiqueta VA-API ou Software necessária.
O que significa uma vista vazia de transcodificação ativa?
De acordo com a correção de gelbuilding, isso pode significar que o ficheiro está a ser reproduzido ou transmitido diretamente, e que não está atualmente ativa nenhuma transcodificação de vídeo.
Ativar a aceleração por hardware resolveu completamente o problema?
Não. Permitiu reproduzir um fluxo transcodificado, mas a utilização da CPU manteve-se nos 95–98% e o tópico terminou sem uma confirmação final de que a iGPU tratava de todo o pipeline.
Que opções sugeriu a comunidade caso o 4K continuasse instável?
As respostas sugeriram dar preferência a conteúdos H.264 compatíveis sempre que possível, reduzir o bitrate da fonte 4K, testar a configuração personalizada do Jellyfin partilhada pelo Zima-Jerry ou adicionar uma pequena GPU Intel Arc para obter uma solução de transcodificação por hardware mais capaz.
