Plusieurs flux vidéo H.264 dans une session RTP

https://stackoverflow.com/questions/163898

03-07-2019
|

Question

Je souhaite basculer dynamiquement la source vidéo dans une application de diffusion vidéo en continu Cependant, les différentes sources vidéo ont des dimensions d'image uniques. Je peux générer des fichiers SDP individuels pour chaque source vidéo, mais je souhaite les combiner en un seul fichier SDP afin que le client qui visualise puisse redimensionner automatiquement la fenêtre d'affichage en fonction de la modification de la source vidéo. Voici deux exemples de fichiers SDP:

640x480.sdp:

v=0
o=VideoServer 305419896 9876543210 IN 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=VideoServer 305419896 9876543210 IN 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

Comment ces fichiers individuels peuvent-ils être combinés en un seul fichier SDP?

La solution

Les paramètres de vos deux exemples sdp sont très proches - le nom du flux et les ensembles de paramètres sprop diffèrent. Je suppose que vous ne vous souciez pas du nom du flux. Si vous avez besoin de jeux de paramètres sprop distincts et que les clients prennent en charge le puits standard, vous pouvez utiliser des types de charge utile dynamique distincts pour chaque résolution et disposer d'un seul SDP comme suit:

    v=0
    o=VideoServer 305419896 9876543210 IN 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

Semblable à d’autres réponses si vous n’avez pas besoin des différents noms de flux ou des différents ensembles de paramètres sprop, vous devriez pouvoir utiliser votre premier SDP et le format intermédiaire du flux de format. Je ne connais pas suffisamment la charge utile réelle du H.264 ou de votre décodeur pour garantir que cela fonctionnera dans vos applications, mais il est très courant dans les applications de visioconférence de permettre la commutation dynamique entre les résolutions sans signaler de changement ou nécessiter une dynamique distincte. type de charge utile.

Bien que vous puissiez concaténer deux documents SDP comme indiqué dans une autre réponse, je ne pense pas que cela aidera dans ce cas. Les décodeurs H.264 ne peuvent fonctionner qu'avec un seul paramètre sprop-paramètre-sets à la fois, je crois. Étant donné que les deux SDP auraient le même type de charge utile, le même port source, etc., le récepteur ne saurait pas quand utiliser quel paramètre sprop-parameters-sets. UPDATE: Notez que certaines implémentations ont leurs sprops inband et non pas du SDP (ou seulement initialement du SDP). Si cela s’applique dans votre environnement, les ensembles de paramètres SDP sprop peuvent être mis à jour en bande

Références:

[Désolé de ne pas donner la citation complète - n'hésitez pas à corriger]

Autres conseils

J'ai parcouru le RFC ( RFC2327 - SDP: protocole de description de session ) et il semble que vous pouvez simplement concaténer les deux documents SDP. Le document indique explicitement:

Lorsque SDP est acheminé par SAP, une seule description de session est autorisée par paquet. Lorsque SDP est acheminé par d'autres moyens, de nombreuses descriptions de session SDP peuvent être concaténées ensemble (la ligne "v =" indiquant le début d'une description de session met fin à la description précédente) .

Je pense que cela dépend de votre décodeur. S'il prend en charge le changement de paramètres dans le flux, si vous pouvez demander au codeur de placer l'en-tête correspondant lors du changement de résolution, votre décodeur devrait basculer automatiquement.

Quelle est votre question exactement? Est-ce: Comment changer de résolution sans arrêter / redémarrer le flux?

Je ne pense pas que vous puissiez dire à l’avance à un décodeur, voici la résolution potentielle que vous verrez avec un peu de magie du SDP. Soit votre décodeur est capable de comprendre le changement de paramètre H264 et tout s’en va, ou vous devez arrêter de tout redémarrer, et alors le sdp dynamique suffit.

Je sais que, par exemple, VLC est capable de détecter les changements de codage MP4 (par exemple, de passer d'un débit variable à un débit constant), mais se bloquera si vous changez la résolution. La seule chose que vous puissiez faire avec sdp est de combiner différentes descriptions de média, par exemple avec différents types de charge utile dynamique et différents attributs de contrôle-id.

Vous pouvez effectuer le changement dynamique de charge utile ou le jeu d'ensemble de paramètres dans le flux, ou SIP re-INVITE.

Les modifications de la charge utile posent le problème suivant: si vous ne contrôlez pas l'encodeur et le décodeur, vous devez vous assurer que l'autre extrémité accepte les deux charges utiles, et qu'elles basculeront correctement les charges utiles (et assez rapidement pour vous - rien n'est requis ça).

Les modifications dans le flux ont un problème si les paquets de jeu de paramètres sont perdus. Vous pouvez utiliser un jeu de jeux de paramètres différent (passez du jeu de paramètres 1 à 2 lorsque vous modifiez) pour éviter les erreurs de décodage. Si les jeux sont perdus, vous devez simplement obtenir une image figée ou vierge. Je conseillerais de les retransmettre à quelques reprises (pas dans une succession trop rapide).

SIP re-INVITE n'est pas dans la bande, la poignée de main est donc sécurisée, mais elle retarde tous les commutateurs et peut créer des problèmes en fonction du récepteur, et être rejetée.

(Remarque: je suis l'auteur de la RFC 3984bis, mise à jour de la RFC 3984)

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow