As cenas com movimento intenso e luz de movimento influenciam o tempo total de codificação?

2

Sou um jogador ávido. Ocasionalmente, gosto de gravar meu jogo com o Fraps e enviá-lo no YouTube. Para minha codificação, eu uso o codec x264 de Komisar no VirtualDub com as seguintes configurações: link para a imagem

Agora, estou tentando escrever um pequeno artigo no blog porque recentemente aposentei meu antigo Q6600 e atualizei para 2700k.

Aqui está um pequeno trecho do rascunho:

Encoding speed is measured in (average) frames per second. The more, the merrier. It's also important to know that there are, what I like to call, "motion-heavy" and "motion-light" scenes.

e

Motion-heavy scenes take much longer to encode than motion-light ones, at least that was my experience in those 2+ years since. I might of course be totally wrong about this, and unfortunately I don't have hard statistics to show for, i.e. benchmarks while encoding. Just my observation, unfortunately.

Agora, com relação ao codec vinculado, software de codificação usado e configurações vinculadas, estou correto na declaração sobre cenas com movimento intenso e com luz de movimento?

Minha experiência pessoal diz sim. Demoro-me muito mais tempo para codificar cenas onde muita coisa está acontecendo na tela, ao contrário de movimentos leves. Usando o mesmo codec, o mesmo software de codificação e as mesmas configurações vinculadas acima.

    
por Grumpy ol' Bear 14.12.2011 / 14:24

3 respostas

3

A compactação de vídeo basicamente codifica as diferenças entre um quadro e o próximo . Então, quanto mais diferenças entre dois quadros, mais dados você terá que escrever. Isso é muito mais complexo que isso, mas essa é a base. Você notará que em DVDs ou qualquer outra compressão de largura de banda fixa (MPEG1, MPEG2, h.264, etc.), as imagens estáticas são quase perfeitas, enquanto as imagens em movimento são desfocadas. Isso porque muito movimento envolve mais dados para escrever, portanto, é necessário fazer uma troca.

    
por 14.12.2011 / 15:12
3

Não sei se a quantidade de dados a processar é significativa. Como cada quadro tem exatamente a mesma quantidade de pixels, você só pode gerar "mais dados" se já executou algoritmos complicados de estimativa de movimento e, mesmo assim, o quadro P / B resultante será menor (caso contrário compensação de movimento seria inútil). A largura de banda de memória nos sistemas modernos é tão alta que eu não acho que a quantidade de dados contribua para a velocidade de codificação.

Um codificador deve primeiro executar um algoritmo, para cada quadro, para determinar qual tipo de quadro deve ser usado. Esse algoritmo pode ser complicado, mas a complexidade deve ser aproximadamente a mesma para cada quadro (portanto, não é um fator aqui). No entanto, quando se determina que um P / B é necessário, algoritmos de estimativa de movimento muito complicados devem ser executados com parâmetros diferentes para determinar qual é a melhor maneira de comprimir o movimento no quadro. Quando a seleção de quadros de referência entra em jogo, como em quadros B, a complexidade anterior será multiplicada.

Essas são complexidades adicionais, portanto, o tempo de computação, que só ocorre quando o codificador decide que a compensação de movimento pode comprimir melhor o quadro do que as diferenças simples de pixel, portanto, cenas com movimento pesado demoram mais para serem computadas. Isso também explica por que o tempo de compactação se beneficia mais de processadores mais rápidos do que de armazenamento mais rápido.

    
por 14.12.2011 / 16:28
2

Obviamente, há muito mais dados para processar ao codificar com movimento pesado.

Então, tecnicamente sim, isso influencia o tempo total de codificação e o movimento pesado será mais longo para codificar do que a luz de movimento.

    
por 14.12.2011 / 15:02