Ich führe einen ffserver-Prozess auf einer Linux-Maschine aus, um Video-Streaming überffmpeg. Allerdings kommt es beim Video-Streaming zu einer Verzögerung.ffserver-KonfigurationsdateiIch definiere Port 8090.
Befehlnetstat -tulnapgibt mir dies:
root@beagleboard:/etc# netstat -tulnap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address Stat e PID/Program name
tcp 0 0 0.0.0.0:68 0.0.0.0:* LIST EN 654/pump
tcp 0 0 0.0.0.0:111 0.0.0.0:* LIST EN 662/portmap
tcp 0 0 0.0.0.0:22 0.0.0.0:* LIST EN 698/dropbear
tcp 0 0 0.0.0.0:8090 0.0.0.0:* LIST EN 744/ffserver
tcp 0 52 192.168.1.104:22 192.168.1.111:10838 ESTA BLISHED 724/dropbear
udp 0 0 0.0.0.0:514 0.0.0.0:* 703/syslog-ng
udp 0 0 0.0.0.0:111 0.0.0.0:* 662/portmap
udp 0 0 0.0.0.0:60628 0.0.0.0:* 709/avahi-daemon: r
udp 0 0 0.0.0.0:5353 0.0.0.0:* 709/avahi-daemon: r
Wie Sie sehen, verwendet der FFServer-Prozess das TCP-Protokoll zur Übertragung und ich vermute, dass dies der Grund für die Verzögerung beim Videostreaming ist. Wie kann ich den Prozess zwingen, das UDP-Protokoll zu verwenden? Sollte ich den Port ändern?
Antwort1
Sie können ein Programm nicht einfach zwingen, UDP statt TCP zu verwenden, ohne Teile des Programms selbst neu zu schreiben. Diese Protokolle sind einfach zu unterschiedlich, um austauschbar zu sein.
TCP ist stream-orientiert (der Empfänger sieht alles als kontinuierlichen Stream in der genauen Reihenfolge, in der der Sender es ausgegeben hat); UDP ist datagrammorientiert (jedes Datagramm wird in einem separaten Paket gesendet und sie können sogar neu angeordnet werden).
TCP verfügt über eine Flusskontrolle, sodass der Sender (oder das Betriebssystem des Senders) genau weiß, wie schnell er Daten senden soll, ohne dass die Verbindung überläuft oder andere Verbindungen erheblich beeinträchtigt werden. Bei UDP gibt es nichts dergleichen – ein schlecht „gezwungenes“ Programm könnte beginnen, Gigabyte an Daten pro Sekunde über UDP zu senden, unabhängig von der Verbindungsgeschwindigkeit.
TCP verfügt über eine Neuübertragung, d. h. wenn ein Paket mittendrin verloren geht (z. B. weil das Netzwerk überlastet ist oder andere Probleme hat), wird es erneut gesendet. Wenn das Protokoll von einem zuverlässigen Transport abhängt und Sie es zwingen, über UDP zu laufen, kann die Verbindung vollständig abgebrochen werden, sobald mindestens ein einziges Paket verloren geht. (Und PaketeWilleverloren gehen; siehe Punkte 1 und 2 oben.)
Antwort2
Wie andere bereits erwähnt haben, handelt es sich bei UDP und TCP um grundlegend unterschiedliche Protokolle.
Wenn Sie jedochmussDaten über UDP statt TCP transportieren, können Sie ein Relay-Tool verwenden wiesocat. Sie können socat so konfigurieren, dass es auf eine TCP-Verbindung wartet und den Inhalt des TCP-Streams als UDP-Stream an einen anderen Host weiterleitet. Wenn der andere Host TCP-Verkehr erwartet, können Sie dort eine andere Instanz des Relays verwenden, um wieder auf TCP umzuwandeln. Dadurch wird das Wiederholungs- und Bestätigungsverhalten aus der Host-zu-Host-Verbindung entfernt. Wiederholungsversuche und Bestätigungen sind zwischen dem lokalen Relay-Tool und der lokalen Anwendung weiterhin vorhanden, aber es ist unwahrscheinlich, dass Sie Wiederholungsversuche auf einer lokalen Loopback-Verbindung sehen.
Dies wird Ihr Verzögerungsproblem jedoch wahrscheinlich nicht lösen. Wenn Ihre Anwendung so aufgebaut ist, dass sie TCP statt UDP verwendet, ist sie möglicherweise nicht tolerant gegenüber verlorenen Paketen. In diesem Fall kann dieser Hack zu instabilem Verhalten führen.
Antwort3
Sofern Sie keine sehr langsamen Verbindungen verwenden, liegt Ihr Verzögerungsproblem höchstwahrscheinlich an Ihrem Video-Codec.
Um Videos effizient zu komprimieren, müssen Sie prädiktive Kodierungen verwenden (siehedieser Artikel auf Wikipedia).
Prädiktive Kodierungen berechnen grundsätzlich Bilder aus früheren oder späteren Bildern. Dies hat folgende Auswirkungen:
Wenn Sie viele P-Frames verwenden (berechnet aus früheren Frames), kommt es zu einer Verzögerung vor der Anzeige des Videosbeginnt, da der Client auf das nächste vollständige Videobild (I-Frame) warten muss. Sobald der Stream jedoch hergestellt ist, können Sie das Video relativ verzögerungsfrei ansehen.
Wenn Sie B-Frames verwenden (berechnet aus früheren UND späteren Bildern), kommt es zu einer sehr großen Verzögerung: Zusätzlich zur anfänglichen Verzögerung von oben muss der Client warten, bis das nächste I-Frame die Wiedergabe vom letzten I-Frame aus startet. Dies führt zu Verzögerungen (der Client spielt das Video merklich später ab, als der Server es aufzeichnet/sendet, oft viele Sekunden). Wenn Sie das Video im laufenden Betrieb kodieren, kommt es auch zu einer Verzögerung vom Server – er muss auf das nächste I-Frame warten, um alles ab dem vorherigen I-Frame zu senden.
Bei den meisten Codecs können Sie die Verwendung von B- und P-Frames nach Ihren Bedürfnissen anpassen, allerdings müssen Sie dabei zwischen Verzögerung und Komprimierungseffizienz abwägen.
Wenn Sie über genügend Bandbreite verfügen, können Sie auch einen Codec ohne B-/P-Frames verwenden, wieMJPEG
Ein weiterer Grund für eine Verzögerung kann die Pufferung auf der Player-Seite sein, damit es bei einer ruckeligen Netzwerkübertragung nicht zu Störungen kommt. Bei vielen Videoplayern ist es möglich, die Puffergröße anzupassen.