Führen Sie ffmpeg parallel aus, um die Synchronisierung beim RTSP-Streaming zu ermöglichen

Führen Sie ffmpeg parallel aus, um die Synchronisierung beim RTSP-Streaming zu ermöglichen

Ich versuche, Videos von drei Kameras über RTSP zu empfangen. Wir verwenden ffmpeg mit mehreren Ausgaben, wie ffmpeg erklärt, aber die Verzögerung ist schlimmer, als wenn wir drei verschiedene Linux-Prozesse direkt ausführen. Ist es möglich, eine ffmpeg-Befehlskombination zu finden, um den Aufnahmevorgang für die drei Kameras genau im richtigen Moment zu starten?

Derzeit verwenden wir diesen Befehl:

ffmpeg -rtsp_transport tcp -i rtsp://admin:[email protected]:554 -rtsp_transport tcp -i rtsp://admin:[email protected]:554 -rtsp_transport tcp -i rtsp://admin:[email protected]:554 -map 0  -vcodec copy video1.mp4 -map 1 -vcodec copy video2.mp4 -map 2  -vcodec copy video3.mp4  -y

Es ergibt sich eine Verzögerung von etwa 2 Sekunden.

Außerdem versuchen wir, alle Frames während der Aufnahme synchron zu halten, aber das scheint unmöglich, wenn sie von verschiedenen Geräten stammen, da es eine variable Verzögerung zwischen den Videos geben sollte …

Antwort1

Es gibt VIELE Dinge, die beeinflussen, wie das Video aus verschiedenen Quellen startet, interagiert und synchron bleibt (oder nicht):

  • Drei Kameras haben höchstwahrscheinlich nichtgenaudie gleiche Bildrate. Selbst eine Ungleichheit von 1/1000 in den Zeitbasen bei 25 fps ergibt alle 40 Sekunden einen Unterschied von einem kompletten Bild
  • Damit der Stream „startet“ (also das erste Ausgabebild erscheint), muss der Decoder auf das erste vollständige Bild (I-Frame) warten, auf dem die folgenden B-Frames und P-Frames aufgebaut werden können. Dies wird nach oben durch die GOP-Länge begrenzt, die bei Streaming-Kameras typischerweise im Bereich von 1-2 Sekunden liegt. Da I-Frames meistens nicht nur an jeder GOP-Grenze, sondern auch bei deutlich verändertem Bildinhalt („oportunistische“ I-Frames bei Szenenwechsel) eingeplant werden, ist es sehr unwahrscheinlich, dass sie gleichzeitig kommen. Dies bedeutet, dass bei einem Fall mit mehreren Eingängen die minimale Verzögerung die maximale Zeitdifferenz zwischen I-Frames in den verschiedenen Streams ist.Bedenken Sie: Ein h.264-Stream kann konstruktionsbedingt nicht ab einem bestimmten Zeitpunkt interpretiert werden, sondern nur ab dem ersten Keyframe (I-Frame) nach diesem Zeitpunkt.
  • Sind Sie sicher, dass Sie die richtige Frage stellen? Vielleicht wäre es besser, die Eingabephase viel früher zu starten, in ein Nur-Keyframe-Format zu dekodieren (das Ihnen einen sofortigen Start ermöglicht) und dann erneut zu kodieren? So wird in der Rundfunkbranche die minimale Latenz erreicht.

Die ersten beiden Punkte beantworten die Frage, warum unterschiedliche Prozesse scheinbar schneller starten als ein einzelner Prozess: Jeder einzelne muss auf ein einzelnes Keyframe warten, nicht auf alle drei.

verwandte Informationen