Para o mesmo fluxo 4K em tempo real, a aceleração de hardware é normalmente a melhor opção para um servidor multimédia quando a GPU ou o motor multimédia suporta todas as etapas necessárias de descodificação, filtragem, mapeamento de tons e codificação. Transfere o trabalho de vídeo mais pesado dos núcleos gerais da CPU, reduz a pressão sobre a CPU e cria mais margem para a execução concorrente. A transcodificação por CPU continua a ser útil quando o percurso de hardware não suporta um formato ou filtro necessário, ou quando uma codificação de software pontual dá prioridade à eficiência de compressão em detrimento do débito em tempo real. A comparação só é significativa se o ficheiro de origem, a resolução de destino, a taxa de bits, o cliente e os requisitos de processamento forem mantidos constantes.
Mantenha o trabalho 4K constante antes de comparar os motores
Uma comparação justa utiliza o mesmo ficheiro de origem, a mesma resolução de saída, a mesma taxa de bits ou definição de qualidade pretendida, o mesmo estado das legendas, o mesmo requisito HDR/SDR e o mesmo cliente. Alterar qualquer uma destas variáveis pode mudar a quantidade de trabalho mais do que a escolha entre codificação por hardware e por CPU.
A documentação de desempenho do HandBrake mostra como a predefinição do codificador, o objetivo de qualidade, a taxa de bits e os filtros afetam a velocidade. As suas variáveis controladas de desempenho do codificador fornecem a disciplina de teste adequada: compare um percurso de cada vez, em vez de comparar dois trabalhos diferentes.
Registe a velocidade de transcodificação, a reprodução interrompida ou atrasada, a utilização da CPU, a utilização do motor de vídeo, o consumo de energia do sistema, se disponível, e a qualidade da saída. Se ambos os percursos forem mais rápidos do que em tempo real, a decisão seguinte deve centrar-se na margem disponível e na eficiência, não em saber se algum deles consegue tecnicamente concluir a tarefa.
A aceleração de hardware vence o teste de débito em tempo real
A aceleração de hardware compatível utiliza blocos de descodificação e codificação de função fixa, concebidos especificamente para vídeo. Isso evita consumir ciclos de CPU de uso geral em cada macrobloco ou transformação e, normalmente, deixa muito mais capacidade de CPU para a aplicação multimédia, a pilha de armazenamento, as legendas, o trabalho da base de dados e serviços não relacionados.
O Jellyfin enumera QSV, NVENC/NVDEC, AMF, VA-API, VideoToolbox e outros métodos de hardware, e descreve como um pipeline de transcodificação pode descarregar várias etapas. O pipeline de transcodificação de função fixa sustenta a conclusão prática: o hardware vence quando todo o percurso necessário é efetivamente acelerado.
A vantagem é maior quando várias transmissões se sobrepõem. Um CPU capaz de transcodificar por software uma fonte 4K em tempo real poderá ter pouca margem para uma segunda sessão, enquanto um motor de vídeo adequado consegue frequentemente manter mais trabalho simultâneo sem consumir o mesmo orçamento do CPU geral.
A transcodificação por CPU mantém a flexibilidade onde os caminhos de hardware terminam
A transcodificação por software consegue processar formatos, opções de codificação ou filtros que uma determinada geração de hardware não disponibiliza. Também permite predefinições mais lentas que investem mais computação na melhoria das decisões de compressão, o que pode ser vantajoso para preparar bibliotecas offline, embora seja frequentemente inadequado para reprodução em direto.
As orientações atuais da Plex sobre transmissão com aceleração de hardware referem que a geração do hardware pode afetar a qualidade de saída e que a codificação HEVC requer mais recursos do que a H.264. A sua saída de hardware sensível à geração define o limite: o hardware não é um codificador idêntico em todas as gerações de processadores e GPUs.
A transcodificação por CPU continua, por isso, a ser a opção de recurso quando o acelerador não consegue concluir a tarefa necessária. Não deve ser escolhida apenas porque existe utilização disponível do CPU; a questão é saber se a flexibilidade adicional compensa o consumo de energia e a menor capacidade de lidar com sessões simultâneas numa sessão 4K em direto.
A aceleração parcial pode ocultar o verdadeiro estrangulamento
Uma sessão pode apresentar codificação de hardware enquanto o CPU continua a tratar da descodificação, da sobreposição permanente de legendas, do processamento de áudio, do redimensionamento ou de outro filtro. Nesse caso, o sistema não está a comparar um pipeline totalmente de hardware com um pipeline totalmente de CPU; está a comparar dois modelos híbridos com diferentes etapas de software.
O Video Codec SDK da NVIDIA separa as capacidades do NVDEC e do NVENC e documenta o suporte de hardware específico de cada codec. As suas capacidades separadas de descodificação e codificação de hardware ilustram por que motivo uma codificação de hardware bem-sucedida não prova que a descodificação da fonte também seja descarregada para o hardware.
Observe a atividade do CPU e do motor de vídeo e, em seguida, consulte o registo de transcodificação. Se um filtro de software for o estrangulamento, atualizar para um codificador de hardware mais rápido poderá não alterar a reprodução até que esse filtro também disponha de um caminho acelerado ou os requisitos de reprodução mudem.
A Qualidade Deve Ser Comparada à Taxa de Bits de Entrega que Utiliza Realmente
Um codificador de software pode utilizar predefinições lentas para procurar de forma mais agressiva uma maior eficiência de compressão, enquanto o hardware de função fixa é otimizado para o débito e uma latência limitada. Os codificadores de hardware mais recentes melhoraram substancialmente, pelo que as diferenças de qualidade devem ser medidas, e não presumidas com base em comparações entre gerações antigas.
A documentação da Quick Sync da Intel salienta que a funcionalidade é implementada nos gráficos do processador e tem de ser suportada pelo CPU específico. A verificação exata da geração do Quick Sync é importante, porque “aceleração por hardware” pode significar motores multimédia muito diferentes consoante a geração da plataforma.
| Eixo de decisão | Aceleração por hardware | Transcodificação por CPU |
|---|---|---|
| Débito 4K em tempo real | Geralmente mais forte quando totalmente suportado | Depende fortemente do CPU e do codec |
| Margem de CPU | Preserva mais capacidade geral do CPU | Consome núcleos gerais |
| Fluxos simultâneos | Geralmente mais prático | Escala com um custo substancial de CPU |
| Filtros/formatos não suportados | Pode recuar ou falhar | Maior flexibilidade do software |
| Compressão offline lenta | Otimizado para a velocidade | Pode utilizar predefinições de software mais lentas |
Para reprodução em direto, compare a qualidade visível à taxa de bits que o utilizador remoto ou cliente irá receber. Se ambos cumprirem o limiar de qualidade da casa, escolha o percurso que deixe mais margem de recursos, em vez de otimizar uma métrica do codificador que o espetador não consegue ver.
A Potência e a Concorrência Transformam um Teste de Um Fluxo numa Decisão para o Servidor
O mesmo fluxo 4K pode ser sustentável no CPU e, ainda assim, ser a predefinição errada para um servidor sempre ligado. Uma utilização elevada do software aumenta a probabilidade de um segundo fluxo, uma análise da biblioteca, uma cópia de segurança ou outro serviço interferir com a reprodução. A aceleração por hardware preserva mais margem de agendamento para essas sobreposições.
O guia da ZimaSpace para verificar se a transcodificação por hardware está realmente a funcionar recomenda confirmar o fluxo ativo, a atividade do acelerador do anfitrião e os registos, em vez de confiar apenas numa definição. Use essa mesma prova antes de atribuir qualquer vantagem de eficiência ao percurso de hardware.
Se uma transmissão acelerada por hardware for estável, mas a segunda falhar, encontrou um limite real de simultaneidade. Se a transcodificação de software por CPU só funcionar enquanto todos os outros serviços estiverem inativos, passou numa demonstração, mas falhou perante a carga de trabalho do servidor.
Perguntas frequentes
A transcodificação por hardware produz sempre pior qualidade do que a transcodificação por CPU?
Não. A qualidade depende da geração do hardware, do codec, das definições do codificador, da taxa de bits de destino e da predefinição do codificador de software utilizada na comparação. As predefinições de software lentas podem trocar muito mais computação por eficiência de compressão, mas os motores de hardware recentes também conseguem produzir uma saída em tempo real de muito boa qualidade. Compare à taxa de bits e ao tamanho de ecrã que os seus utilizadores realmente veem.
Porque é que a utilização da CPU continua elevada com a aceleração por hardware ativada?
Apenas parte do pipeline pode ser acelerada. A conversão de áudio, as legendas, o mapeamento de tons, o redimensionamento, os formatos de descodificação não suportados ou outros filtros podem continuar a ser processados pela CPU. Utilize os registos da transmissão e a atividade do motor do anfitrião para descobrir qual a etapa que continua limitada ao software.
Deve utilizar a transcodificação por CPU se o servidor tiver muitos núcleos inativos?
Só se o percurso de software atingir uma velocidade em tempo real com margem suficiente para a pior carga simultânea e se valorizar a sua flexibilidade ou as características da saída. Os núcleos inativos proporcionam margem útil para bases de dados, análises, cópias de segurança e sessões adicionais; consumi-los simplesmente porque estão disponíveis pode reduzir a resiliência do servidor.
Utilize o hardware primeiro para 4K em direto; CPU como caminho de exceção
Escolha a aceleração por hardware quando o percurso exato da fonte 4K até à saída for totalmente suportado e forem importantes o débito em tempo real, a simultaneidade e a margem de capacidade do servidor. Esta é a opção normal para um servidor multimédia sempre ligado que serve clientes variados.
Escolha a transcodificação por CPU quando o hardware não conseguir suportar um codec ou uma etapa de processamento necessária, ou quando o trabalho for offline e aceitar deliberadamente um tempo de codificação muito mais longo com uma predefinição de software. Trata-se de uma exceção da carga de trabalho, não de uma prova de que o hardware de vídeo de função fixa é desnecessário.
Se a transmissão já for reproduzida diretamente, deixe de comparar completamente estes dois caminhos. Nem a transcodificação por hardware nem por CPU melhora uma sessão que não necessita de conversão de vídeo; preserve a Reprodução direta e utilize o orçamento do servidor nas conversões que não pode evitar.
Comparações de Produtos
Mais para Ler

Docker vs. máquina virtual para o Plex: qual é a opção de implementação mais adequada?
Uma avaliação condicional da implementação do Plex para Docker, máquinas virtuais ou Docker numa máquina virtual, com base em requisitos operacionais comuns.

8 GB vs 16 GB vs 32 GB de RAM para o Plex: que nível se adequa à sua carga de trabalho?
Escolha 8 GB para o Plex mais simples, 16 GB para aplicações partilhadas moderadas ou 32 GB para máquinas virtuais e espaços de trabalho...

A aceleração de hardware dedicada dá ao Plex uma vantagem significativa?
A aceleração por hardware oferece vantagens nas transcodificações repetidas suportadas; apenas com CPU continua a ser uma opção válida para reprodução direta, conversões ocasionais...

