Diffuser du contenu YouTube en direct via DASH

Ce document donne des consignes sur l'utilisation du format de diffusion DASH pour diffuser des données en direct sur YouTube à partir d'un encodeur. Il est destiné à aider les fournisseurs d'encodeurs à ajouter la compatibilité de la diffusion DASH à leurs produits.

Fonctionnement de DASH

La liste ci-dessous répertorie les principales caractéristiques et attributs de DASH:

• Basé sur des normes ouvertes.
• Basé sur HTTP. Par conséquent, DASH est adapté aux infrastructures Internet et peut traverser les pare-feu.
• Compatible avec un débit de transfert élevé. DASH est compatible avec plusieurs sessions HTTP simultanées et la livraison de segments non séquentiels, ce qui offre une plus grande résilience que les protocoles qui reposent sur une seule connexion TCP.
• Diffusion sécurisée via HTTPS.
• Diffusion sans perte via HTTP et HTTPS
• Compatibilité avec les codecs
• Compatible avec les formats MP4 (H264 et AAC), ainsi que WebM (VP8/VP9 et Vorbis/Opus).

Caractéristiques

• Le format DASH est décrit dans la norme ISO/IEC 23009-1:2014 Technologie d'information – Streaming adaptatif dynamique sur HTTP (DASH).
• La propriété WebM sur DASH est décrite dans la spécification WebM DASH.

Conditions requises

Les sous-sections suivantes expliquent les exigences concernant l'utilisation de DASH pour diffuser des diffusions en direct sur YouTube.

Calendrier

Le point de terminaison DASH YouTube se comporte comme un serveur HTTP passif, enregistrant les appels de méthode PUT envoyés par un encodeur.

• Le point de terminaison DASH accepte les connexions TCP simultanées. Vous pouvez réutiliser les connexions conformément au protocole HTTP/1.1.
• Les segments MPD et d'initialisation doivent être placés dans un délai de 3 secondes à partir du premier segment multimédia. (Nous vous recommandons d'inclure le segment d'initialisation dans la description de la présentation du média.)
• Chaque segment ou MPD doit utiliser une requête PUT distincte. L'importation en plusieurs parties de plusieurs segments n'est pas prise en charge.
• Les opérations PUT pour les segments multimédias peuvent se chevaucher dans le temps afin d'améliorer la bande passante de transfert.
• Les segments peuvent être fournis dans un ordre non séquentiel dans un intervalle d'environ trois secondes.
• Les segments de la présentation du média et de l'initialisation doivent être mis à jour au moins toutes les 60 secondes avec les valeurs availabilityStartTime et startNumber mises à jour. (Comme indiqué ci-dessus, le segment d'initialisation peut être inclus dans la description de la présentation du média.) Dans ce cas, une requête PUT peut mettre à jour les deux segments.

Structure d'URL

Votre encodeur doit former des URL PUT en ajoutant une chaîne à l'URL de base du point de terminaison YouTube. Vous devez créer le point de terminaison d'ingestion DASH à l'aide de l'API YouTube Live Streaming.

L'encodeur peut ensuite obtenir l'URL de base du point de terminaison de manière programmatique via l'API YouTube Live Streaming. L'URL de base est également visible dans l'interface utilisateur des événements en direct YouTube si vous souhaitez fournir l'URL à l'encodeur manuellement.

La chaîne ajoutée à l'URL de base peut contenir l'ensemble de caractères ASCII suivant:

• Lettres minuscules: a-z
• Lettres majuscules: A-Z
• Chiffres: 0 à 9
• Caractères spéciaux: _ (trait de soulignement), - (tiret), . (point)

URL MPD

En plus de l'exigence ci-dessus, l'URL de la description de la présentation du média doit se terminer par .mpd, ce qui permet au serveur YouTube de l'identifier facilement.Les autres URL de segment ne doivent pas se terminer par .mpd.

Initialisation et URL de segment multimédia

L'URL du segment d'initialisation et toutes les URL du segment multimédia doivent se terminer par .mp4 si les données se trouvent dans un conteneur ISO BMFF ou par .webm si les données se trouvent dans un conteneur WebM.

Contenu de la description de la présentation du média

La description de la présentation du média doit être complète et conforme à la norme DASH. Il doit contenir exactement chacun des éléments suivants. Cette liste répertorie les éléments spécifiquement requis par YouTube, et la norme DASH peut en identifier d'autres. Les éléments sont représentés à l'aide de la syntaxe XPath et sont conformes à la norme DASH.

• /mpd:MPD/attribute::type
• /mpd:MPD/mpd:Period
• /mpd:MPD/mpd:Period/mpd:AdaptationSet
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/attribute::mimeType (video/mp4 or video/webm)
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::media
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::initialization
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::startNumber

Veuillez tenir compte des exigences suivantes concernant les valeurs des éléments:

• La valeur de l'attribut minimumUpdatePeriod de l'élément <MPD> doit être inférieure ou égale à 60 secondes (PT60S).
• L'attribut media de l'élément <SegmentTemplate> doit spécifier que les URL des segments multimédias sont générées à l'aide de $Number$. (L'attribut startNumber identifie le numéro attribué au premier segment multimédia.)

Longueur du segment d'initialisation

Le segment d'initialisation ne doit pas dépasser 100 Ko. En général, un segment d'initialisation est beaucoup plus petit. Si le segment d'initialisation est inclus dans la description de la présentation du média, l'URL data:, qui contient le segment, ne doit pas dépasser 100 Ko.

Sortie de l'encodeur

Le segment d'initialisation et les segments multimédias doivent constituer un flux de fichiers multiplex ISO BMFF ou WebM associé à des GOP (groupes d'images) fermés.

• La taille du GOP doit être d'environ 2 secondes et inférieure à 8 secondes.
• Le flux multiplexé doit contenir à la fois des pistes audio et vidéo.

Autres bonnes pratiques

Chiffrement

YouTube est compatible avec le chiffrement des flux via HTTPS. Nous vous recommandons vivement d'utiliser cette fonctionnalité.

Segments d'initialisation en MPD

Vous pouvez représenter le segment d'initialisation directement dans la description de la présentation du média à l'aide d'une URL data:, conformément à la norme RFC 2397. Cela simplifie la configuration de votre flux et réduit le risque que le segment d'initialisation ne corresponde pas au reste du flux.

Le chemin XPath de cet élément est:

/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute:data

Remarque : L'URL data: ne doit pas dépasser 100 000 octets.

Durées des segments cibles

Pour optimiser les performances d'ingestion et trouver le bon compromis entre débit et latence, la durée de vos segments multimédias doit être comprise entre une et cinq secondes.Nous vous recommandons vivement de communiquer la durée cible de ces segments dans la description de la présentation du média à l'aide des deux éléments suivants:

• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::duration
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::timescale

La durée calculée à partir de ces attributs doit être inférieure à deux fois par rapport à la durée réelle du segment ou les performances de streaming.

Notez que la durée cible de l'ingestion ne correspond pas à celle du fragment pour le flux en direct produit par YouTube. YouTube transcode et retranche les entrées, et la durée cible de sortie dépend de l'optimisation de la qualité de streaming ou de la latence.

Tentatives et intervalle exponentiel entre les tentatives

Toutes les requêtes HTTP PUT doivent être exécutées avec un délai d'expiration. Nous vous recommandons de définir une valeur de 500 millisecondes supérieure à la durée du segment.

Une requête PUT de segment multimédia qui échoue, qu'elle soit due à un délai d'inactivité ou à une autre erreur, correspond à un blanc dans le flux vidéo. Ainsi, vous devez relancer une telle requête à l'aide d'un intervalle exponentiel binaire entre les tentatives aléatoire :

1. Après un échec, attendez une période aléatoire comprise entre [0 ... 100] millisecondes et relancez la requête.
2. Si la requête échoue à nouveau, attendez entre [0 ... 200] millisecondes et effectuez une nouvelle tentative.
3. Si la requête échoue à nouveau, attendez entre [0 ... 400] millisecondes et effectuez une nouvelle tentative.
4. etc.

Notez que les échecs répétés doivent être signalés à l'opérateur de codage, car ils correspondent à une diffusion en échec.

Codes de réponse HTTP

Les sections suivantes expliquent les codes de réponse renvoyés par YouTube en réponse aux segments envoyés via DASH.

200 (OK)

Une réponse HTTP 200 (OK) indique que le serveur YouTube a reçu une opération attendue et qu'elle a bien été traitée.

202 (Accepté)

Une réponse HTTP 202 (Acceptée) à une opération PUT ou POST indique que l'opération était inattendue et acceptée pour un traitement différé. Cependant, l'opération différée peut réussir ou échouer. La réponse ne garantit donc pas que YouTube sera effectivement en mesure de la traiter.

Cette réponse est plus fréquente lorsqu'un segment est livré de manière non séquentielle. En général, YouTube peut traiter correctement le segment accepté après avoir reçu les segments précédents, et vous n'avez pas besoin de le renvoyer.

Par exemple, YouTube peut renvoyer une réponse 202 dans les cas suivants:

• Un segment d'initialisation est reçu avant la description de la présentation du média.
• Les segments multimédias sont reçus avant les segments MPD et d'initialisation.
• Un segment multimédia est reçu avant un segment précédent, comme le segment 3 reçu avant le segment 2.

Cependant, une réponse 202 peut également indiquer que l'identifiant d'article est incorrect si YouTube ne peut pas le valider complètement à la réception de la requête POST ou PUT. Par exemple, lorsque YouTube reçoit et accepte un segment d'initialisation avant de recevoir la description de la présentation du média, mais que le segment d'initialisation s'avère non valide, Dans ce cas, YouTube accepte le segment d'initialisation et renvoie un code 202, puis détermine si le segment est valide à la réception de la description de la présentation du média. Vous pouvez éviter ce cas de figure en incluant le segment d'initialisation dans la description de la présentation du média.

400 (Requête incorrecte)

Une réponse HTTP 400 (requête incorrecte) indique l'un des problèmes suivants:

• L'URL n'est pas rédigée correctement
• Post trop volumineux (> 10 Mo)
• Impossible d'analyser la description de la présentation du média.
• Le segment d'initialisation de la description de la présentation du média est corrompu

401 (Opération non autorisée)

Une réponse HTTP 401 (Non autorisé) indique que l'URL de base du point de terminaison DASH YouTube est corrompue ou arrivée à expiration.

405 (Méthode non autorisée)

Une réponse HTTP 405 (Méthode non autorisée) indique qu'une requête autre que POST ou PUT a été envoyée.

409 (Conflit)

Une réponse HTTP 409 (Conflit) sur une opération PUT ou POST indique que YouTube ne peut pas traiter la demande. Par exemple, cette réponse peut se produire si le demandeur a envoyé de nombreux segments multimédias, mais que YouTube ne dispose toujours pas de la MPD et/ou de l'initialisation. Dans cet exemple, l'encodeur doit retransmettre les segments MPD et d'initialisation avant de relancer la requête ayant échoué.

Important:Un encodeur DOIT gérer correctement ce code de réponse, car il peut être renvoyé à tout moment, y compris lors d'opérations normales. Bien que le nombre de tentatives ne soit pas limité, l'opérateur d'encodage doit signaler les échecs répétés de la diffusion.

500 (Erreur interne du serveur)

Une réponse HTTP 500 (Erreur interne du serveur) indique que le serveur n'a pas pu traiter la requête. Pour cette erreur, nous vous recommandons de relancer la requête avec un intervalle exponentiel entre les tentatives.

Exemples

Séquence d'URL

La séquence d'URL ci-dessous présente une série de requêtes PUT qui seraient envoyées pour fournir du contenu via DASH. La séquence suppose que l'URL de base du point de terminaison YouTube DASH est la suivante:

http://upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=

La séquence affiche les segments de la présentation du média et de l'initialisation envoyés séparément. Toutefois, le segment d'initialisation peut être représenté directement dans la description de la présentation du média, et cette pratique est recommandée. De plus, les segments de la présentation du média et de l'initialisation doivent être mis à jour au moins toutes les 60 secondes. Au final, les URL correspondant à ces segments apparaîtront de nouveau dans cette séquence, puis elles seront suivies par les URL de segments multimédias supplémentaires.

PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=dash.mpd
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media001.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media002.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media003.mp4
...

Segments WebM

MPD avec segment d'initialisation intégré

L'exemple de MPD suivant comporte un segment d'initialisation intégré dans une URL de données RFC 2397. Nous vous recommandons d'intégrer le segment "Initialisation" de cette manière plutôt que de l'envoyer séparément.

Cet exemple est conforme à l'ingestion WebM (VP8 ou VP9, Opus) sur YouTube. La majorité de l'URL de données a été éliminée pour des raisons de lisibilité:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic" 
     profiles="urn:mpeg:dash:profile:isoff-live:2011" 
     minimumUpdatePeriod="PT60S"
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:52:58" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/webm">
      <ContentComponent contentType="video" id="1"/>
      <SegmentTemplate timescale="1000"
           duration="2000"
           startNumber="1"
           initialization="data:video/mp4;base64,AAAAGGZ0eXBpc...AAA"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media-$Number%09d$.webm"/>
      <Representation id="1" width="1920" height="1080">
        <SubRepresentation contentComponent="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

MPD

L'exemple de MPD suivant, qui n'a pas de segment d'initialisation, est également conforme à l'ingestion WebM (VP8 ou VP9, Opus) sur YouTube:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic" 
     profiles="urn:mpeg:dash:profile:isoff-live:2011" 
     minimumUpdatePeriod="PT60S"
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:52:58" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/webm">
      <ContentComponent contentType="video" id="1"/>
      <SegmentTemplate timescale="1000"
           duration="2000"
           startNumber="1"
           initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.webm"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media-$Number%09d$.webm"/>
      <Representation id="1" width="1920" height="1080">
        <SubRepresentation contentComponent="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

Initialisation

Voici un exemple de segment d'initialisation WebM. Il s'agit de la partie du flux WebM jusqu'au premier, mais sans le premier.

Multimédia

Voici un exemple de mise en page d'un segment multimédia WebM. Elle se compose d'un seul cluster WebM. Comme pour un flux ISO BMFF, le segment d'initialisation précédé d'une série de clusters doit générer un flux WebM valide.

Segments BMFF ISO

MPD avec segment d'initialisation intégré

L'exemple de MPD suivant comporte un segment d'initialisation intégré dans une URL de données RFC 2397. Nous vous recommandons d'intégrer le segment "Initialisation" de cette manière plutôt que de l'envoyer séparément.

Cet exemple est conforme aux normes d'ingestion ISO BMFF (H.264, AAC) sur YouTube. La majorité de l'URL de données a été éliminée pour des raisons de lisibilité:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="urn:mpeg:dash:schema:mpd:2011"   
    xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" 
    type="dynamic"
    minimumUpdatePeriod="PT30S" 
    availabilityStartTime="2016-05-04T20:47:25" 
    minBufferTime="PT12S" 
    profiles="urn:mpeg:dash:profile:isoff-live:2011">
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2">
      <ContentComponent contentType="video" id="1"/>
      <ContentComponent contentType="audio" id="2"/>
      <SegmentTemplate timescale="600"
             media="/dash_upload?cid=ug50-xg26-cbc1-2p0h&staging=1&copy=0&file=media$Number%09d$.mp4"
             initialization="data:video/mp4;base64,AAAAGGZ0eXBpc281AA...AA"
             duration="306"
             startNumber="1"/>
      <Representation id="1" width="640" height="360" bandwidth="526952">
        <SubRepresentation contentComponent="1" bandwidth="526952" 
codecs="avc1.4d401e"/>
        <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

MPD

L'exemple de MPD suivant, qui n'a pas de segment d'initialisation, est également conforme à l'ingestion ISO BMFF (H.264, AAC) sur YouTube:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic"
     profiles="urn:mpeg:dash:profile:isoff-live:2011"
     minimumUpdatePeriod="PT60S" 
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:51:31" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2">
      <ContentComponent contentType="video" id="1"/>
      <ContentComponent contentType="audio" id="2"/>
      <SegmentTemplate timescale="600"
           duration="1200"
           startNumber="1"
           initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.mp4"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media$Number%09d$.mp4"/>
      <Representation id="1" width="640" height="360" bandwidth="526952">
        <SubRepresentation contentComponent="1" bandwidth="526952" codecs="avc1.4d401e"/>
        <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

Initialisation

Le schéma suivant montre la mise en page d'un exemple de segment d'initialisation ISO BMFF multiplexé. YouTube n'utilise pas nécessairement les atomes, mais cet exemple est conforme. En particulier, les pistes audio et vidéo sont représentées.

Multimédia

Le schéma suivant montre la mise en page d'un exemple de segment multimédia ISO BMFF multiplexé. YouTube n'utilise pas nécessairement tous les atomes, mais cet exemple est conforme. En particulier, les pistes audio et vidéo sont représentées. Une série de ces segments peut être ajoutée à un segment d'initialisation pour générer un flux ISO BMFF multiplexé valide et complet.

Limitations connues

Intégrations RTMP et DASH

Il n'est pas possible de combiner des ingestions RTMP et DASH sur YouTube.Cela s'applique au passage de l'un à l'autre pendant une diffusion, ainsi qu'à l'utilisation de l'une comme méthode d'ingestion principale et de l'autre pour l'ingestion de sauvegarde.