Ce document fournit des consignes pour utiliser le format de diffusion Dynamic Adaptive Streaming over HTTP (DASH) afin de diffuser des données en direct sur YouTube à partir d'un encodeur. Il est destiné à aider les fournisseurs d'encodeurs à ajouter la prise en charge de la diffusion DASH à leurs produits.
Comprendre DASH
Vous trouverez ci-dessous quelques-unes des principales caractéristiques et attributs 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.
- Compatible avec un débit de transfert élevé. DASH est compatible avec plusieurs sessions HTTP simultanées et la diffusion de segments non séquentiels, ce qui offre une meilleure résilience que les protocoles qui s'appuient sur une seule connexion TCP.
- Diffusion sécurisée via HTTPS.
- Diffusion sans perte via HTTP et HTTPS.
- Compatible avec tous les codecs.
- Compatible avec les formats MP4 (H264 et AAC) et WebM (VP8/VP9 et Vorbis/Opus).
Spécifications
- DASH est décrit dans la norme ISO/CEI 23009-1:2014 Technologies de l'information -- Streaming adaptatif dynamique sur HTTP (DASH).
- WebM sur DASH est décrit dans la spécification WebM DASH.
Conditions requises
Les sous-sections suivantes expliquent les exigences à respecter pour utiliser DASH afin de diffuser des contenus en direct sur YouTube.
Durée
Le point de terminaison YouTube DASH se comporte comme un serveur HTTP passif, enregistrant les appels de méthode PUT envoyés par un encodeur.
- Le point de terminaison DASH est compatible avec les connexions TCP simultanées. Vous pouvez réutiliser les connexions conformément à HTTP/1.1.
- Le segment MPD et le segment d'initialisation doivent être envoyés dans les trois secondes suivant le premier segment média. (Nous vous recommandons d'inclure le segment d'initialisation dans le fichier MPD.)
- Chaque segment ou MPD 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 d'importation.
- Les segments peuvent être fournis dans un ordre non séquentiel dans un intervalle de temps d'environ trois secondes.
- Les segments MPD et d'initialisation doivent être mis à jour au moins toutes les 60 secondes avec des éléments
availabilityStartTime
etstartNumber
actualisés. (Comme indiqué ci-dessus, le segment d'initialisation peut être inclus dans le fichier MPD. Dans ce cas, une requête PUT peut mettre à jour les deux segments.)
Structure d'URL
Votre encodeur doit créer 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 : de 0 à 9
- Caractères spéciaux : _ (trait de soulignement), - (tiret), . (point)
URL MPD
En plus de l'exigence ci-dessus, l'URL du fichier MPD doit se terminer par .mpd
, ce qui permet au serveur YouTube d'identifier facilement le fichier MPD. Les autres URL de segments ne doivent pas se terminer par .mpd
.
URL d'initialisation et de segment mé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 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
Le fichier MPD doit être complet et conforme à la norme DASH. Il doit contenir exactement un de chacun des éléments suivants. Cette liste identifie les éléments spécifiquement requis par YouTube. La norme DASH peut identifier d'autres éléments requis. 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 noter les exigences suivantes concernant les valeurs des éléments :
- L'attribut
minimumUpdatePeriod
de l'élément<MPD>
doit être défini sur une valeur 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'attributstartNumber
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 d'initialisation est beaucoup plus petit.) Si le segment d'initialisation est inclus dans le fichier MPD, 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 média doivent constituer un flux de fichiers ISO BMFF ou WebM multiplexé avec des GOP (groupes d'images) fermés.
- La taille du GOP doit être d'environ deux secondes et ne doit pas dépasser huit secondes.
- Le flux multiplexé doit contenir des pistes audio et vidéo.
Autres bonnes pratiques
Chiffrement
YouTube accepte le chiffrement des flux via HTTPS. Nous vous recommandons vivement d'utiliser cette fonctionnalité.
Segments d'initialisation dans le fichier MPD
Vous pouvez représenter le segment d'initialisation directement dans le fichier MPD à l'aide d'une URL data:
, conformément à la 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 le suivant :
/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute:data
Durées des segments cibles
Pour 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 1 et 5 secondes. Nous vous recommandons vivement de communiquer la durée cible de ces segments dans le fichier MPD à 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 comprise dans un facteur de 2 de toutes les durées de segment réelles. Dans le cas contraire, 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 segments de la diffusion en direct que YouTube produit. YouTube transcode et regroupe l'entrée. La durée cible de la sortie dépend de l'optimisation du flux (qualité de streaming ou latence).
Nouvelles 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 ce délai sur une valeur supérieure de 500 millisecondes à la durée du segment.
Une requête PUT de segment multimédia qui échoue, que ce soit en raison d'un délai d'attente ou d'autres erreurs, correspond à un écart dans le flux vidéo. Par conséquent, vous devez relancer toute requête de ce type à l'aide d'un intervalle exponentiel entre les tentatives binaire aléatoire :
- En cas d'échec, attendez une période aléatoire comprise entre
[0 ... 100]
millisecondes et réessayez. - Si la requête échoue à nouveau, attendez une période aléatoire comprise entre
[0 ... 200]
millisecondes et réessayez. - Si la requête échoue à nouveau, attendez une période aléatoire comprise entre
[0 ... 400]
millisecondes et réessayez. - 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 expliquent les codes de réponse que YouTube renvoie en réponse aux segments fournis 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 traitée avec succès.
202 (Accepté)
Une réponse HTTP 202 (Accepté) à une opération PUT ou POST indique que l'opération était inattendue et acceptée pour un traitement différé. Toutefois, l'opération différée peut réussir ou échouer. La réponse ne garantit donc pas que YouTube pourra effectivement traiter l'opération.
Cette réponse se produit le plus souvent lorsqu'un segment est fourni 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. 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 le fichier MPD.
- Les segments média sont reçus avant les segments MPD et d'initialisation.
- Un segment média est reçu avant un segment antérieur (par exemple, le segment 3 est reçu avant le segment 2).
Toutefois, une réponse 202 peut également indiquer que l'identifiant de l'élément est incorrect si YouTube ne peut pas le valider entièrement lors de la réception de la requête POST ou PUT. Par exemple, cela se produit lorsque YouTube reçoit et accepte un segment d'initialisation avant de recevoir le fichier MPD, 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 du fichier MPD. Pour éviter ce scénario particulier, incluez le segment d'initialisation dans le fichier MPD.
400 (Requête incorrecte)
Une réponse HTTP 400 (requête incorrecte) indique que l'un des problèmes suivants s'est produit :
- L'URL n'est pas conforme.
- Le post est trop volumineux (> 10 Mo).
- Impossible d'analyser le fichier MPD.
- Le segment d'initialisation du fichier MPD est corrompu.
401 (Opération non autorisée)
Une réponse HTTP 401 (non autorisée) 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 requête. 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 du fichier MPD, du segment d'initialisation ou des deux. Dans cet exemple, l'encodeur devrait retransmettre les segments MPD et d'initialisation avant de réessayer la requête ayant échoué.
500 (Erreur interne au 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 montre une série de requêtes PUT qui seraient 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©=0&file=
La séquence montre que le fichier MPD et les segments d'initialisation sont envoyés séparément. Toutefois, le segment d'initialisation peut être représenté directement dans le fichier MPD, ce qui est recommandé. De plus, les segments MPD et d'initialisation doivent être mis à jour au moins toutes les 60 secondes. Ainsi, les URL de ces segments apparaîtraient à nouveau dans cette séquence, suivies des URL d'autres segments multimédias.
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=dash.mpd PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=init.mp4 PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media001.mp4 PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media002.mp4 PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media003.mp4 ...
Segments WebM
MPD avec segment d'initialisation intégré
L'exemple de fichier 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 d'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 des données a été supprimée pour faciliter la lecture :
<?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©=0&file=media-$Number%09d$.webm"/> <Representation id="1" width="1920" height="1080"> <SubRepresentation contentComponent="1"/> </Representation> </AdaptationSet> </Period> </MPD>
MPD
L'exemple de fichier MPD suivant, qui ne comporte pas de segment d'initialisation intégré, est également conforme pour 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©=0&file=init.webm" media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media-$Number%09d$.webm"/> <Representation id="1" width="1920" height="1080"> <SubRepresentation contentComponent="1"/> </Representation> </AdaptationSet> </Period> </MPD>
Initialisation
L'exemple suivant montre la mise en page d'un segment d'initialisation WebM. Il s'agit de la partie du flux WebM jusqu'au premier cluster, mais sans l'inclure.

Contenus multimédias
La mise en page d'un exemple de segment multimédia WebM est présentée ci-dessous. Il se compose d'un seul cluster WebM. Comme pour un flux ISO-BMFF, le segment d'initialisation ajouté à une série de clusters doit produire un flux WebM valide.

Segments ISO BMFF
MPD avec segment d'initialisation intégré
L'exemple de fichier 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 d'initialisation de cette manière plutôt que de l'envoyer séparément.
Cet exemple est conforme à l'ingestion ISO BMFF (H.264, AAC) sur YouTube. La majorité de l'URL des données a été supprimée pour faciliter la lecture :
<?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©=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 fichier MPD suivant, qui ne comporte pas de segment d'initialisation intégré, 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©=0&file=init.mp4" media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=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 diagramme 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 il s'agit d'un exemple conforme. En particulier, les pistes audio et vidéo sont représentées.

Contenus multimédias
Le schéma suivant montre la mise en page d'un exemple de segment média ISO BMFF multiplexé. YouTube n'utilise pas nécessairement tous les atomes, mais il s'agit d'un exemple 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 ISO BMFF multiplexé valide et complet.

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