Diffuser du contenu YouTube en direct via HLS

Ce document explique comment utiliser le protocole HTTP Live Streaming (HLS) pour diffuser des données en direct sur YouTube à partir d'un encodeur. Ce document s'adresse aux fournisseurs d'encodeurs qui souhaitent ajouter la prise en charge de l'ingestion HLS à leurs produits. L'ingestion HLS est un bon choix pour les contenus premium qui nécessitent une qualité et une résolution élevées avec une latence relativement plus élevée. Pour une brève comparaison des différents protocoles d'ingestion compatibles avec YouTube Live Streaming, consultez Comparaison des protocoles d'ingestion YouTube Live Streaming.

Pour diffuser des données en direct à l'aide de HLS, l'encodeur doit envoyer une série de playlists multimédias et de segments multimédias au point de terminaison HLS de YouTube à l'aide de requêtes HTTP PUT ou POST. Du point de vue de l'encodeur, le point de terminaison HLS YouTube apparaît comme un serveur HTTP passif.

Chaque segment multimédia représente le contenu multimédia réel d'une brève partie du flux, d'une durée comprise entre une et quatre secondes. Chaque playlist multimédia décrit comment réassembler les segments multimédias dans l'ordre de flux correct.

Exigences concernant les formats multimédias

L'ingestion HLS YouTube présente les exigences suivantes pour le contenu vidéo et audio:

  • La vidéo et l'audio doivent être multiplexés au format M2TS.
  • Les codecs vidéo compatibles sont H.264 et HEVC.
  • Les fréquences d'images sont acceptées jusqu'à 60 FPS.
  • Seuls les GOP fermés sont acceptés.
  • Le codec audio compatible est AAC, et seul l'audio mono est accepté.

Pour en savoir plus, consultez la section Segments multimédias.

HDR

Les vidéos HDR (High Dynamic Range) sont compatibles avec le codec HEVC et doivent respecter les conditions supplémentaires suivantes:

  • Les normes de couleur compatibles sont PQ 10 bits et HLG avec luminance non constante. Plus précisément :
    • Le format de chrominance doit être YUV 4:2:0 10 bits.
    • La fonction de transfert doit être PQ (également appelée SMPTE ST 2084) ou HLG (également appelée ARIB STD-B67).
    • Les primaires de couleur doivent être Rec. 2020.
    • Les coefficients matriciels doivent être de la luminance non constante du gamut Rec. 2020.
  • Les valeurs d'échantillonnage à plage limitée (ou plage MPEG) et à plage complète (ou plage JPEG) sont acceptées. Il est important que la plage soit définie en fonction de la plage de valeurs d'échantillon que le contenu utilise. Les valeurs d'échantillon à plage limitée sont recommandées.

Obtenir une URL d'ingestion HLS

Obtenir une URL d'ingestion HLS à partir de l'API YouTube

Pour obtenir l'URL d'ingestion complète, les encodeurs peuvent utiliser l'API YouTube Live Streaming pour insérer une ressource liveStream avec les propriétés suivantes:

"cdn": {
  "ingestionType": "hls",
  "frameRate": "variable",
  "resolution": "variable"
}

Dans la réponse de l'API, le champ cdn.ingestionInfo.ingestionAddress spécifie l'URL d'ingestion principale, et le champ cdn.ingestionInfo.backupIngestionAddress spécifie l'URL d'ingestion de secours. Pour en savoir plus, consultez la documentation de la ressource liveStreams.

Obtenir une URL d'ingestion HLS dans YouTube Creator Studio

Dans l'interface Web YouTube Creator Studio, après avoir cliqué sur "Créer un flux", le créateur voit s'afficher une "Clé de flux" composée de caractères alphanumériques et de traits d'union. Cette clé secrète identifie à la fois le créateur et le flux sur YouTube.

Vous pouvez créer une URL HLS à partir de cette clé de flux comme suit:

https://a.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=0&file=

... où $STREAM_KEY correspond à la clé de flux affichée dans l'interface Web. Exemple : https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst&copy=0&file=.

Pour plus de fiabilité, vous pouvez transmettre une deuxième copie redondante de l'ingestion à cette URL de sauvegarde:

https://b.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=1&file=

Notez que la sauvegarde présente deux différences par rapport à l'URL principale: le nom d'hôte et le paramètre copy= ont changé. L'ingestion de sauvegarde doit envoyer une valeur de paramètre copy= différente de celle de l'ingestion principale pour éviter de corrompre le flux.

Compléter l'URL d'ingestion HLS

Les URL obtenues à l'aide de l'une ou l'autre de ces méthodes sont des modèles incomplets. Chacune se termine par un paramètre de requête file= vide. Pour former l'URL finale, l'encodeur doit ajouter le nom de fichier d'une playlist multimédia ou d'un segment multimédia à la fin de l'URL, complétant ainsi le paramètre file=.

Les règles suivantes s'appliquent à la valeur du paramètre file=:

  • L'encodeur peut créer un nom de fichier de playlist multimédia ou de segment multimédia à partir de caractères alphanumériques, de traits de soulignement, de barres obliques, de traits d'union et de points. Aucun autre caractère n'est accepté.
  • L'encodeur ne doit pas encoder le nom de fichier en URL.
  • L'encodeur peut inclure des composants de chemin d'accès relatifs ou absolus dans les noms de fichiers, bien que cela ne soit jamais obligatoire. Si l'encodeur inclut un composant de chemin d'accès dans le nom de fichier d'un segment multimédia, il doit faire référence au même chemin d'accès dans l'entrée de playlist correspondante.

Exigences concernant le protocole HLS

Les playlists multimédias et les segments multimédias envoyés par l'encodeur doivent respecter la spécification HTTP Live Streaming 2e édition.

La spécification HLS définit deux types de playlist: la playlist multimédia et la playlist principale. Étant donné que YouTube transcode le contenu en streaming en différentes résolutions et débits, l'encodeur n'a pas besoin d'envoyer du contenu avec différents débits à YouTube. Par conséquent, YouTube n'accepte que les playlists multimédias pour l'ingestion HLS, et les playlists principales sont ignorées. (Une playlist principale fournit un ensemble de flux de variantes, chacun décrivant une version différente du même contenu.)

L'encodeur doit:

  • Envoyez exactement un seul flux encodé avec la résolution la plus élevée que vous souhaitez diffuser auprès des utilisateurs (résolution et codec uniques).
  • muxer l'audio et la vidéo ;
  • utiliser HTTPS et une connexion persistante pour toutes les requêtes.

Les sections suivantes contiennent des exigences plus spécifiques pour les playlists multimédias et les segments multimédias.

Playlists multimédias

Une playlist multimédia contient une liste de segments multimédias pouvant être concatenatés pour représenter un flux multimédia continu et décodable. La playlist multimédia indique au serveur les segments multimédias attendus et comment les organiser correctement dans le flux réassemblé.

Conditions requises

  • Le nom du fichier de la playlist multimédia doit se terminer par .m3u8 ou .m3u.

  • La première playlist multimédia envoyée pour un flux doit commencer au numéro de séquence 0, et ce numéro doit augmenter de manière monotone.

  • La balise EXT-X-MEDIA-SEQUENCE doit identifier le numéro de séquence du premier segment multimédia listé dans la playlist.

  • Une playlist multimédia ne doit pas contenir plus de cinq segments en cours. Un segment est en attente si le serveur ne l'a pas reçu ou n'a pas confirmé sa réception.

    En plus des segments en attente, incluez également quelques segments reconnus dans chaque playlist multimédia. Cette pratique réduit la probabilité qu'un segment soit ignoré si une playlist multimédia est perdue côté serveur. Par exemple, vous pouvez inclure jusqu'à deux segments confirmés et jusqu'à cinq segments en attente dans chaque playlist multimédia.

    Notez que le serveur confirme la réception d'un segment multimédia en renvoyant une réponse 200 (OK) ou 202 (Accepted) lors de l'importation de ce segment. Une réponse 202 indique que le serveur a reçu le segment avant qu'une playlist ne l'identifie.

  • Envoyez une playlist multimédia mise à jour pour chaque segment multimédia afin que le serveur puisse récupérer rapidement une playlist multimédia perdue.

  • Lorsque le serveur confirme la réception des segments multimédias, vous pouvez incrémenter la valeur de la balise EXT-X-MEDIA-SEQUENCE pour éviter que la playlist multimédia ne devienne trop longue. Par exemple, si le serveur a déjà confirmé la réception des neuf premiers segments multimédias, la prochaine playlist multimédia peut lister les huitième, neuvième et dixième segments multimédias.

  • Les balises EXT-X-KEY et EXT-X-SESSION-KEY ne sont pas acceptées.

Exemples

La liste suivante présente un exemple de fichiers que l'encodeur doit envoyer:

Media Playlist file with seqnum #0
Media Segment file #0
Media Playlist file with seqnum #0-#1
Media Segment file #1
Media Playlist file with seqnum #0-#2
Media Segment file #2
Media Playlist file with seqnum #1-#3
Media Segment file #3
...

L'exemple suivant montre une playlist multimédia envoyée au milieu d'une diffusion vidéo en direct. Comme l'exemple provient du milieu d'un flux, la balise EXT-X-MEDIA-SEQUENCE a une valeur non nulle.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:3.975,
fileSequence2680.ts
#EXTINF:3.941,
fileSequence2681.ts
#EXTINF:3.975,
fileSequence2682.ts

Segments multimédias

La liste suivante identifie les exigences concernant les segments multimédias:

  • Noms de fichiers
    • Les noms de fichiers de segments multimédias dans l'URL doivent comporter l'extension de nom de fichier .ts et doivent correspondre aux noms de fichiers de la playlist.
    • Les noms de fichiers de segments multimédias doivent être uniques entre les redémarrages de l'encodeur et les redémarrages du flux.
  • Format
    • Les segments multimédias doivent être au format M2TS et doivent s'initialiser automatiquement.
    • Chaque segment M2TS doit contenir un seul programme MPEG-2.
    • Le segment M2TS doit contenir un PAT et un PMT, et les deux premiers paquets de transport stream d'un segment doivent être un PAT et un PMT.
  • Contenu
    • La vidéo et l'audio doivent être multiplexés.
    • Les codecs vidéo compatibles sont H.264 et HEVC.
    • Le HDR avec HEVC est compatible (voir les Exigences concernant le HDR).
    • Les fréquences d'images sont acceptées jusqu'à 60 FPS.
    • Seuls les GOP fermés sont acceptés.
    • Le codec audio compatible est AAC, et seul l'audio mono est accepté.
    • Nous vous recommandons de définir la durée des segments multimédias entre une et quatre secondes, comme indiqué dans la section suivante. La durée des segments multimédias ne doit pas dépasser cinq secondes.
    • Les segments multimédias ne doivent être chiffrés que dans la couche TLS/SSL avec HTTPS. Les autres mécanismes de chiffrement ne sont pas acceptés.

Durée du segment multimédia

Nous prévoyons d'utiliser l'ingestion HLS pour les contenus premium qui nécessitent une qualité et une résolution élevées. La latence de l'ingestion HLS est généralement plus élevée que celle des ingestions basées sur RTMP et WebRTC, car l'ingestion HLS est basée sur des segments.

Nous vous recommandons de définir la durée des segments multimédias entre une et quatre secondes, car des segments multimédias plus courts peuvent entraîner une latence plus faible, mais au prix d'un taux de rebuffering plus élevé et d'une efficacité d'encodage plus faible. Comme indiqué dans la section précédente, les segments multimédias ne doivent pas dépasser cinq secondes.

Débits

Le Centre d'aide YouTube fournit des consignes sur les paramètres de débit.

Notez que le HEVC offre généralement une compression de données de 25% à 50% supérieure à celle du H.264 pour une même qualité vidéo. Par conséquent, les valeurs de débit à l'extrémité inférieure des plages suggérées peuvent être utilisées avec HEVC pour économiser de la bande passante, ce qui est particulièrement utile pour les contenus 4K.

Autres prérequis

  • Les encodeurs doivent définir l'en-tête User-Agent dans la requête HTTP à l'aide de la syntaxe suivante, qui inclut le nom du fabricant, le nom du modèle et la version:

    User-Agent: <manufacturer> / <model> / <version>

Sous-titres

L'ingestion HLS accepte deux options d'envoi de sous-titres:

  • Envoyez les sous-titres à l'aide de requêtes HTTP POST distinctes. Cela fonctionne pour toutes les ingestions HLS.
  • Les sous-titres intégrés 608/708 fonctionnent avec les ingestions HLS qui utilisent le codec vidéo H.264, mais pas avec celles qui utilisent le codec vidéo HEVC. Pour en savoir plus, consultez les Exigences concernant les sous-titres en direct dans le centre d'aide YouTube.

Codes de réponse HTTP

Les sections suivantes expliquent les codes de réponse que YouTube renvoie en réponse aux segments multimédias et aux playlists multimédias diffusés à l'aide de HLS.

200 (OK)

En réponse à une requête PUT ou POST, une réponse HTTP 200 (OK) indique que le serveur YouTube a reçu une opération attendue et qu'il l'a gérée avec succès.

En réponse à une requête DELETE, une réponse HTTP 200 (OK) indique que le serveur YouTube a reçu et ignoré la requête. Le serveur YouTube n'exige pas du client de supprimer une ressource du flux et ignore les requêtes DELETE. Pour des raisons de performances, YouTube recommande aux clients de ne pas envoyer de requêtes DELETE.

202 (Accepté)

Une réponse HTTP 202 (Accepté) indique que le serveur YouTube a reçu le segment multimédia avant de recevoir une playlist multimédia contenant ce segment multimédia. Cela indique au client qu'il doit envoyer la playlist multimédia contenant ce segment multimédia dès que possible pour éviter tout retard dans le traitement de ce segment. Notez que ce ne sera pas un problème si l'encodeur envoie une playlist multimédia mise à jour pour chaque segment multimédia.

400 (Requête incorrecte)

Une réponse HTTP 400 (Bad Request) indique que l'un des problèmes suivants s'est produit:

  • Format d'URL incorrect
  • La playlist ne peut pas être analysée ou contient des balises non prises en charge
401 (Opération non autorisée)

Une réponse HTTP 401 (Non autorisé) indique que le paramètre cid de l'URL de base du point de terminaison HLS YouTube est corrompu ou expiré. Le client doit mettre à jour le paramètre cid pour continuer.

405 (Méthode non autorisée)

Une réponse HTTP 405 (Méthode non autorisée) indique que la requête n'était pas une requête POST, PUT ou DELETE.

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 réessayer la requête avec un intervalle exponentiel entre les tentatives.