Estoy convirtiendo archivos de audio y video comprimidos sin pérdidas (Utvideo/LCPM) a códecs FFV1/FLAC usando MKV como contenedor para ahorrar espacio de almacenamiento sin comprometer la calidad. Estoy usando las funciones framemd5 de ffmpeg para garantizar que cada conversión sea 1:1 con la captura original en términos de salida.
El script por lotes es el siguiente:
for %%a in ("*.avi") do ffmpeg -i "%%a" -f framemd5 "%%~na.framemd5"
Sin embargo, cuando se utiliza FLAC como códec de audio, la parte de audio de las salidas framemd5 ya no coincide.
Aquí están las primeras 1001 líneas del framemd5 de una grabación de muestra:
https://pastebin.com/axcf3f0aLPCM originales
https://pastebin.com/3n75YTMjConversión FLAC
El problema parece ser queFLAC agrega metadatos adicionales y su propia suma de verificación, de modo que si bien el audio es supuestamente 1:1, framemd5 no lo reconoce como tal. No conozco bien la estructura de archivos de FLAC, por lo que no puedo verificarlo por mí mismo ni encontrar una solución alternativa.
¿Hay alguna forma de conciliar esto? ¿Puedo crear archivos framemd5 que sumen de verificación tanto el video como el audio entre Utvideo/LPCM y FFV1/FLAC como 1:1?
Esto es increíblemente frustrante. Quiero usar FLAC para comprimir el audio porque ya estoy intentando ahorrar la mayor cantidad de espacio posible.
Respuesta1
Esto no tiene nada que ver con los metadatos de la transmisión FLAC.
ffmpeg-allen framehash(framemd5 es una variante de framehash):
De forma predeterminada, los fotogramas de audio se convierten en audio sin formato firmado de 16 bits y los fotogramas de vídeo en vídeo sin formato antes de calcular el hash.
(NOTA: en el caso de una profundidad de bits mayor, deberá especificar el valor correspondientecodificador, Por ejemplo-c:a pcm_s24le después -f framemd5en los casos "A y B" para evitar que se realice una suma de comprobación en cuadros de audio "truncados").
Por lo tanto, la suma de verificación siempre se realiza en cuadros decodificados (y luego codificados, de una manera un tanto "falsa", como en los casos PCM o no), a menos que haya especificado algo como -c copy. Por lo tanto, los metadatos no "interferirían" con el hash aquí.
La verdadera causa del problema aquí es que, a diferencia del caso de un vídeo, el "cuadro" en este caso, cuando se aplica al flujo de audio, no se refiere a una sola muestra, sino a muestras en su conjunto que se agruparon en un paquete. Los paquetes pueden tener diferentes tamaños (número de muestras) dependiendo del codificador/muxer (valores predeterminados en su código) y, quizás, de la configuración del usuario.
Como puede ver en las líneas de salida, cada paquete en el flujo de audio de entrada tiene 1024 muestras en el caso de PCM, mientras que en el caso de FLAC, cada uno tiene 4608 muestras.
TL;DR. La solución aquí sería agregar -frame_size 1024después -c:a flacal codificar la "versión comprimida".
PD: No tengo idea de si, en cualquier caso, cambiar el tamaño de fotograma/paquete de la transmisión FLAC le causaría algún problema (por ejemplo, en la reproducción) o efectos secundarios indeseables, y puede preguntarse si puede o no cambiar el tamaño de fotograma/paquete de en su lugar, la transmisión PCM. Todo lo que puedo decir es que en el caso de PCM, sería un nivel de muxer en lugar de un nivel de codificador como en el caso de FLAC, lo que más o menos implica que es poco probable que sea configurable por el usuario .
Si bien puede que ayude o no, siempre puedes intentar mezclar (desde archivos de flujo sin formato o archivos WAVE/AIFF si es PCM, en lugar de remixar un archivo Matroska, ya que el proceso involucrado puede ser diferente) con otro Matroska. muxer en caso de que el tamaño de paquete/trama PCM-in-Matroksa (es decir, 1024) en ffmpeg no funcione bien cuando se usa para FLAC.
ACTUALIZACIÓN: Aparentemente, si usa el archivo WAVE como entrada, puede usar el-max_size demultiplexoropción (del WAVE dexmuer) para determinar qué tan grande es cada paquete cuando la secuencia se introduce en el muxer Matrokska. Tenga en cuenta que -max_sizeestá en bytes en lugar de muestras. Entonces, en este caso, puedes usar algo como ffmpeg ... -max_size 9216 -i path/to/input.wav ...(asegúrate de tener-max_size antes -i). No parece ver una opción similar disponible en los demultiplexores PCM sin formato (p. ej. s16le), por lo que primero deberá convertir el archivo de audio de entrada en un archivo WAVE si necesita usarlo en su lugar.
Árbitro. (ubicación en el código de los valores predeterminados):
https://github.com/FFmpeg/FFmpeg/blob/n5.1.2/libavcodec/flacenc.c#L314
https://github.com/FFmpeg/FFmpeg/blob/n5.1.2/libavformat/pcm.c#L27
https://github.com/FFmpeg/FFmpeg/blob/n5.1.2/libavformat/wavdec.c#L76