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 En direct, consultez Comparaison des protocoles d'ingestion YouTube En direct.

Pour diffuser des données en direct à l'aide de HLS, l'encodeur doit envoyer une série de playlists 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 YouTube HLS ressemble à un serveur HTTP passif.

Chaque segment multimédia représente le contenu multimédia réel pour 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 le bon ordre de flux.

Exigences concernant le format du contenu multimédia

L'ingestion HLS YouTube présente les exigences suivantes pour les contenus 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 jusqu'à 60 FPS sont acceptées.
  • Seuls les GOP fermés sont acceptés.
  • Le codec audio compatible est AAC, et seul l'audio mono-piste est accepté.

Pour en savoir plus sur les exigences, consultez la section Segments média.

HDR

Les vidéos HDR (High Dynamic Range) sont compatibles avec le codec HEVC et sont soumises aux exigences supplémentaires suivantes :

  • Les normes de couleur acceptées sont PQ et HLG 10 bits avec une luminance non constante. Plus précisément :
    • Le format de chroma 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 correspondre à la luminance non constante du gamut Rec. 2020.
  • Les valeurs d'échantillon à 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 utilisée par le contenu. Il est recommandé d'utiliser des valeurs d'échantillon à plage limitée.

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 En direct 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 sauvegarde. Pour en savoir plus, consultez la documentation sur la ressource liveStreams.

Obtenir une URL d'ingestion HLS depuis YouTube Creator Studio

Dans l'interface Web YouTube Creator Studio, une fois que le créateur a cliqué sur "Créer un flux", YouTube affiche une clé de flux composée de caractères alphanumériques et de tirets. 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 sous forme d'URL.
  • L'encodeur peut inclure des composants de chemin d'accès relatifs ou absolus dans les noms de fichiers, mais ce n'est 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 et les segments multimédias envoyés par l'encodeur doivent être conformes à la spécification HTTP Live Streaming 2nd Edition.

La spécification HLS définit deux types de playlists : la playlist multimédia et la playlist principale. Étant donné que YouTube transcode le contenu diffusé en streaming en différentes résolutions et différents débits, l'encodeur n'a pas besoin d'envoyer de 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 :

  • envoyer un seul flux encodé avec la résolution la plus élevée que vous souhaitez proposer aux utilisateurs (une seule résolution et un seul codec).
  • mux audio and video.
  • utiliser HTTPS et une connexion persistante pour toutes les requêtes.

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

Playlists multimédias

Une playlist multimédia contient une liste de segments multimédias qui peuvent être concaténés pour représenter un flux multimédia continu et décodable. La playlist média indique au serveur les segments média à attendre et comment les ordonner correctement dans le flux reconstitué.

Conditions requises

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

  • La première playlist multimédia envoyée pour un flux doit commencer par le numéro de séquence 0, et le numéro de séquence doit augmenter de façon 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 mé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 accusé réception.

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

    Notez que le serveur accuse 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 une playlist identifiant ce segment.

  • 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 du tag EXT-X-MEDIA-SEQUENCE pour éviter que la playlist multimédia ne devienne trop longue. Par exemple, si le serveur a déjà accusé réception des neuf premiers segments multimédias, la playlist multimédia suivante 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 montre un exemple des fichiers que l'encodeur est censé 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, le tag 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 média

La liste suivante identifie les exigences concernant les segments média :

  • Noms de fichiers
    • Les noms de fichiers des segments multimédias dans l'URL doivent comporter l'extension .ts et correspondre à ceux de la playlist.
    • Les noms de fichiers de segments multimédias doivent être uniques lors des redémarrages de l'encodeur et des redémarrages du flux.
  • Format
    • Les segments multimédias doivent être au format M2TS et être auto-initialisés.
    • Chaque segment M2TS doit contenir un seul programme MPEG-2.
    • Le segment M2TS doit contenir une PAT et une PMT. Les deux premiers paquets Transport Stream d'un segment doivent être une PAT et une 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 pris en charge (voir les exigences relatives au HDR).
    • Les fréquences d'images jusqu'à 60 FPS sont acceptées.
    • Seuls les GOP fermés sont acceptés.
    • Le codec audio compatible est AAC, et seul l'audio à une seule piste est accepté.
    • Il est recommandé que les segments multimédias aient une durée comprise entre une et quatre secondes, comme indiqué dans la section suivante. Les segments multimédias ne doivent pas durer plus de 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 média

Nous nous attendons à ce que l'ingestion HLS soit utilisée pour les contenus premium qui nécessitent une haute qualité et une haute résolution. L'ingestion HLS présente généralement une latence plus élevée que les ingestions basées sur RTMP et WebRTC, car elle est basée sur des segments.

Nous recommandons une durée de segment média comprise entre une et quatre secondes, car des segments média plus petits peuvent entraîner une latence plus faible, mais au prix d'un taux de rembobinage plus élevé et d'une efficacité d'encodage plus faible. Comme indiqué dans la section précédente, les segments média ne doivent pas durer plus de cinq secondes.

Débits

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

Notez que le codec HEVC permet généralement de compresser les données 25 % à 50 % de plus que le codec H.264, tout en conservant la même qualité vidéo. Ainsi, les valeurs de débit binaire inférieures des plages suggérées peuvent être utilisées avec HEVC pour économiser de la bande passante, ce qui est particulièrement utile pour le contenu 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 est compatible avec 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 H264, mais pas avec celles qui utilisent le codec vidéo HEVC. Pour en savoir plus, consultez les exigences concernant les sous-titres instantanés 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 l'a traité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 qu'il SUPPRIME une ressource dans le flux et ignore les requêtes DELETE. Pour des raisons de performances, YouTube recommande aux clients de ne pas envoyer de 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. 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 problème ne se posera pas 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 tags non compatibles
401 (Opération non autorisée)

Une réponse HTTP 401 (non autorisée) indique que le paramètre "cid" de l'URL de base du point de terminaison YouTube HLS est corrompu ou a 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.