Verlustfreies universelles Videoformat


14

Ich versuche, das am besten geeignete verlustfreie Videoformat für 1280x720 25fps-Videos zu finden. Das Video hat 4 Minuten. Sound wird 320 kbps mp3 sein, das ist keine große Sache. Ideale Bedingungen:

  • Verlustfrei (kann wahrnehmungslos verlustfrei sein)
  • Container + Codec kann auf den meisten Plattformen gespielt werden
  • Container + Codec kann auf modernen DVD-Playern abgespielt werden (unterstützt andere Formate als DVD)
  • Die Größe beträgt weniger als 700 MB

Ist das überhaupt möglich? Ich habe bereits drei Tage ohne zufriedenstellende Ergebnisse gekämpft und sogar 12-GB-Dateien erhalten (scheint viel zu sein - 3 GB / Minute).



4
Es tut mir leid, aber Sie können praktisch kein (visuell) verlustfreies 720p-Video von 4 Minuten erhalten, das auf weniger als 700 MB komprimiert ist (ich habe hier Megabyte angenommen, nicht "mb", was "Bit" bedeuten würde). Warum haben Sie eine solche Einschränkung? Kann das Video nicht h.264-codiert werden?
Slhck

Ja, MB, Entschuldigung für die Verwirrung. Ich muss cca 5 Videos x 4 Minuten in 4 GB einpassen (mittlere Einschränkungen).
Mrkva

2
Da Sie 12-GB-Dateien erhalten, gehe ich davon aus, dass Sie eine Farbtiefe von 24 Bit verwenden. Der unkomprimierte Videodatenstrom beträgt ca. 4 GB pro Minute. Das ist eine riesige Datenmenge. Was Sie wollen, ist etwa 170 MB pro Minute. Unabhängig vom gewählten Codec können Sie dies nur mit einer statischen Szene ohne viel Bewegung erreichen. Ich fürchte, Sie müssen die Vorrichtung lockern, um verlustfrei zu sein, die Bildrate zu verringern oder eine größere Datei zu tolerieren.
Marco

Können Sie klarstellen, dass "Container + Codec auf modernen DVD-Playern abgespielt werden kann (die andere Formate als DVD unterstützen)"?
Llogan

Antworten:


24

Das beste aktuelle, mathematisch verlustfreie Format, das ich kenne, ist huffyuv, aber das erzeugt unglaublich große Dateien und wäre nicht mit viel kompatibel. Für die Aufzeichnung kann ffmpeg dies tun mit:

ffmpeg -i input -c:v huffyuv -c:a libmp3lame -b:a 320k output.avi

X264, der Open-Source-Encoder h.264, verfügt über einen verlustfreien Modus. Dies kann in einen MP4-Container passen und sollte mit den meisten in den letzten Jahren hergestellten Hardware kompatibel sein. Der erste Befehl gibt eine schnelle Codierungsgeschwindigkeit, aber eine große Datei an. Der zweite Befehl wird viel länger dauern, aber die Datei sollte ungefähr halb so groß sein wie die schnell codierte (sie wird jedoch immer noch ziemlich groß sein):

ffmpeg -i input -c:v libx264 -crf 0 -preset ultrafast -c:a libmp3lame -b:a 320k output.mp4

ffmpeg -i input -c:v libx264 -crf 0 -preset veryslow -c:a libmp3lame -b:a 320k output.mp4

Wenn Sie dadurch keine ausreichend kleine Datei erhalten, wird ein CRF von 18 im Allgemeinen als "visuell verlustfrei" betrachtet:

ffmpeg -i input -c:v libx264 -crf 18 -preset veryfast -c:a libmp3lame -b:a 320k output.mp4

Im Allgemeinen empfehle ich die sehr schnelle Voreinstellung für die Codierung mit x264. Meiner Erfahrung nach bietet sie den besten Kompromiss zwischen Geschwindigkeit und Größe (es gibt einen großen Rückgang der Dateigröße zwischen superschnell und sehr schnell, langsamer und inkrementeller). Allgemeiner Rat ist, die langsamste Voreinstellung zu verwenden, die Sie verarbeiten können. Die Voreinstellungen sind: ultraschnell, superschnell, sehr schnell, schneller, schnell, mittel, langsam, langsamer, sehr langsam.

Sehen Sie hier für eine tiefergehende Anleitung zur x264 - Codierung.


2
Schlagen Sie nicht veryfastals guten Standard für verlustbehaftetes x264 vor. mediumist ein guter Mittelweg, aber ich benutze normalerweise veryslowfür die endgültige Kodierung von irgendetwas. Auch huffyuvist nicht einmal sehr schnell, ich würde es nicht für etwas anderes als Kompatibilität empfehlen.
Peter Cordes

ffmpeg hat einige andere verlustfreie Codecs, die es möglicherweise wert sind, ausprobiert zu werden [FFv1 fällt mir ein]. GL!
Rogerdpack

Libx264 verkleinert die beiden Farbkanäle (in YUV UV) nicht um die Hälfte in beide Richtungen, selbst wenn Sie einen CRF von 0 verwenden, sodass er nicht wirklich verlustfrei ist. Bei Rundungsfehlern ist nicht garantiert, dass die Daten nach einer Runde x264-Komprimierung Bit für Bit indentisch sind.
Adisak

1
In meinen Experimenten mit ffmpeg 3.4.1 verwendete libx264 das Pixelformat yuv444, wobei "444" bedeutet, dass der U, V-Teil nicht heruntergesampelt wird. Und das OP hat ausdrücklich nichts gegen Rundungsfehler: "Kann wahrnehmungslos verlustfrei sein". Also, @Adisak, Ihre Bedenken sind vernünftig, aber auf diese Antwort nicht anwendbar.
Jim DeLaHunt

ffmpeg und libx264 im YUV-Modus handeln ein YUV-Pixelformat basierend auf der Eingabe aus. Wenn die Eingabe also YUV 4: 2: 0 ist, ist dies auch das Ausgabepixelformat. Wenn der Eingang YUV 4: 4: 4 oder RGB ist, ist der Ausgang YUV 4: 4: 4.
Gyan

2

In diesen Tagen mag ich webm :

ffmpeg -i input.avi -c:v libvpx-vp9 -lossless 1 output.webm

Um schneller mit Multi-Core-Prozessoren zu konvertieren, habe ich gelesen, dass empfohlen wird, einen Thread weniger zu verwenden, als Sie von echten Kernen haben. Mit einem 8-Kern könnten Sie also 7 Threads wie folgt angeben:

ffmpeg -i input.avi -c:v libvpx-vp9 -threads 7 -lossless 1 output.webm

1
Ich verwende gerne die Umgebungsvariable% NUMBER_OF_PROCESSORS%, um die zu verwendende Thread-Anzahl zu bestimmen. Wenn die Anzahl 1 oder 2 ist, habe ich alle Prozessoren verwendet. Wenn die Anzahl 3 oder 4 ist, verwende ich alle bis auf einen Prozessor. Und wenn die Anzahl höher ist, verwende ich alle bis auf zwei Prozessoren für die Threadanzahl.
Adisak

1
Als DOS-Ausdruck sieht es folgendermaßen aus: if "% ADJUSTED_CPUCOUNT%" EQU "" (if% NUMBER_OF_PROCESSORS% EQU 1 (set ADJUSTED_CPUCOUNT = 1) else if% NUMBER_OF_PROCESSORS% EQU 2 (set ADJUSTED_CPUCOUNT =% 2) EQU 3 (setze ADJUSTED_CPUCOUNT = 2) sonst wenn% NUMBER_OF_PROCESSORS% EQU 4 (setze ADJUSTED_CPUCOUNT = 3) sonst (setze / A ADJUSTED_CPUCOUNT =% NUMBER_OF_PROCESSORS% -2)
Adisak

1
superuser.com/questions/155305/… sagt, dass ffmpeg bereits die optimale Anzahl von Threads auswählt
Boris

Eine bessere Wahl als webm (heutzutage) ist vielleicht das av1- Format.
LonnieBest

-1
# BEHÄLTER

Um die volle Kompatibilität mit DVD-Playern zu gewährleisten, müssen Sie das MPEG-2-Format, den Container, die Einschränkungen und die Codecs verwenden. Ich denke, "moderne Player" bedeutet "mp4" -Kompatibilität, was im Grunde und meistens ein mp4-Dateispieler ist - H.264, MPEG-4, AVC => libx264
Lesen Sie mehr: https://de.wikipedia.org/wiki /H.264

# VIDEO

Werfen Sie einen Blick auf https://trac.ffmpeg.org/wiki/Encode/H.264 , vor allem den Teil , in dem es um „Profil“ und „Ebene“, um die Kompatibilität
verwenden -profile:v high -level 4.0sollte es tun

# AUDIO

Vermeiden Sie die Neucodierung von Audiospuren mit verlustbehafteten Codecs - jedes MP3-Format ist verlustbehaftet, sogar 320 KBit / s.
Verwenden Sie -c:a copystattdessen.

Bisher hat es einen ziemlich guten Job für mich gemacht. Keine Synchronisierungsprobleme.
Audio-Streams sind nicht an Keyframes gebunden. Genaue Schnitte sind möglich.
Wenn Ihre Audiospur mit einer Abtastrate von 44 kHz aufgenommen wurde, verwenden Sie max. 256 KBit / s

Verwenden Sie verlustbehaftete Codecs nur für die endgültige Codierung Ihres Videos, wenn Sie bestimmte Voraussetzungen erfüllen müssen.

Ich habe von einigen Problemen mit der Audiosynchronisierung gehört, aber es sieht so aus, als ob das Hauptproblem darin bestand, dass es sich um geschütztes Material (!) Handelte.

# Endlich

Ich würde so etwas bevorzugen:
ffmpeg -i input -c:v libx264 -crf 5 -preset faster -profile:v high -level 4.0 -c:a copy output.mp4


Option "-level 4.0" wird nicht benötigt. Der Pegel in x264 wird basierend auf Auflösung und FPS bestimmt. Daher macht es normalerweise keinen Sinn, ihn manuell einzustellen. Dadurch wird nichts verbessert. Soweit ich weiß, kann ffmpeg den korrekten Pegel automatisch einstellen. Wenn Sie also keinen guten Grund haben, ihn zu erzwingen und vollständig zu verstehen, wie der Pegel basierend auf FPS und Auflösung ausgewählt wird, sollten Sie die Option "-level" nicht verwenden. Wenn Sie sich für höchste Kompatibilität interessieren, verwenden Sie stattdessen "Basis" -Profil "Hoch".
Lissanro Rayen
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.