¿Qué parámetros de compresión de video H.264 / H.265 proporcionan calidad equivalente a DVD con mejor compresión?


11

Tengo una caja de discos de video DVD de la cual trato de deshacerme mientras me gustaría conservar los videos al convertirlos en archivos MP4 para almacenarlos en un disco duro.

Considerando la superioridad de los modernos algoritmos de compresión H.264 AVC y H.265 HEVC sobre el DVD-MPEG2 estándar, espero ahorrar espacio en el disco duro al comprimir el video y ahorrar ~ 99% de la calidad original del DVD.

Qué

  • Parámetros de compresión H.264 (FFMPEG + libx264)
  • Parámetros de compresión H.265 (FFMPEG + libx265)

debo usar para lograr mi objetivo?

Por parámetros me refiero a los valores de CBR / CRF, el preajuste (sin veryslow / placebo por favor), banderas, etc.

PD: Prefiero restringir el caso con el uso -pix_fmt yuv420py -profile:v baseline -level 3.0garantizar que el archivo se reproduzca bien en todos los dispositivos, incluidos los dispositivos antiguos que dependen de chips de decodificador de hardware antiguos. El uso de una frecuencia de cuadros I algo incrementada (usando el -gparámetro) también es deseable para facilitar el uso de medios de baja velocidad y alta latencia.

Para HEVC, también preferiría usar parámetros que garanticen una reproducción fluida acelerada por hardware en dispositivos que lo admitan, pero no pretendo centrarme en esta restricción, ya que no he visto ningún dispositivo que ofrezca H.265 acelerado por hardware decodificación en absoluto todavía.

Respuestas:


14

Tenga en cuenta que para esto, siempre debe usar la última versión de ffmpeg y preferiblemente compilarla usted mismo . Esto le da acceso a la libx265 y libfdk-aac más recientes para la codificación de audio.

Además, el ahorro en la velocidad de datos será bastante drástico si va de un DVD de ~ 10 MBit / s a ​​alrededor de 1–2 MBit / s para video H.264 y 0.5–1 MBit / s para video H.265. Cambiar la calidad en los pasos a continuación puede influir en las tasas de bits, pero aún así la reducción de datos debería ser significativa.

H.264

Para el control de calidad / velocidad, desea utilizar el modo CRF en libx264 en lugar de una tasa de bits constante. El uso de CRF garantiza que se mantenga una calidad promedio, independiente de la resolución de video original o su complejidad. La velocidad de bits constante solo es realmente útil si está limitado por el medio de transmisión (por ejemplo, la velocidad del disco duro, el rendimiento de Internet).

Elegir el valor CRF es la parte difícil. Requiere que mires la salida. El valor predeterminado para libx264 (23) ofrece una compensación bastante buena entre tamaño y calidad. Pero dado que su fuente original ya está comprimida (y no con una muy buena calidad en comparación con los Blu-rays), es posible que desee cambiar el CRF para que sea un poco más bajo, como 20. Esto aumentará la tasa de bits necesaria en aproximadamente un tercio .

Elija el preajuste de acuerdo con el tiempo que desea esperar. slowParece un buen valor aquí.

ffmpeg -i input \
-c:v libx264 -crf 20 -pix_fmt yuv420p \
-x264-params keyint=240:min-keyint=20 \
-preset:v slow -profile:v baseline -level 3.0 \
-c:a libfdk_aac -vbr 4 \
output.mp4

El codificador incorporado ffmpeg AAC se puede usar si libfdk-aac no está disponible. Usar en -c:a aac -strict experimental -b:a 128klugar de -c:a libfdk_aac -vbr 4.

H.265

La investigación sugiere que el uso de HEVC conducirá a un ahorro de hasta el 74% de la tasa de bits en comparación con H.264. Esto se basa en datos de visualización subjetivos de secuencias Ultra-HD. Por supuesto, depende de la complejidad temporal del contenido de origen, y la cantidad de datos guardados no será tan alta para secuencias difíciles de codificar. De cualquier manera, puede decir con seguridad que la reducción de datos del 50% es absolutamente posible.

El CRF predeterminado para libx265 es 28. Al usar el mismo contenido de origen, se obtiene aproximadamente la mitad de la tasa de bits en comparación con libx264 en CRF 23. Esto es independiente de la tasa de bits real, es decir, si la versión H.264 toma 1.5 MBit / s, entonces H.265 usará alrededor de 750 kBit / s, pero es 750 kBit / s vs. 350 kBit / s para otra secuencia. Lo ejecuté en un par de secuencias con resolución DVD-PAL y no pude notar la diferencia en términos de calidad.

ffmpeg -i input \
-c:v libx265 -pix_fmt yuv420p \
-x265-params crf=28:keyint=240:min-keyint=20 \
-preset:v slow \
-c:a libfdk_aac -vbr 4 \
output.mp4

Para obtener más información, aquí están los recursos relevantes:


Gracias por una buena respuesta. ¿Qué significa keyint prácticamente por cierto?
Ivan

1
El keyinten x264 / X265 es el intervalo entre IDR-tramas, es decir, el intervalo entre fotogramas clave a la que puede que el decodificador de actualización. En el medio, puede haber cuadros I sin fotogramas clave, por ejemplo, cuando se produce un corte de escena. Es equivalente al -gparámetro si no me equivoco.
slhck

Por cierto, @slhck, algo que me ha sorprendido en su respuesta: la atención que presta a la elección de una biblioteca de codificación AAC. Solía ​​pensar que todos son casi iguales y dan poca o ninguna diferencia, que las cosas son simples en la parte de audio (solo elija la tasa de bits y listo y que todos los códecs con pérdidas principales como MP3, AAC y Vorbis suenen casi o exactamente lo mismo a 128 kbps y superior). ¿Quiere decir que en realidad hay una diferencia notable entre libfdk-aac y aac ordinario?
Ivan

1
Las construcciones de @Ivan The Zeranoe definitivamente deberían permitirte hacer lo -c:a aac -strict experimentalque se indica en mi respuesta. Y estoy de acuerdo, no trataría de construirlo en Windows.
slhck

2
@Ivan (1er comentario): Ver ffmpeg-wiki : "Basado en la calidad producida de mayor a libopus > libvorbis >= libfdk_aac > aac > libmp3lame >= libfaac >= eac3/ac3 > libtwolame > vorbis > mp2 > wmav2/wmav1menor: solo para AAC: (porque es un poco confuso, con 3 codificadores disponibles): libfdk_aac > aac > libfaacel signo> = significa mayor o igual calidad."
Golar Ramblar
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.