Flux vidéo multiples H.264 dans une session RTP

Question

Je souhaite changer dynamiquement la source vidéo dans une application 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 voudrais les combiner en un seul fichier SDP afin que le client de visualisation puisse automatiquement redimensionner la fenêtre d'affichage lorsque la source vidéo change. Voici deux exemples de fichiers SDP:

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 

Comment ces fichiers individuels réunis en un seul fichier SDP?

Answer 1

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 sprop paramètres-ensembles distincts et les clients prennent en charge la norme bien vous pouvez utiliser les types de charge utile dynamique séparés pour chaque résolution et un seul SDP comme suit:

 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 

similaires à d'autres réponses si vous ne le faites pas En fait, vous avez besoin des différents noms de flux ou des différents jeux de paramètres sprop. Vous devriez être en mesure d'utiliser votre premier format SDP et votre format de commutateur mid stream. Je ne connais pas suffisamment la charge utile réelle de H.264 ou de votre décodeur pour que cela fonctionne dans vos applications, mais il est très courant dans les applications de vidéoconférence de permuter dynamiquement entre résolutions sans signaler de changement ou exiger une dynamique séparée type de charge utile.

Bien que vous puissiez concaténer deux documents SDP comme mentionné dans une autre réponse, je ne pense pas que cela aidera dans ce cas. H.264 décodeurs ne peuvent fonctionner qu'avec un seul paramètre sprop-parameter-sets à la fois, je crois. Puisque 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 le paramètre sprop-parameter-sets. UPDATE: Notez que certaines implémentations obtiennent leurs sprops inband et pas du SDP (ou seulement initialement du SDP). Si cela s'applique dans votre environnement, le SDP-paramètres-ensembles peuvent être mis à jour intrabande

Références:

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

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

Answer 2

J'ai parcouru la RFC (RFC2327 - SDP: Session Description Protocol) 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).

Answer 3

Je pense que cela dépend de votre décodeur. S'il prend en charge les changements de paramètres à l'intérieur du flux, alors si vous pouvez dire à l'encodeur de mettre l'en-tête correspondant lors de la modification de la résolution, votre décodeur devrait automatiquement basculer.

Quelle est votre question exactement? Est-il: Comment puis-je changer la résolution sans arrêter/redémarrer le flux?

Je ne pense pas que vous pouvez dire à l'avance à un décodeur, voici la résolution potentielle que vous verrez avec une magie sdp. Soit votre décodeur est en mesure de comprendre le changement de paramètre H264, et alors vous êtes bien, ou vous devez arrêter de redémarrer le tout, et puis sdp dynamique est suffisante. Je sais que par exemple, VLC est capable de détecter les changements de codage MP4 (par exemple passer d'un débit binaire variable à un débit binaire constant), mais se bloque si vous changez la résolution La seule chose que vous pouvez faire avec sdp est de combiner une description de média différente, par exemple avec un type de charge utile dynamique différent et un attribut d'identifiant de contrôle différent.

Answer 4

Vous pouvez effectuer la modification de la charge utile dynamique ou la modification du jeu de paramètres dans le flux ou SIP re-INVITE. Les modifications de charge utile ont un problème: si vous ne contrôlez pas le codeur et le décodeur, vous devez vous assurer que l'autre extrémité accepte les deux charges utiles et qu'elle permutera les charges utiles correctement (et assez rapidement pour vous). sur ça).

Les modifications dans le flux présentent un problème si les paquets définis sont perdus. Vous pouvez utiliser un ensemble différent de jeux de paramètres (passer du jeu de paramètres 1 à 2 lorsque vous changez) pour éviter les erreurs de décodage - si les jeux sont perdus, vous devez simplement obtenir une image figée ou vide. Je conseillerais de les retransmettre plusieurs fois (pas en succession trop rapide). SIP re-INVITE est out-of-band et handshaked, et donc sûr, mais ajoute un retard à n'importe quel commutateur et peut pépin selon le récepteur, et pourrait être rejeté.

(Note: Je suis un auteur de RFC 3984bis, la mise à jour RFC 3984)