it-swarm.com.de

So ändern Sie die Einstellungen für ffmpeg -threads

Arbeiten an einer Tube Seite. Ich starte Videos durch ffmpeg auf einem Linux dedizierten Server zum Konvertieren zu mp4 .

Die Serverspezifikationen:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 60
Stepping:              3
CPU MHz:               3491.749
BogoMIPS:              6983.49
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7

Das Problem beim Testen ist, dass selbst wenn nur 4-5 auf einmal ausgeführt werden, die Auslastung des Servers schnell auf durchschnittlich 36 steigt. Dies ist nur eine einzelne Person. Ich stelle mir vor, wenn es geöffnet wird, werden viele Leute auf einmal hochladen.

Es scheint, dass ffmpeg versucht, alle für eine Konvertierung verfügbaren Ressourcen zu nutzen.

Ich habe gehört, dass Sie die Einstellung -threads ändern können, aber ich kann sie nicht finden. Ich habe einen 8-CPU-Server. Es wird nur für Konvertierungen verwendet, daher habe ich gehört, dass die beste Einstellung zwischen 2 und 4 liegt. Ich kann es testen.

Aber wie ändere ich diese Einstellung? Alles, was ich online sehe, behandelt diese Einstellung, aber nicht die Schritte, um sie zu ändern.

14
Jacob

Das Options-Flag, das Sie wollen, ist wirklich nur -threads und Sie würden es so verwenden (für nur einen Thread):

ffmpeg -i somefile.wmv -c:a libfdk_aac -c:v libx264  -threads 1 transcoded.mp4

Es gibt jedoch einige Feinheiten, die die Serverauslastung und -betriebszeit erhöhen, z. B. die Neuskalierung, das Anwenden von Filtern und die endgültige Bildqualität/Bildrate - ganz zu schweigen von der Tatsache, dass einige VM - Architekturen tatsächlich lesen und verarbeiten schreibe alles zweimal (einmal nativ und einmal virtuell !!!)

Hier sind ein paar Tipps, um Ihre Geschwindigkeit zu steigern:

  1. verwenden Sie eine Warteschlange, damit immer nur ein Element gleichzeitig transkodiert wird
  2. fordern Sie kleinere Dateien von Ihren Benutzern an
  3. schöpfen Sie die volle Leistung Ihrer Maschine aus, indem Sie:
    • lesen und Schreiben von einer Ramdisk
    • wechsel zu Bare Metal für Transcodierungsaufgaben
    • benutze -threads 0

Was auch immer Sie tun, informieren Sie Ihre Benutzer über den Transcodierungsprozess, da dies nur einige Zeit in Anspruch nimmt. (I.J.T.T.)

[Befehl bearbeitet, um LordNeckbeards Kommentar wiederzugeben]

17
denjello

Das mag ein bisschen alt sein, aber das klingt nach einer perfekten Aufgabe für einen Container wie Docker.

  • Lass ffmpeg mit full horsepower laufen (wie denjello es nannte)
  • aber lass es in docker laufen

Jetzt können Sie den Ressourcenverbrauch einer einzelnen ffmpeg-Instanz einschränken, ohne auch nur die ffmpeg-Befehlszeilenoptionen zu verwenden. Und nicht nur CPU, sondern auch Speicher und IOs.

Mehr noch: Vielleicht haben Sie verschiedene Aufgaben, die möglicherweise im Hintergrund ausgeführt werden, und es ist Ihnen egal, wie lange sie dauern, und Sie haben Aufgaben, die schnell ausgeführt werden sollen, damit Sie verschiedene Aufgaben bewerten können.

Siehe https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources

Es gibt bereits ein vordefiniertes ffmpeg-Image auf Github: https://github.com/jrottenberg/ffmpeg

docker run jrottenberg/ffmpeg \
        -i http://url/to/media.mp4 \
        -stats \
        $ffmpeg_options  - > out.mp4

Eine einzelne Konvertierung wird aufgrund des Overheads wahrscheinlich langsamer ausgeführt. Wenn Sie jedoch mehrere Instanzen gleichzeitig ausführen, kann dies ein großer Vorteil sein. Dies lässt sich sehr gut skalieren, ganz zu schweigen von der verbesserten Sicherheit, da jede Aufgabe vom zugrunde liegenden Betriebssystem isoliert ist.

3