
Tenho 950 arquivos PNG que se destinam a se tornar quadros individuais em uma trilha de vídeo de 38 segundos a 25 quadros por segundo. Os nomes dos arquivos são idênticos, exceto pelo número de sequência, como é habitual neste tipo de casos.
Quero produzir um contêiner de um formato amplamente suportado, de preferência WebM, se todos os critérios puderem ser atendidos, ou MPEG-4, por exemplo, com um codec que seja suportado por navegadores modernos para reprodução, a partir desta série de imagens PNG que eu ter. O problema é que as cores são alteradas e a cor de fundo no vídeo decodificado não corresponde mais ao mesmo trio RGB amostrado da cor de fundo nas imagens PNG. Isso faz com que o vídeo fique fora do plano de fundo pretendido na minha página HTML onde o vídeo está incorporado.
Eu tentei o simples:
ffmpeg -f image2 -i image%03d.png output.webm
o que de fato me deu uma trilha de vídeo VP9 de 25 fps embalada em um contêiner WebM.
As imagens PNG são em estilo de animação, com fundo sólido e formas simples animadas em primeiro plano. Eles parecem ser coloridossem etiqueta(isso é o que o Adobe Bridge me diz, presumo que isso signifique nenhum perfil de cores incorporado ou uma referência a um). O problema com minha tentativa acima é que, embora o contêiner seja reproduzido no Chrome, a cor de fundo amostrada na imagem PNG, com RGB triplet #ED4D56
, não corresponde perceptualmente à cor de fundo que aparece no vídeo que está sendo reproduzido.
Este é um efeito colateral inevitável da conversão de cores RGB para YUV (codificação) para RGB (reprodução)? Existe alguma maneira de mitigar isso? Não insisto que os quadros na trilha de vídeo sejam codificados usando RGB, suponho que YUV seja adequado, desde que um navegador moderno reproduza esses quadros produza o mesmo triplo RGB (dentro de uma margem de erro insignificante) ao decodificar e exibir o quadro(s).
Minha pergunta é: qual linha de comando ffmpeg
posso tentar atenuar isso? Estou aberto para mudar o codec de vídeo, formato de pixel, habilitar o gerenciamento de cores no ffmpeg, se existir, etc.
Responder1
Tive uma tarefa muito semelhante recentemente e diria que ainda não existe uma solução perfeita (em outubro de 2018). Este é o efeito colateral da conversão de cores RGB para YUV para RGB de baixa precisão. Mesmo algumas variantes de codecs "sem perdas" (por exemplo, libvpx-vp9 -lossless
) produzem cores distorcidas devido ao espaço de cores YUV.
Se cores não exatas forem aceitáveis, então olibvpxcodec pode fazer um bom trabalho:
ffmpeg -r 25 -i image%03d.png -c:v libvpx -crf 4 -b:v 0 output.webm
Com essas configurações, produziu-se uma quantidade insignificante de mudança de cor ou até mesmo as cores exatas para alguns conjuntos de quadros. Os codecs VPx são amplamente suportados (todos os principais navegadores, exceto IE e Safari) e produzem arquivos de tamanho razoável.
Se as cores exatas forem estritamente necessárias, precisamos evitar a conversão do espaço de cores. A única solução entre navegadores que encontrei é usarpng animadoimagens.
ffmpeg
tem apenas suporte básico para apng, então é melhor usar outras ferramentas, por exemploapngasm
:apngasm output.png image001.png 1 25
funcionará em qualquer lugar, exceto IE e Edge (lá retornará ao primeiro quadro estático). Os tamanhos dos arquivos são enormes, mas esse é o preço da codificação sem perdas real.
- Olibx264rgbcodec também deve ser mencionado - usando-ovai será a maneira correta de codificar as cores RGB precisas quando/se os navegadores suportarem.