Eu estava lendo este artigo e vi que uma CPU é melhor para compactação de vídeo do que uma GPU.
O artigo diz apenas que isso acontece porque o processador pode lidar com algoritmos mais complexos que o GPU, mas eu quero uma explicação mais técnica, fiz algumas pesquisas na internet, mas não encontrei nada.
Então, alguém sabe explicar ou vincular um site para eu ter uma explicação mais profunda disso?
O artigo que você vinculou não é muito bom.
Normalmente, as codificações de taxa de bits de passagem única convertem sua taxa de bits em um valor de RF com um limite máximo de taxa de bits e a levam a partir daí.
O controle de rato ABR de uma passagem do x264 não é implementado como limite de CRF +. Ele está certo que o 2pass é de longe a melhor maneira de atingir uma taxa de bits alvo.
E ele aparentemente não percebe que poderia iniciar o x264 com threads = 3 ou algo assim, para deixar algum tempo de CPU livre para outras tarefas. Ou defina a prioridade do x264 como muito baixa, para obter apenas o tempo de CPU que nenhuma outra tarefa deseja.
Ele também mistura threads = 1 com o uso de CUDA, ou algo assim. Não é de admirar que você tenha dúvidas, porque esse artigo tem uma explicação TERRÍVEL. O artigo inteiro se resume basicamente a: use x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, ou talvez use alguma filtragem de luz com um script AviSynth de entrada. Ele realmente recomenda "placebo". Isso é hilário. Eu nunca vi um arquivo pirata codificado com placebo. (você pode distinguir de me=esaou me=tesa, em vez de me=umhtodas 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 é necessário arredondar para exatamente um valor inteiro de 8 bits. Você pode pensar em 8 bits por componente como um hack de velocidade; quantizar no domínio da frequência e depois compactá-lo com o CABAC significa que coeficientes de profundidade de bits mais altos não precisam ocupar mais espaço.
(BTW, o h.265 obtém menos benefícios com codificações de 10 bits para vídeo de 8 bits porque já possui mais precisão para vetores de movimento. Se houver um benefício em usar x265 de 10 bits para entradas de vídeo de 8 bits, é menor que com x 264. Portanto, é menos provável que a pena de velocidade valha a pena.)
edit: doom9 está novamente ativo agora, então vou arrumar o link. Vá a ele para citar corretamente quem disse o quê.
http://forum.doom9.org/showthread.php?p=1135399#post1135399
o Google apenas armazena em cache a versão estúpida de impressão, que não mostra corretamente a citação. Não tenho muita certeza de quais partes dessas mensagens são citadas e quais são atribuídas à própria pessoa.
Padrões de ramificação altamente irregulares (modos de pular) e manipulação de bits (codificação de quantização / entropia) não se adequam às GPUs atuais. A IMO, a única aplicação realmente boa no momento, é o algoritmo ME de pesquisa completa, no final, embora a pesquisa completa acelerada ainda seja lenta, mesmo que seja mais rápida que na CPU.
- MfANa verdade, basicamente tudo pode ser feito razoavelmente na GPU, exceto o CABAC (o que poderia ser feito, apenas não podia ser paralelo).
x264 O CUDA implementará inicialmente um algoritmo ME de fullpel e subpel; mais tarde, poderíamos fazer algo como RDO com uma aproximação de custo em vez de CABAC.
Porque ele tem que fazer tudo no único ponto flutuante de precisão
- MfAErrado, o CUDA suporta matemática inteira.
- Shikari Escuro
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 parte do trabalho do encadeamento lookahead (decisão rápida de I / P / B, 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 as heurísticas inteligentes para o término antecipado dos caminhos de pesquisa nas CPUs superam as GPUs de força bruta que trazem para a mesa, pelo menos para a codificação de alta qualidade. É apenas comparado a -preset ultrafastonde você pode escolher razoavelmente a codificação HW em vez de x264, esp. se você tiver uma CPU lenta (como laptop com dual core e sem hyperthreading). Em uma CPU rápida (i7 quad core com hyperthreading), o x264 superfastprovavelmente será tão rápido e parecerá melhor (com a mesma taxa de bits).
Se você estiver fazendo uma codificação em que a distorção da taxa (qualidade por tamanho do arquivo) é importante, use x264 -preset mediumou mais lento. Se você estiver arquivando algo, gastar um pouco mais de tempo da CPU agora economizará bytes enquanto você mantiver esse arquivo por perto.
observação lateral: se você vir mensagens de deadrats em um fórum de vídeo, isso não será útil. Ele está errado sobre a maioria das coisas que ele está falando em todos os tópicos que eu já vi. Suas postagens apareceram em alguns tópicos que pesquisei sobre a codificação x264 GPU. 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:
O ffmpeg suporta a codificação de vídeo acelerada por GPU h264 e h265 NVENC . Você pode codificar 1 passagem ou 2 passagens na qualidade que escolher, para hevc_nvenc ou h264_nvenc, ou mesmo com uma GPU de nível de entrada é muito mais rápida que a codificação não acelerada e a codificação acelerada Intel Quick Sync.
Codificação de alta qualidade com 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 que a codificação da CPU.
Se você não possui 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 que a codificação não acelerada.
-c:v libx264 -preset slower(o que não é tão lento, como quase em tempo real para 1920x1080p24 em um Skylake i7-6700k.)ffmpegcom-vcodec h264_qsvno meu antigo notebook Intel com um Grpahics Intel HD 4000 fez a renderização muito mais rápido!Para elaborar um pouco mais sobre o que Peter diz, em geral, o uso de múltiplos processadores ajuda nos casos em que você tem várias tarefas independentes que precisam ser feitas, mas que não dependem umas das outras, ou uma tarefa em que você está executando o mesmo matemática em grandes quantidades de dados.
Se, no entanto, você precisar da saída do cálculo A como entrada do cálculo B e da saída do cálculo B como entrada do cálculo C, não será possível agilizá-la com um núcleo diferente trabalhando em cada tarefa ( A, B ou C) porque um não pode ser iniciado até que o outro termine.
No entanto, mesmo no caso acima, você poderá paralelizar de outra maneira. Se você pode dividir seus dados de entrada em partes, você pode ter um trabalho principal na execução de A, depois B, depois C com uma parte dos dados, enquanto outro núcleo trabalha na execução de A, depois B e C em uma parte diferente dos dados. .
Existem outras considerações também. Talvez você possa encontrar uma maneira de paralelizar os cálculos, mas apenas ler os dados do disco ou da rede ou enviá-los para a GPU levará mais tempo do que os cálculos. Nesse caso, não faz sentido paralelizá-lo porque apenas colocar os dados na memória leva mais tempo que a quantidade de tempo que você economiza fazendo o cálculo em paralelo.
Em outras palavras, é tanto uma arte quanto uma ciência.
fonte