Bases baseadas em tempo em vez de baseadas em quadros (com diferentes CRF) para codificação ffmpeg + x264 / x265?

1

x264 / 5 tem um parâmetro zones para oferecer suporte a diferentes configurações de codificação para parte de um vídeo, mas aceita somente números de quadros, não timestamps.

Este é um pequeno inconveniente com vídeo de taxa de quadros constantes, mas um grande inconveniente ao usar um filtro ffmpeg como mpdecimate para eliminar (quase) quadros duplicados exatos. Ou com vídeo VFR em geral. (E se não funcionar com ffmpeg , apenas uma opção para o CLI independente, isso também seria um grande inconveniente.)

libx265 (e libx264) tem uma API que permite ao chamador reconfigurar alguns parâmetros do encoder em tempo real, portanto os encapsuladores do ffmpeg libx264 e libx265 poderiam em teoria ajustar o CRF ou outros parâmetros do encoder em um determinado intervalo de registros de data e hora, separadamente do recurso de "zonas" do x264.

O ffmpeg tem intervalos de início / parada para os filtros, portanto, sua análise de linha de comando / opção provavelmente tem a maior parte do código necessário para lidar com isso.

Mas, AFAIK, isso não está atualmente implementado. ffmpeg -h encoder=libx265 não mostra nada relevante; -x265-params é analisado para configurar o codificador uma vez na inicialização e há apenas algumas outras opções suportadas. ( libx264 tem muitas outras opções de ffmpeg, mas não qualquer tipo de zona que eu possa ver).

Existe alguma maneira alternativa de codificar com -vf mpdecimate (ou uma fonte VFR arbitrária) e ter CRF30 para a maior parte do vídeo, mas CRF = 24 de 00:30:00 para 00:30:30 , por exemplo?

No meu caso, há um clipe visualmente interessante que vale a pena gastar bits extras em qualidade, e eu prefiro não cortar o vídeo e usar MKV ordenou capítulos apenas para fazer isso acontecer. Embora se houver alguma sintaxe direta de ffmpeg para fazer isso (especialmente em uma passagem), isso seria bom. Algo que pode caber razoavelmente em um shell bash "one liner" é o que eu estou querendo.

Para fazer isso com zonas, acho que preciso executar o vídeo por meio de mpdecimate e descobrir os números de quadros do início / fim dessa região de tempo. E eu acho que precisaria rodar o vídeo através do x265 CLI independente, porque acho que as zonas são um recurso do front-end de linha de comando, não da própria biblioteca. (E, portanto, não suportado via -x265-params para passar pares chave / valor para libx265).

Eu verifiquei se o Handbrake suportava qualquer tipo de zona, e não vejo isso na GUI. (E o pacote Handbrake 1.0.7 do Arch Linux ainda está usando x265 2.1, então ele nem tem as tabelas Lambda atualizadas de x265 2.4 , que saiu há mais de 9 meses. O Handbrake é legal, exceto por ter cópias antigas desatualizadas de codecs em vez de construir contra a versão do sistema, o que definitivamente ainda importa para x265.) / p>     

por Peter Cordes 21.01.2018 / 12:20

0 respostas