Aller au contenu principal

8.2.2. Usage with the SDP Offer/Answer Model (Modèle SDP Offer/Answer)

8.2.2. Usage with the SDP Offer/Answer Model (Modèle SDP Offer/Answer)​

Lorsque le H.264 est offert sur RTP avec SDP dans le modèle Offer/Answer [8] pour la négociation en unicast, les limitations et règles suivantes s'appliquent:

  • Les paramètres identifiant une configuration de format média pour le H.264 sont profile-level-id et packetization-mode. Ces paramètres de configuration de format média (sauf la partie niveau de profile-level-id) DOIVENT être utilisés de façon symétrique; c'est-à-dire que le répondant DOIT soit conserver tous les paramètres de configuration, soit retirer complètement le format médial (type de charge utile) si au moins une valeur n'est pas prise en charge. La partie niveau de profile-level-id comprend level_idc et, pour indiquer le niveau 1b lorsque profile_idc vaut 66, 77 ou 88, le bit 4 (constraint_set3_flag) de profile-iop. La partie niveau de profile-level-id est modifiable.

Note informative: L'exigence de symétrie ne s'applique pas à la partie niveau de profile-level-id ni aux autres paramètres de propriétés du flux et de capacité.

Note informative: Dans H.264 [1], tous les niveaux sauf 1b valent level_idc/10. Le niveau 1b est supérieur à 1.0 et inférieur à 1.1 et est signalé de façon ad hoc. Pour Baseline, Main et Extended (profile_idc 66, 77, 88), le 1b est indiqué par level_idc 11 et constraint_set3_flag 1. Pour d'autres profils, par level_idc 9 (le 1b reste au-dessus du niveau 1 avec level_idc 10). En SDP Offer/Answer, une réponse peut indiquer un niveau inférieur ou égal à l'offre. Pour le 1b, offreur et répondant doivent examiner le bit 4 de l'octet médian de profile-level-id lorsque profile_idc est 66, 77 ou 88 et level_idc vaut 11.

Pour simplifier, le MÊME numéro de type de charge utile RTP que dans l'offre DEVRAIT être utilisé dans la réponse [8]. Une réponse NE DOIT PAS contenir le type de charge utile de l'offre sauf si la configuration est strictement identique.

Note informative: L'offreur, en recevant la réponse, doit comparer les types non déclarés dans l'offre au type média video/H264 et aux paramètres ci-dessus avec ceux déjà offerts pour savoir si la configuration est nouvelle ou équivalente.

  • max-recv-level, s'il est présent, déclare le plus haut niveau de réception. S'il est absent, le plus haut niveau de réception est le niveau par défaut indiqué par la partie niveau de profile-level-id. S'il est présent, max-recv-level DOIT être supérieur au niveau par défaut.

  • level-asymmetry-allowed indique si l'asymétrie de niveau est autorisée.

Si level-asymmetry-allowed vaut 0 (ou est absent) dans l'offre ou la réponse, l'asymétrie n'est pas permise; le niveau de l'offreur vers le répondant DOIT être le même que dans l'autre sens; le niveau commun est le minimum des niveaux par défaut de l'offre et de la réponse.

Si la valeur 1 apparaît dans l'offre et la réponse, l'asymétrie est permise: offreur→répondant = plus haut niveau que le répondant peut recevoir; répondant→offreur = plus haut niveau que l'offreur peut recevoir.

Sans asymétrie, pas d'augmentation de niveau; le niveau par défaut dans la réponse DOIT être ≤ à celui de l'offre.

  • sprop-deint-buf-req, sprop-interleaving-depth, sprop-max-don-diff, sprop-init-buf-time décrivent les propriétés du flux RTP envoyé par l'offreur ou le répondant pour la configuration — ce qui diffère de l'usage habituel Offer/Answer (souvent capacité de réception). Pour le H.264, l'offreur suppose que le répondant peut recevoir le média encodé selon la configuration offerte.

Note informative: Ces paramètres s'appliquent à tout flux émis avec la même configuration (dépendance à la source); ils peuvent devoir s'appliquer à un autre type de charge utile à l'envoi.

  • max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br, redundant-pic-cap, max-rcmd-nalu-size, sar-understood, sar-supported PEUVENT déclarer des capacités de réception supplémentaires. Ils NE DOIVENT PAS être présents lorsque l'attribut de direction est sendonly et qu'ils décrivent les limites de réception.

  • L'offreur DOIT inclure sprop-deint-buf-req pour un flux H.264 entrelacé. Les deux parties DEVRAIENT inclure deint-buf-cap. Plusieurs types de charge utile avec des exigences de tampon différentes DEVRAIENT être envisagés si les capacités du récepteur sont inconnues.

  • sprop-parameter-sets / sprop-level-parameter-sets (ligne a=fmtp ou attribut source fmtp [9] §6.3) servent au transport hors bande; le transport in-band reste possible en plus.

Le répondant PEUT utiliser hors bande ou in-band pour son flux, indépendamment de la direction offreur→répondant. Les jeux dans l'offre et la réponse sont indépendants (deux flux vidéo).

Transport des jeux offreur → répondant

  • L'offre PEUT inclure l'un ou les deux sprop-*; si aucun, seul in-band.

  • Si la réponse a in-band-parameter-sets=1, l'offreur DOIT envoyer les jeux in-band.

  • Si le niveau utilisé offreur→répondant égale le niveau par défaut de l'offre:

Si sprop-parameter-sets est dans a=fmtp de l'offre, le répondant DOIT être prêt à utiliser ces jeux pour décoder le flux entrant.

Si sprop-parameter-sets est porté par l'attribut source fmtp dans l'offre: si la réponse contient use-level-src-parameter-sets=1 ou l'attribut source fmtp, le répondant DOIT être prêt à utiliser ces jeux; sinon l'offreur DOIT envoyer in-band.

Si sprop-parameter-sets est absent de l'offre, l'offreur DOIT envoyer in-band.

Le répondant DOIT ignorer sprop-level-parameter-sets dans l'offre (présent ou non, a=fmtp ou attribut source).

  • Si le niveau utilisé offreur→répondant diffère du niveau par défaut de l'offre:

Le répondant DOIT ignorer sprop-parameter-sets dans l'offre.

Si la réponse n'a ni use-level-src-parameter-sets=1 ni attribut source fmtp, le répondant DOIT ignorer sprop-level-parameter-sets dans l'offre et l'offreur DOIT envoyer in-band.

Si la réponse a use-level-src-parameter-sets=1 ou l'attribut source fmtp, le répondant DOIT être prêt à utiliser les jeux pour le niveau accepté (niveau par défaut de la réponse) dans sprop-level-parameter-sets de l'offre et ignorer les autres.

S'il manque des jeux pour le niveau requis dans sprop-level-parameter-sets de l'offre, l'offreur DOIT envoyer in-band.

Transport répondant → offreur

  • La réponse PEUT contenir sprop-parameter-sets OU sprop-level-parameter-sets, pas les deux; si aucun, seul in-band.

  • Offre avec in-band-parameter-sets=1 → le répondant NE DOIT PAS inclure de sprop-* dans la réponse et DOIT envoyer in-band.

  • Si le niveau répondant→offreur égale le niveau par défaut de la réponse:

Si sprop-parameter-sets est dans a=fmtp de la réponse, l'offreur DOIT être prêt à utiliser ces jeux.

Si porté par attribut source dans la réponse: si l'offre a use-level-src-parameter-sets=1 ou attribut source fmtp, l'offreur DOIT pouvoir utiliser ces jeux; sinon le répondant DOIT envoyer in-band.

Si absent de la réponse, le répondant DOIT envoyer in-band.

L'offreur DOIT ignorer sprop-level-parameter-sets dans la réponse.

  • Si le niveau répondant→offreur diffère du niveau par défaut de la réponse:

L'offreur DOIT ignorer sprop-parameter-sets dans la réponse.

Si l'offre n'a ni use-level-src-parameter-sets=1 ni attribut source fmtp, l'offreur DOIT ignorer sprop-level-parameter-sets dans la réponse et le répondant DOIT envoyer in-band.

Si l'offre a l'un des deux, l'offreur DOIT être prêt à utiliser les jeux pour le niveau utilisé répondant→offreur dans sprop-level-parameter-sets de la réponse et ignorer les autres.

S'il manque les jeux pour ce niveau dans la réponse, le répondant DOIT envoyer in-band.

Avec attribut source fmtp [9] §6.3, le récepteur des paramètres DOIT stocker les jeux pour le niveau accepté et les associer à la source; décoder uniquement les NALU de la même source; détection/résolution de collision SSRC selon [9].

Note informative: L'attribut source fmtp convient aux topologies Topo-Video-switch-MCU [29].

Multicast

  • Configuration identifiée par profile-level-id (niveau inclus) et packetization-mode; tous les paramètres de configuration (niveau inclus) DOIVENT être symétriques; la partie niveau n'est pas modifiable en Offer/Answer multicast. Même type de charge utile que dans l'offre DEVRAIT être dans la réponse; la réponse NE DOIT pas réutiliser un type de l'offre sauf configuration identique.

  • Les jeux reçus DOIVENT être associés à la source d'origine et utilisés uniquement pour le flux entrant de cette source.

  • Les autres paramètres comme en unicast si les règles ci-dessus sont respectées.

Tableau 6. Interprétation des paramètres selon l'attribut de direction

Paramètresendrecvrecvonlysendonly
profile-level-idCCP
max-recv-levelRR-
packetization-modeCCP
sprop-deint-buf-reqP-P
sprop-interleaving-depthP-P
sprop-max-don-diffP-P
sprop-init-buf-timeP-P
max-mbpsRR-
max-smbpsRR-
max-fsRR-
max-cpbRR-
max-dpbRR-
max-brRR-
redundant-pic-capRR-
deint-buf-capRR-
max-rcmd-nalu-sizeRR-
sar-understoodRR-
sar-supportedRR-
in-band-parameter-setsRR-
use-level-src-parameter-setsRR-
level-asymmetry-allowedO--
sprop-parameter-setsS-S
sprop-level-parameter-setsS-S

Légende: C configuration envoi/réception; O mode Offer/Answer; P propriétés du flux à envoyer; R capacités du récepteur; S jeux hors bande; - non utilisable (DEVRAIT être ignoré).

Les capacités de réception sont en général déclassables (plafond). Les points de configuration ne changent pas sauf la partie niveau de profile-level-id en unicast.

Des capacités d'émetteur non déclassables décrivent une configuration de réception acceptable. Pour l'interopérabilité, offrir plusieurs alternatives (ex. modes de paquetisation) est souvent conseillé; chaque alternative nécessite son propre type de charge utile.

Un récepteur DEVRAIT comprendre tous les paramètres du type média même s'il n'en implémente qu'une partie.

Un répondant PEUT étendre l'offre; souvent un second offre est nécessaire pour les propriétés du flux, et l'offreur doit alors aussi pouvoir recevoir cette configuration.

Asymétrie des capacités: level-asymmetry-allowed=1 ou sessions RTP distinctes recvonly / sendonly (sémantique externe pour les lier).

Dernière mise à jour le