FFmpeg MP4 zu FLV zu langsam

Ich konvertiere .mp4-Dateien in .flv mit ffmpeg in Centos. Aber die Konvertierungszeit ist extrem zu langsam! Es dauert ungefähr 1,5 Stunden, um eine 500 MB große .mp4-Datei in eine .flv-Datei zu konvertieren. Ich verwende einen Linux vps mit 2 GB dediziertem RAM.

Ich verwende folgenden Code:

ffmpeg -i source.mp4 -c:v libx264 -ar 22050 -crf 28 destination.flv

Gibt es eine Möglichkeit, die Umstellungszeit zu beschleunigen? Jede Hilfe/Anregung wird geschätzt.

Antworten (3)

Angesichts der Tatsache, dass Sie ein VPS verwenden, ist dies keine Überraschung (vorausgesetzt, Sie haben nur einen einzelnen Kern mit 1-3 GHz) und Sie werden die Konvertierung nicht auf wenige Minuten reduzieren können. Sie können versuchen, es zu verwenden, -c:v libx264 -presets ultrafastaber ich schätze, das Codieren dauert immer noch etwa 45 bis 60 Minuten.

Entfernen Sie auch die -crfOption, wenn Sie eine Voreinstellung verwenden (sie wählen eine Standardeinstellung, die ein sehr gutes Gleichgewicht zwischen Geschwindigkeit und Qualität erzeugt. Ich empfehle nur, diesen Wert zu ändern, wenn Sie wissen, was es wirklich tut).

Beachten Sie, dass die Qualität, die Sie von diesem Preset erhalten, nicht gerade großartig ist. Wenn Sie für alles eine schnelle Kodierungsgeschwindigkeit BENÖTIGEN, dann entscheiden Sie sich dafür, wenn es nicht so wichtig ist, würde ich vorschlagen, fastoder fasteranstelle der ultrafastVoreinstellung zu verwenden.

Hallo, das hat das Zeitproblem gelöst. Die nach der Konvertierung generierte .flv-Datei ist jedoch etwa doppelt so groß wie die ursprüngliche .mp4-Datei im „ultrafast“-Modus und dreimal so groß wie die ursprüngliche .mp4-Datei im „fast“-Modus. :(
Das ist einer der Kompromisse, die Sie für die schnelle Konvertierung erhalten, Sie können keine kleinen, gut aussehenden Dateien und eine gute Komprimierung haben. In Ultrafast wird afaik auch eine kleinere Bitrate verwendet, was die geringere Größe erklären würde. -crf 28, was Sie zuvor verwendet haben, ist eine ziemlich aggressive Komprimierung. Normalerweise verwenden Sie etwas um die 20-22, wenn Sie mit konstanter Qualität codieren.
Warum empfehlen Sie das Entfernen, -crfwenn Sie ein verwenden -preset? Wenn entfernt, wird der Standardwert von -crf 23verwendet.
Weil die Voreinstellungen sehr gut mit den Einstellungen funktionieren, die sie in diesem Fall crf 23 bieten. Es gibt kaum einen Grund, diesen Wert zu ändern. Die Komprimierung erhöht sich mit einem höheren Preset, obwohl der crf-Wert für alle Presets gleich ist. Ich setze hier Amateurwissen voraus, wenn Sie mehr tun möchten, müssen Sie keine grundlegenden Fragen stellen, da Sie sehr schnell feststellen werden, wie diese (Grund-) Einstellungen tatsächlich funktionieren, und Ihre eigenen, auf Ihre Inhalte zugeschnittenen Feineinstellungen vornehmen.
hat die Frage bearbeitet, um dies widerzuspiegeln

Eine MP4-Datei enthält normalerweise H.264-Video und AAC-Audio, die beide mit dem FLV-Container kompatibel sind. Sie könnten einfach die Streams kopieren:

ffmpeg -i input.mp4 -c copy output.flv

Da Sie die Streams kopieren, geschieht dies so augenblicklich wie möglich und führt zu keinem Qualitätsverlust.

RAM ist nicht der kritische Teil einer Transcodierung, CPU ist es. Da es von Stream zu Stream arbeitet, muss tatsächlich ziemlich wenig Speicher benötigt werden, wenn der Codierer effizient arbeitet. Die Speichergeschwindigkeit spielt für den Arbeitsspeicher des Prozessors eine Rolle, aber nicht so sehr die Menge.

Die CPU (oder GPU bei GPU-optimierter Codierung) erledigt die ganze Arbeit, und höchstwahrscheinlich hat Ihr VPS nicht genügend Rechenleistung. Die Videokodierung ist extrem intensiv. Dies ist einer der Hauptgründe dafür, dass Videobearbeitungs-Workstations in der Regel große, leistungsstarke Computer sind, oft mit mehreren Grafikkarten, um die Last auf die GPU-Verarbeitung oder dedizierte Peripheriegeräte für die Hardwarecodierung zu verteilen.

Abhängig von der Länge des Videos, das durch diese 500-MB-Datei dargestellt wird, ist dies überhaupt nicht überraschend. Selbst auf meinem 2,9-GHz-Quad-Core-i7 dauert es immer noch ungefähr die 2- bis 3-fache Länge des Originalvideos, um eine hochwertige 2-Pass-VBR-Codierung abzuschließen (und alle 8 virtuellen Kerne sind die ganze Zeit über 99 % ohne Unterbrechung). Sie machen vielleicht nicht zwei Durchgänge, aber Sie haben wahrscheinlich auch nicht annähernd so viel Rechenleistung, die darauf geworfen wird.

Hallo @AJ Henderson, vielen Dank für die ausführlichen Informationen. Ich schätze es sehr.