Por que o processador é “ melhor ” para codificação do que a GPU?

O artigo vinculado não é muito bom.

Normalmente, as codificações de taxa de bits de passagem única convertem sua taxa de bits em um valor RF com um limite máximo de taxa de bits e parte daí.

O controle de controle ABR de uma passagem de x264 “não é implementado como limite de CRF +. Ele está certo de que 2 passagens é de longe a melhor maneira de atingir a taxa de bits desejada.

E ele aparentemente não percebe que poderia iniciar o x264 com threads = 3 ou algo assim, para deixe algum tempo de CPU livre para outras tarefas. Ou defina a prioridade de x264 como muito baixa, de modo que só obtenha tempo de CPU que nenhuma outra tarefa deseja.

Ele também confunde threads = 1 com o uso de CUDA ou algo assim. o artigo tem uma explicação TERRÍVEL. O artigo inteiro basicamente se resume a: usar x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv ou talvez usar alguma filtragem de luz com um script AviSynth de entrada. Na verdade, ele recomenda ” placebo “. Isso é hilário. Nunca vi um arquivo pirata codificado com placebo. (Você pode saber por me=esa ou me=tesa, em vez de me=umh para todas as predefinições de boa qualidade, até veryslow.

Ele também não menciona o uso de profundidade de cor de 10 bits. Mais lento para codificar e decodificar, mas mesmo após a conversão para 8 bits, você obtém um SSIM de 8 bits melhor. Ter mais precisão para vetores de movimento aparentemente ajuda. Além disso, não ter que arredondar para exatamente um valor inteiro de 8 bits ajuda. Você pode pensar em 8 -bit por componente como um hack de velocidade; quantizar no domínio da frequência e, em seguida, compactar isso com CABAC significa que coeficientes de profundidade de bits mais altos não precisam ocupar mais espaço.

(BTW, h. O 265 obtém menos benefícios com codificações de 10 bits para vídeo de 8 bits porque já tem mais precisão para vetores de movimento. Se houver uma vantagem em usar x265 de 10 bits para entradas de vídeo de 8 bits, é menor do que com x264. Portanto, é menos provável que a penalidade de velocidade Valerei a pena.)

Para responder à sua pergunta:

edit: doom9 está de volta agora, então vou limpar o link. Vá até ele para uma citação adequada de quem disse o quê.

http://forum.doom9.org/showthread.php?p=1135399#post1135399

O Google só armazena em cache a versão impressa idiota que não mostra as citações corretamente. Não tenho certeza de quais partes dessas mensagens são citações e quais são atribuídas à própria pessoa.

Padrões de ramificação altamente irregulares (modos de salto) e manipulação de bits (codificação de quantização / entropia) não se adequam às GPUs atuais. O IMO é o único aplicativos realmente bons no momento são os algoritmos de busca completa de ME, embora a busca completa acelerada ainda seja lenta, mesmo que seja mais rápida do que na CPU.
– MfA

Na verdade, basicamente tudo pode ser razoavelmente feito na GPU, exceto CABAC (o que poderia ser feito, mas não poderia ser paralelizado).

x264 CUDA implementará um fullpel e algoritmo subpel ME inicialmente; mais tarde, poderíamos fazer algo como RDO com uma abordagem de custo de bit ximação em vez de CABAC.

Porque tem que fazer tudo em um ponto flutuante de precisão única
– MfA

Errado, CUDA suporta matemática inteira.

– Dark Shikari

Dark Shikari é o mantenedor do x264 e desenvolvedor da maioria dos recursos desde 2007 ou mais.

AFAIK, este projeto CUDA não deu certo. Há suporte para o uso do OpenCL para descarregar algum trabalho do thread de lookahead (decisão I / P / B rápida, não uma codificação final de alta qualidade do quadro).

Meu entendimento é que o espaço de pesquisa para codificação de vídeo é TÃO grande que heurísticas inteligentes para término antecipado de caminhos de pesquisa superam as GPUs de força bruta trazer para a mesa, pelo menos para uma codificação de alta qualidade. É apenas comparado a -preset ultrafast onde você pode razoavelmente escolher a codificação HW em vez de x264, especialmente se você tiver uma CPU lenta (como um laptop com dual core e sem hyperthreading). CPU (i7 quad core com hyperthreading), x264 superfast provavelmente será tão rápido e parecerá melhor (com a mesma taxa de bits).

Se você está fazendo uma codificação onde a taxa de distorção (qualidade por tamanho de arquivo) é importante, você deve usar x264 -preset medium ou mais lento. Se você ” Ao arquivar algo, gastar um pouco mais de tempo de CPU agora economizará bytes enquanto você “mantiver esse arquivo por perto.

observação, se você vir mensagens de ratos mortos em um fórum de vídeo, isso” não vai ser útil. Ele está errado sobre a maioria das coisas que ele está falando em cada tópico que eu já vi. Suas postagens apareceram em alguns tópicos que pesquisei sobre codificação GPU x264. Aparentemente, ele não entende por que não é fácil, e postou várias vezes para dizer aos desenvolvedores do x264 por que eles são burros …

atualização de 2017:

ffmpeg suporta codificação de vídeo acelerada por GPU NVENC h264 e h265 . Você pode fazer a codificação de 1 ou 2 passagens com a qualidade que escolher, para hevc_nvenc ou h264_nvenc, ou mesmo com uma GPU básica, é muito mais rápido do que a codificação não acelerada e a codificação acelerada Intel Quick Sync.

Codificação de alta qualidade de 2 passagens:

ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4 

Codificação padrão de 1 passagem:

ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4 

Ajuda e opções do NVENC ffmpeg:

ffmpeg -h encoder=nvenc 

Use-o, é muito mais rápido do que a codificação da CPU.

Se você não tiver uma GPU, pode usar o codec Intel Quick Sync, h264_qsv, hevc_qsv ou mpeg2_qsv, que também são muito mais rápidos do que a codificação não acelerada.

Comentários

• Use-o se você valorizar a velocidade (e baixo uso da CPU) sobre a qualidade por tamanho de arquivo. Em alguns casos de uso, por exemplo, streaming para twitch, que ‘ é o que você deseja (especialmente o baixo uso da CPU). Em outros, por exemplo, codificar uma vez para criar um arquivo que será transmitido / assistido muitas vezes, você ainda não t vai superar -c:v libx264 -preset slower (o que não é tão lento, como quase em tempo real para 1920x1080p24 em um Skylake i7-6700k.)
• Usar ffmpeg com -vcodec h264_qsv em meu antigo notebook Intel com um Intel HD Grpahics 4000 tornou a renderização muito mais rápida!

Para elaborar um pouco mais sobre o que Peter diz, em geral, usar vários processadores ajuda nos casos em que você tem várias tarefas independentes que todas precisa ser feito, mas não tem dependências entre si, ou uma tarefa em que você está realizando a mesma matemática em grandes quantidades de dados.

Se, no entanto, você precisa da saída do cálculo A como a entrada do cálculo B, e a saída do cálculo B como a entrada para o cálculo C, então você não pode acelerá-lo tendo um trabalho principal diferente em cada tarefa (A, B ou C) porque não se pode comece até que o outro termine.

No entanto, mesmo no caso acima, você pode ser capaz de t o paralelizar de outra maneira. Se você pode quebrar seus dados de entrada em pedaços, você pode ter um trabalho principal em fazer A, depois B, então C com um pedaço de dados, enquanto outro núcleo trabalha em fazer A, depois B e C em um pedaço diferente de dados .

Existem também outras considerações. Talvez você possa encontrar uma maneira de paralelizar os cálculos, mas apenas ler os dados do disco, ou pela rede, ou enviá-los para a GPU vai demorar mais do que fazer os cálculos. Nesse caso, não faz sentido paralelizar porque apenas colocar os dados na memória leva mais tempo do que a quantidade de tempo que você economiza fazendo o cálculo em paralelo.

Em outras palavras, é tanto uma arte quanto uma ciência.

Comentários

• Oh, sim x264 paraleliza muito bem em CPUs multicore. Eu escala quase linearmente até pelo menos 8 núcleos, e decentemente até além de 32. A estimativa de movimento pode ser feita em paralelo, deixando apenas o trabalho necessariamente serial para outro thread e truques semelhantes.
• A questão é ‘ t paralelismo em geral, é ‘ GPUs em particular. Eles ‘ são muito mais restritivos no código que você pode fazer com que sejam executados do que CPUs. Acho que ‘ s porque você não pode ‘ ter código com ramificações que seguem caminhos diferentes em blocos diferentes da imagem. Não ‘ não entendo exatamente o porquê, mas acho que ‘ é algo assim. Cada processador de stream é tão simples, e com meios tão limitados de fazê-lo funcionar independentemente dos outros, que ou você sempre tem que esperar que o mais lento termine, ou você tem limitações para ramificar, ou ambos.
• Se você tivesse um cluster de computadores (CPUs com RAM independente que não ‘ competiam entre si por largura de banda de memória e cache de CPU), você ‘ d divide seu vídeo de entrada em GOPs e envia seções do vídeo de entrada ainda compactado para serem decodificados e compactados em outras máquinas no cluster.Portanto, apenas o vídeo compactado de entrada ou saída teria que ser transferido. Em um sistema de cache / RAM compartilhado multicore como até mesmo uma estação de trabalho x86 multisocket, você tem vários threads operando nos mesmos quadros ao mesmo tempo. (também significa que você não ‘ precisa de um novo código para fazer o controle de proporção global para codificações de segmentação.)