Cette page a été traduite par l'API Cloud Translation.

Diffuser du contenu YouTube en direct via DASH

Ce document explique comment utiliser le format de diffusion DASH (Dynamic Adaptive Streaming over HTTP) pour diffuser des données en direct sur YouTube à partir d'un encodeur. L'objectif est d'aider les fournisseurs d'encodeurs à ajouter une prise en charge de la diffusion DASH à leurs produits.

Comprendre DASH

La liste ci-dessous répertorie quelques-uns des attributs et fonctionnalités clés de DASH:

Basé sur des normes ouvertes.
Basé sur HTTP. Par conséquent, DASH est compatible avec l'infrastructure Internet et peut traverser les pare-feu.
Accepte un débit de transfert élevé. DASH prend en charge plusieurs sessions HTTP simultanées et la diffusion de segments non séquentielle, offrant ainsi une plus grande résilience que les protocoles qui reposent sur une seule connexion TCP.
Distribution sécurisée via HTTPS.
Diffusion sans perte via HTTP et HTTPS
Compatibilité avec les codecs.
Compatible avec les formats MP4 contenant H264 et AAC, ainsi que les fichiers WebM contenant VP8/VP9 et Vorbis/Opus.

Spécifications

DASH est décrit dans la norme ISO/IEC 23009-1:2014 Technologies de l'information - Diffusion adaptative dynamique des flux sur HTTP (DASH).
Le format WebM sur DASH est décrit dans la spécification WebM DASH.

Conditions requises

Les sous-sections suivantes décrivent les conditions requises pour utiliser DASH pour diffuser des diffusions en direct sur YouTube.

Durée

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 des connexions conformément à la norme HTTP/1.1.
Les segments d'initialisation et de description de la présentation du média doivent être de type PUT dans les trois secondes qui suivent le premier segment multimédia. Nous vous recommandons d'inclure le segment "Initialisation" dans la description de la présentation du média.
Chaque segment ou description de présentation du média doit utiliser une requête PUT distincte. L'importation en plusieurs parties de plusieurs segments n'est pas acceptée.
Les opérations PUT pour les segments multimédias peuvent se chevaucher dans le temps afin d'améliorer la bande passante montante.
Les segments peuvent être fournis dans un ordre non séquentiel sur une fenêtre de temps d'environ trois secondes.
La description de la présentation du média et les segments d'initialisation doivent être actualisés au moins toutes les 60 secondes avec les valeurs availabilityStartTime et startNumber. (Comme indiqué ci-dessus, le segment "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 sur YouTube si vous souhaitez fournir manuellement l'URL à l'encodeur.

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

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

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

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 d'identifier facilement la description de la présentation du média.Les URL des autres segments ne doivent pas se terminer par .mpd.

URL d'initialisation et de segment multimédia

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

Contenus 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 un des éléments suivants. Cette liste identifie 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 indiquer que les URL des segments multimédias sont générées via $Number$ . L'attribut startNumber identifie le numéro qui sera 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 "Initialisation" est bien plus petit que cela. 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 WebM ou ISO multiplexé avec des GOP (groupes d'images) fermés.

La taille du GOP doit être d'environ 2 secondes et doit être 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 dans la description de la présentation du média

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 "Initialisation" ne corresponde pas au reste du flux.

Le chemin XPath de cet élément est le suivant:

/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 obtenir de bonnes performances d'ingestion et un 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 correspondre à un facteur de deux fois la durée réelle du segment, car les performances de streaming peuvent en pâtir.

Notez que la durée cible de l'ingestion n'est pas égale à la durée des fragments pour le flux en direct produit par YouTube. YouTube transcode et resegmente l'entrée. La durée cible de sortie varie selon que le flux est optimisé pour la qualité du flux ou pour la latence.

Nouvelles tentatives et intervalle exponentiel entre les tentatives

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

Une requête PUT de segment multimédia qui échoue (en raison d'un délai d'inactivité ou d'autres erreurs) correspond à un blanc dans le flux vidéo. Par conséquent, vous devez relancer une requête de ce type en utilisant un intervalle exponentiel binaire entre les tentatives aléatoire:

En cas d'échec, attendez un délai aléatoire compris entre [0 ... 100] millisecondes et relancez la requête.
Si la requête échoue à nouveau, attendez un délai aléatoire compris entre [0 ... 200] millisecondes et relancez la requête.
Si la requête échoue à nouveau, attendez un délai aléatoire compris entre [0 ... 400] millisecondes et relancez la requête.
etc.

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

Codes de réponse HTTP

Les sections suivantes décrivent les codes de réponse que YouTube renvoie en réponse aux segments diffusés via DASH.

200 (OK)

Une réponse HTTP 200 (OK) indique que le serveur YouTube a reçu une opération attendue et l'a gérée avec succès.

202 (Accepté)

Une réponse HTTP 202 (acceptée) à une opération PUT ou POST indique que l'opération était inattendue et qu'elle a été acceptée pour un traitement différé. Cependant, l'opération différée peut réussir ou échouer. Par conséquent, la réponse ne garantit pas que YouTube sera en mesure de traiter l'opération correctement.

Cette réponse se produit le plus souvent lorsqu'un segment est diffusé de manière non séquentielle. En règle générale, YouTube peut traiter correctement le segment accepté après avoir reçu les segments précédents. Il n'est donc pas nécessaire de renvoyer le segment.

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 de la description de la présentation du média et des segments d'initialisation.
Un segment multimédia est reçu avant un segment précédent (par exemple, un segment 3 avant le segment 2).

Cependant, une réponse 202 peut également indiquer que l'identifiant de l'article est incorrect si YouTube ne peut pas le valider entièrement à la réception de la requête POST ou PUT. C'est par exemple le cas 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 n'est pas 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 scénario particulier en incluant le segment "Initialisation" dans la description de la présentation du média.

400 (Requête incorrecte)

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

Le format de l'URL est incorrect.
Le post est trop volumineux (plus de 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 YouTube DASH est corrompue ou a expiré.

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) à 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 description de la présentation du média, du segment d'initialisation ou des deux. Dans cet exemple, l'encodeur doit retransmettre les segments de description de la présentation du média et d'initialisation avant de relancer la requête ayant échoué.

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 illustre une série de requêtes PUT effectuées pour diffuser 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 montre la description de la présentation du média et les segments d'initialisation envoyés séparément. Toutefois, le segment "Initialisation" peut être représenté directement dans la description de la présentation du média, et cette pratique est recommandée. De plus, la description de la présentation du média et les segments d'initialisation doivent être mis à jour au moins toutes les 60 secondes. Au final, les URL de ces segments se reproduisent dans cette séquence, puis sont suivies d'URL correspondant à d'autres segments multimédias.

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

Description de la présentation du média avec segment d'initialisation intégré

L'exemple de description de la présentation du média suivant intègre un segment d'initialisation 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) dans YouTube. La majeure partie de l'URL de données a été éliminée pour une meilleure 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 description de la présentation du média suivant, qui ne comporte pas de segment d'initialisation intégré, est également conforme à l'ingestion WebM (VP8 ou VP9, Opus) dans 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 la mise en page d'un exemple de segment d'initialisation WebM. Il se compose de la partie du flux WebM jusqu'au premier cluster (non inclus).

Multimédia

Vous trouverez ci-dessous la mise en page d'un exemple de segment multimédia WebM. Il se compose d'un seul cluster WebM. Comme pour un flux BMFF ISO, le segment d'initialisation ajouté à une série de clusters doit produire un flux WebM valide.

Segments du format de fichier ISO BMFF

Description de la présentation du média avec segment d'initialisation intégré

Cet exemple est conforme à l'ingestion au format ISO BMFF (H.264, AAC) dans YouTube. La majeure partie de l'URL de données a été éliminée pour une meilleure 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 description de la présentation du média suivant, qui ne contient pas de segment d'initialisation, est également conforme à l'ingestion du format ISO BMFF (H.264, AAC) dans 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 illustre la mise en page d'un exemple de segment d'initialisation de fichier de ce format (BMFF ISO 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 illustre la mise en page d'un exemple de segment multimédia multiplexé de type "BMFF ISO". 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 produire un flux BMFF multiplexé ISO valide et complet.

Limitations connues

Ingestions RTMP et DASH

Il n'est pas possible de combiner des ingestions RTMP et DASH dans YouTube.Cela s'applique au basculement entre les deux pendant une diffusion, ainsi qu'à l'utilisation de l'une comme méthode d'ingestion principale et de l'autre pour l'ingestion des sauvegardes.