
Ich konvertiere verlustfrei komprimierte Video- und Audiodateien (Utvideo/LCPM) in die Codecs FFV1/FLAC und verwende dabei MKV als Container, um Speicherplatz zu sparen, ohne Kompromisse bei der Qualität einzugehen. Ich verwende die FrameMD5-Funktionen von ffmpeg, um sicherzustellen, dass jede Konvertierung in Bezug auf die Ausgabe 1:1 mit der Originalaufnahme übereinstimmt.
Das Batch-Skript lautet wie folgt:
for %%a in ("*.avi") do ffmpeg -i "%%a" -f framemd5 "%%~na.framemd5"
Wenn Sie jedoch FLAC als Audiocodec verwenden, stimmt der Audioteil der FrameMD5-Ausgaben nicht mehr überein.
Hier sind die ersten 1001 Zeilen des Framemd5 einer Beispielaufnahme:
https://pastebin.com/axcf3f0aOriginal-LPCM
https://pastebin.com/3n75YTMjFLAC-Konvertierung
Das Problem scheint zu sein, dassFLAC fügt zusätzliche Metadaten und eine eigene Prüfsumme hinzu, sodass der Ton zwar angeblich 1:1 ist, von framemd5 aber nicht als solcher erkannt wird. Ich kenne mich mit der Dateistruktur von FLAC nicht gut aus, daher kann ich das selbst nicht wirklich überprüfen oder mir eine Problemumgehung ausdenken.
Gibt es eine Möglichkeit, dies zu vereinbaren? Kann ich FrameMD5-Dateien erstellen, die sowohl Video als auch Audio zwischen Utvideo/LPCM und FFV1/FLAC als 1:1-Prüfsummen berechnen?
Das ist unglaublich frustrierend. Ich möchte FLAC verwenden, um den Ton zu komprimieren, da ich sowieso versuche, so viel Platz wie möglich zu sparen.
Antwort1
Dies hat nichts mit den Metadaten des FLAC-Streams zu tun.
ffmpeg-all
auf Framehash(framemd5 ist eine Variante von Framehash):
Standardmäßig werden Audio-Frames in signiertes 16-Bit-Raw-Audio und Video-Frames in Raw-Video konvertiert, bevor der Hash berechnet wird.
(HINWEIS: Bei einer höheren Bittiefe müssen Sie die entsprechendeEncoder, Zum Beispiel-c:a pcm_s24le
nach -f framemd5
in den Fällen „A“ und „B“, um zu vermeiden, dass auf „abgeschnittenen“ Audio-Frames eine Prüfsumme gebildet wird.)
Die Prüfsumme wird also immer für dekodierte (und dann auf eine etwas „falsche“ Art und Weise wie im PCM-Fall kodierte) Frames berechnet, sofern Sie nichts wie angegeben haben -c copy
. Daher würden die Metadaten das Hashing hier nicht „stören“.
Die eigentliche Ursache des Problems liegt hier darin, dass sich der „Frame“ hier, anders als im Fall eines Videos, bei der Anwendung auf den Audiostream nicht auf ein einzelnes Sample bezieht, sondern auf Samples als Ganzes, die in einem Paket zusammengefasst wurden. Die Pakete können je nach Encoder/Muxer (Standardeinstellungen in ihrem Code) und möglicherweise je nach Benutzereinstellung unterschiedliche Größen (Anzahl der Samples) haben.
Wie Sie den Ausgabezeilen entnehmen können, verfügt jedes Paket im Audio-Eingangsstream bei PCM über 1024 Samples, während es bei FLAC jeweils 4608 Samples aufweist.
TL;DR. Die Lösung hier wäre, -frame_size 1024
nach -c:a flac
dem Kodieren der „komprimierten Version“ hinzuzufügen.
PS: Ich habe keine Ahnung, ob das Ändern der Frame-/Paketgröße des FLAC-Streams in irgendeinem Fall zu Problemen (z. B. bei der Wiedergabe)/unerwünschten Nebeneffekten führen würde, und Sie fragen sich vielleicht, ob Sie stattdessen die Frame-/Paketgröße des PCM-Streams ändern können. Ich kann nur sagen, dass es im Fall von PCM eine Sache auf Multiplexer-Ebene wäre und nicht eine Sache auf Encoder-Ebene wie im Fall von FLAC, was mehr oder weniger bedeutet, dass es wahrscheinlich nicht benutzerkonfigurierbar ist .
Auch wenn es helfen kann oder nicht, können Sie immer versuchen, es mit einem anderen Matroska-Muxer zu muxen (von RAW-Stream-Dateien oder WAVE/AIFF-Dateien, wenn es PCM ist, anstatt eine Matroska-Datei neu zu uxen, da die beteiligten Prozesse unterschiedlich sein können/sind), falls die PCM-in-Matroska-Paket-/Frame-Größe (d. h. 1024
) in ffmpeg bei Verwendung für FLAC nicht gut funktioniert.
UPDATE: Wenn Sie eine WAVE-Datei als Eingabe verwenden, können Sie anscheinend die-max_size
demuxenOption (des WAVE-Dexmuers), um zu bestimmen, wie groß jedes Paket ist, wenn der Stream in den Matrokska-Muxer eingespeist wird. Beachten Sie -max_size
jedoch, dass dies in Bytes und nicht in Samples angegeben ist. In diesem Fall können Sie also etwas wie Folgendes verwenden ffmpeg ... -max_size 9216 -i path/to/input.wav ...
(stellen Sie sicher, dass Sie Folgendes haben:-max_size
Vor -i
). Ich sehe in den Raw-PCM-Demuxern (z. B. s16le
) keine ähnliche Option, Sie müssen die Eingabe-Audiodatei also zuerst in eine WAVE-Datei umwandeln, wenn Sie diese stattdessen verwenden möchten.
Ref. (Position der Vorgaben im Code):
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