Mehrere H.264-Videostreams in einer RTP-Sitzung

Question

Ich möchte die Videoquelle in einer Streaming-Videoanwendung dynamisch wechseln. Die verschiedenen Videoquellen haben jedoch einzigartige Bilddimensionen. Ich kann einzelne SDP-Dateien für jede Videoquelle erstellen, aber ich möchte sie in einer einzigen SDP-Datei kombinieren, so dass der Anzeigeclient die Größe des Anzeigefensters automatisch ändern könnte, wenn sich die Videoquelle ändert. Hier sind zwei Beispiel SDP-Dateien:

640x480.sdp:

 
v=0 
o=VideoServerIN IP4 192.168.0.2 
s=VideoStream640x480 
t=0 0 
c=IN IP4 192.168.0.2 
m=video 8000/2 RTP/AVP 96 
a=rtpmap:96 H264/90000 
a=fmtp:96 packetization-mode=0; profile-level-id=4D4033; sprop-parameter-sets=Z01AM5ZkBQHtCAAAAwAIAAADAYR4wZU=,aO48gJ== 
a=control:trackID=1 

960x480.sdp:

 
v=0 
o=VideoServerIN IP4 192.168.0.2 
s=VideoStream960x480 
t=0 0 
c=IN IP4 192.168.0.2 
m=video 8000/2 RTP/AVP 96 
a=rtpmap:96 H264/90000 
a=fmtp:96 packetization-mode=0; profile-level-id=4D4033; sprop-parameter-sets=J01AM5WwPA9sBAIA,KO4G8gA= 
a=control:trackID=1 

Wie können diese einzelnen Dateien in einer einzigen SDP-Datei kombiniert werden?

Answer 1

Die Parameter in Ihren beiden sdp-Beispielen sind sehr ähnlich - der Stream-Name und die Sprop-Parameter-Sets unterscheiden sich. Ich nehme an, Sie interessieren sich nicht für den Stream-Namen. Wenn müssen Sie separate sprop-Parameter-Sets und die Clients unterstützen die Standard gut können Sie separate dynamische Payload-Typen für jede Auflösung verwenden und einen einzigen SDP haben wie folgt:

 v=0 
    o=VideoServerIN IP4 192.168.0.2 
    s=VideoStream640x480 
    t=0 0 
    c=IN IP4 192.168.0.2 
    m=video 8000/2 RTP/AVP 96 97 
    a=rtpmap:96 H264/90000 
    a=fmtp:96 packetization-mode=0; profile-level-id=4D4033; sprop-parameter-sets=Z01AM5ZkBQHtCAAAAwAIAAADAYR4wZU=,aO48gJ== 
    a=rtpmap:97 H264/90000 
    a=fmtp:97 packetization-mode=0; profile-level-id=4D4033; sprop-parameter-sets=J01AM5WwPA9sBAIA,KO4G8gA= 
    a=control:trackID=1 

Ähnlich wie bei anderen Antworten, wenn Sie nicht tun eigentlich brauchen Sie die verschiedenen Stream-Namen oder die verschiedenen SPROP-Parameter-Sets, die Sie in der Lage sein sollten, Ihr erstes SDP- und Switch-Format Midstream zu verwenden. Ich kenne die tatsächliche Nutzlast von H.264 oder Ihrem speziellen Decoder nicht gut genug, um sicherzustellen, dass dies in Ihren Anwendungen funktioniert, aber in Videokonferenzanwendungen ist es sehr üblich, dynamisch zwischen Auflösungen zu wechseln, ohne eine Änderung zu signalisieren oder eine separate Dynamik zu erfordern Nutzlast-Typ.

Obwohl Sie zwei SDP-Dokumente verketten können, wie in einer anderen Antwort erwähnt, denke ich nicht, dass es in diesem Fall helfen wird. H.264 Decoder können zu einem Zeitpunkt, den ich glaube, nur mit einem einzigen Parameter für sprop-parameter-sets arbeiten. Da beide SDPs den gleichen Nutzlasttyp, den gleichen Quellport usw. hätten, wüsste der Empfänger nicht, wann er den Parameter sprop-parameter-sets verwenden soll. UPDATE: Beachten Sie, dass einige Implementierungen ihre Sproups in Band erhalten und nicht vom SDP (oder nur anfänglich vom SDP). Wenn das in Ihrer Umgebung der SDP gilt sprop-Parameter-Sets aktualisiert Inband werden kann

Referenzen:

1. RFC 3984 RTP Payload Format for H.264 Video
2. New proposed H.264 RTP Payload Format RFC 6184
3. RFC 4566 SDP: Session Description Protocol

[Es tut uns nicht geben Vollständig zitieren - fühlen Sie sich frei zu korrigieren]

Answer 2

Ich habe über den RFC (RFC2327 - SDP: Session Description Protocol) gegangen und es scheint, Sie können nur die beiden SDP-Dokumente verketten. Das Dokument gibt explizit an:

Wenn SDP von SAP übermittelt wird, ist nur eine Sitzungsbeschreibung pro Paket zulässig. Wenn SDP auf andere Weise übermittelt wird, können viele SDP-Sitzungsbeschreibungen miteinander verkettet werden (die Zeile "v =", die den Beginn einer Sitzungsbeschreibung angibt, beendet die vorherige Beschreibung).

Answer 3

Ich denke, es hängt von Ihrem Decoder ab. Wenn es Parameteränderungen innerhalb des Streams unterstützt, dann sollte der Decoder automatisch schalten, wenn Sie dem Encoder sagen können, dass er den entsprechenden Header bei der Änderung der Auflösung setzen soll.

Was ist Ihre Frage genau? Ist es: Wie kann ich die Auflösung ändern, ohne den Stream zu stoppen/neu zu starten?

Ich glaube nicht, dass Sie im Voraus zu einem Decoder sagen können, hier sind die mögliche Auflösung, die Sie mit etwas Sdp Magie sehen werden. Entweder ist Ihr Decoder in der Lage, H264-Parameteränderungen zu verstehen, und dann geht es Ihnen gut, oder Sie müssen aufhören, das Ganze neu zu starten, und dann ist dynamisches sdp ausreichend.

Ich weiß, dass zum Beispiel VLC MP4-Codierung ändern kann (zum Beispiel von variabler Bitrate zu konstanter Bitrate wechseln), aber wird abstürzen, wenn Sie die Auflösung ändern Das einzige, was Sie mit sdp tun können ist Kombinieren Sie unterschiedliche Medienbeschreibungen, zum Beispiel mit unterschiedlichen dynamischen Nutzdaten und unterschiedlichen Steuer-ID-Attributen.

Answer 4

Sie können entweder die Änderung der dynamischen Nutzlast oder die Änderung des In-Stream-Parametersatzes vornehmen oder SIP re-INVITE.

Payload-Änderungen haben ein Problem, dass, wenn Sie den Encoder und Decoder nicht steuern, Sie sicherstellen müssen, dass das andere Ende beide Payloads akzeptiert, und dass sie Payloads korrekt (und schnell genug für Sie) wechseln - es gibt keine Anforderung auf diesem).

In-Stream-Änderungen haben ein Problem, wenn die Parameter-Set-Pakete verloren gehen. Sie können einen anderen Satz von Parametersätzen verwenden (wechseln Sie beim Ändern von Parametersatz 1 auf 2), um eine falsche Decodierung zu vermeiden. Wenn die Sätze verloren gehen, sollten Sie nur ein eingefrorenes oder leeres Bild erhalten. Ich würde empfehlen, sie einige Male zu wiederholen (nicht in zu schneller Folge).

SIP-Re-INVITE ist bandextern und handshaked und somit sicher, fügt aber jedem Switch eine Verzögerung hinzu und kann abhängig vom Empfänger einen Fehler verursachen und könnte zurückgewiesen werden.

(Anmerkung: Ich bin ein Autor von RFC 3984bis, das Update auf RFC 3984)