Streaming mit geringer Latenz mithilfe von ffmpeg

Streaming mit geringer Latenz mithilfe von ffmpeg

Vor kurzem habe ich versucht, einen Remote-Desktop zu streamen mitffmpeg. Ziel ist es, die Anzeige auf einem Computerbildschirm an einen anderen Computer senden zu können und dabei Einstellungen wie die Ausgabeauflösung usw. auswählen zu können.

Es ist ein kleinesfast arbeitenProof of Concept. Wenn ich fertig bin, kann ich VNC ersetzen durchffmpegStreaming mitx2xoderSynergiezur Weiterleitung von Tastatur- und Mausereignissen.

Jetzt kann ich mit dem Streaming beginnen mit:

ffmpeg -f x11grab -s "1600x1200" -i ":0" \
    -f alsa -i pulse \
    -s 800x600 -b 200k -f mpegts - \
    | mplayer -cache 1024 -
#
# I have pulse audio configured so that `-i pulse` will
# The output can sent through for example netcat to another host
#

Die Latenz hängt von den Kodierungsoptionen ab. Mit diesen Optionen beträgt die Verzögerung zwischen der Bildschirmaktualisierung und der Videoaktualisierung etwa 800 ms.

Was ich erreichen möchte:

  • Erreichen Sie eine Latenz von100 ms.
  • Wenn mplayerausgeführt wird, beschwert es sich, dass es nicht in Lear-Streams suchen kann und es gibtkein Ton. Ich habe immer noch Ton, wenn ich die Ausgabe in einer Datei speichere und abspiele.

    BEARBEITEN: Nach dem Hinzufügen werden -cachein linearen Streams zu suchende Nachrichten nicht mehr angezeigt. Durch Ändern des Ausgabeformats -f mpegtsfunktioniert das Audio.

  • Es wäre toll, wenn die Kodierung nicht 100 % eines CPU-Kerns beanspruchen würde (sekundäres Ziel).

Nach einigen Recherchen im Internet glaube ich, dass diese Probleme mit den Codecs/Optionen zusammenhängen, die ich verwenden sollte. Allerdings kenne ich die Unterschiede zwischen den vorhandenen Möglichkeiten nicht. Könnten Sie mir einige Optionen nennen, die meine Probleme lösen würden? Ist VLC außerdem eine gute Alternative und wenn ja, welche Befehle wären die entsprechenden, um von einem Desktop auf einen anderen zu streamen?

Antwort1

Das Streamen von DesktopA zu DesktopB ist ein interessantes Problem. Wenn Sie kein Video/Audio benötigen, sollten Sie sich stattdessen das NX-Protokoll ansehen. Es ist viel effizienter als VNC. FreeNX ist ein Server und NoMachine und andere stellen NX-Clients her. Es gibt andere Server – kostenlose und kommerzielle.

Es wird auch an einem hochleistungsfähigen Remote-Desktop (SPICE) gearbeitet, der als F/LOSS-Projekt fungiert. Ich glaube, Redhat übernimmt die Führung.http://spice-space.org/

Ich weiß nicht, ob das nützliche Antworten sind, aber vielleicht nur Hinweise zu etwas Nützlicherem?

Beim Streamen von Videos muss wahrscheinlich der Overhead eines vollständigen Desktopprotokolls vermieden werden.

Antwort2

Ich musste kürzlich Streaming mit geringer Latenz einrichten, wobei die Anforderungen noch strenger waren als beim ursprünglichen Verfasser (OP). Ich habe eine Lösung entwickelt, die gut genug funktioniert, um sie als zusätzlichen Monitor für meinen Laptop zu verwenden, mit reibungsloser Maus- und Tastatureingabe.

Auf der Sendeseite habe ich den folgenden ffmpegBefehl verwendet:

ffmpeg -video_size 1920x1080 -r 30 -framerate 30 -f x11grab -i :0.0+0x0 \
    -b:v 40M -maxrate 50M -bufsize 200M \
    -field_order tt -fflags nobuffer -threads 1 \
    -vcodec mpeg4 -g 100 -r 30 -bf 0 -mbd bits -flags +aic+mv4+low_delay \
    -thread_type slice -slices 1 -level 32 -strict experimental -f_strict experimental \
    -syncpoints none -f nut "tcp://10.0.0.1:1234"

Der kritische Teil dieses Befehls ist das Argument -g 100, das Zeit zwischen den Keyframes hinzufügt und so die Stream-Bitrate verringert.

Auf der Empfangsseite habe ich ffplay(im Lieferumfang enthalten ffmpeg) verwendet, um den Stream auf einem Raspberry Pi 3 anzuzeigen:

ffplay -autoexit -flags low_delay -framedrop -strict experimental \
    -vf setpts=0 -tcp_nodelay 1 "tcp://10.0.0.1:1234\?listen"

Mir ist zwar bewusst, dass die ursprüngliche Frage über ein Jahrzehnt alt ist und sich die dem durchschnittlichen Benutzer zur Verfügung stehende Verarbeitungsleistung seitdem erheblich verbessert hat, doch diese beiden Befehle bieten einen sinnvollen Ausgangspunkt für jeden, der einen Stream mit geringer Latenz über ein lokales Netzwerk einrichten möchte, selbst auf Low-End-Hardware.

verwandte Informationen