wie man h264_omx auf RaspberryPi verwendet

Ich verwende RaspberryPi 1gen B+ für den Push-Stream zum Web über rtmp. Aber ich finde, dass meine CPU-Auslastung auf über 90% gestiegen ist. So benutze ich es:

ffmpeg -re -f concat -safe 0 -i playlist.txt -vcodec copy -acodec aac -f flv "rtmp://example.com:1060"

Also möchte ich die GPU zum Decodieren/Codieren verwenden. Nach der Google-Recherche habe ich "h264_omx" gefunden und das h264_omx implementiert:

pi@pi:/usr/src/ffmpeg $ sudo ./configure --enable-omx --enable-omx-rpi
sudo make
sudo make install

also verwende ich:

ffmpeg -re -f concat -safe 0 -i playlist.txt -vcodec h264_omx -acodec aac -f flv "rtmp://example.com:1060"

hier ist die ausgabe:Geben Sie hier die Bildbeschreibung ein

Aber die CPU-Auslastung liegt immer noch bei 90%+, was noch schlimmer ist, das Video wird undeutlich und hat nur noch 5fps.

Also, was ist los mit mir? Ist es für 1gen B+ möglich, einen Hardware-Codec zu verwenden?

Die Videokodierung benötigt immer mehr *PU als das Kopieren eines Videos. Es ist etwas anderes - Netzwerk-I/O vielleicht.
@Mulvya das Upload-Netzwerk ist in Ordnung, ich habe mit meinem Laptop getestet, um Steam ins Web zu bringen, und es funktioniert gut. Möge es I/O sein. Danke~

Antworten (1)

Die erste Priorität besteht hier darin, den Engpass zu ermitteln, insbesondere zuerst auf der Codierungsseite, und dann an anderer Stelle weiterzumachen.

Dies wird durch den Kommentar zum abgehackten Videostream vermerkt, der auf das Überspringen von Frames hinweist.

Dazu müssen wir die Aufgabe isolieren, die die größte CPU-Last beansprucht.

Versuchen Sie, das FFmpeg-Snippet nur mit Audiocodierung auszuführen, während Sie den Videostream kopieren, und überwachen Sie dann die CPU-Auslastung:

ffmpeg -re -f concat -safe 0 -i playlist.txt -c:v copy -c:a aac -f flv "rtmp://example.com:1060"

Dadurch entfällt die Videokodierungsphase, siehe also die neue CPU-Last.

Aktivieren Sie im nächsten Schritt den Video-Encoder, aber kopieren Sie den Audiostream intakt:

ffmpeg -re -f concat -safe 0 -i playlist.txt -c:v h264_omx -c:a copy -f flv "rtmp://example.com:1060"

Überwachen Sie jetzt mit diesem Ausschnitt erneut die CPU-Auslastung.

Sie werden wahrscheinlich feststellen, dass entweder die Arbeitslast (Video- oder Audiocodierung) den größeren Anteil der CPU-Last beansprucht, und von dort aus können Sie dann den/die Encoder nach Belieben einstellen.

Um Encoder-Optionen für den h264_omxEncoder anzuzeigen, führen Sie Folgendes aus:

ffmpeg -h encoder=h264_omx

Und für den aacEncoder:

ffmpeg -h encoder=aac

Tunen Sie dann den Übeltäter mit einem akzeptablen Preset und/oder Einstellungen, bis ein akzeptabler Kompromiss zwischen Qualität und CPU-Last erreicht ist . Beachten Sie, dass einige Funktionen wie automatisch eingefügte Filter dazu neigen, auf der CPU ausgeführt zu werden, was zur hohen Belastung auf der Seite des Encoders beiträgt.

Sie können dies bestätigen, indem Sie Folgendes ausführen:

ffmpeg -loglevel debug -re -f concat -safe 0 -i playlist.txt -c:v h264_omx -c:a aac -f flv "rtmp://example.com:1060"

Und Überwachung der Ausgabe. Erfahren Sie, welche Filter automatisch eingefügt werden, und prüfen Sie, ob das Ändern der Filterzeichenfolgen (über -vf) die Prozessorlast unterstützt.

Danke für Ihre Hilfe. Ich habe gestern mit debuggt -an, die CPU-Auslastung ist auf normal gesunken. Die Audio-Transcodierung ist also der Schlüssel zu meiner Frage. Wenn ich also nur Audio auf dem PC in AAC transcodiere, ist das Problem weg. Danke trotzdem.
Gern geschehen. Wenn Sie noch etwas brauchen, lassen Sie es uns wissen.