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. Il est destiné 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 en flux continu compatibles avec YouTube En direct, consultez Comparaison des protocoles d'ingestion en flux continu de YouTube En direct.

Pour diffuser des données en direct à l'aide du protocole 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 HLS de 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 le bon ordre de flux.

Exigences concernant le format multimédia

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

  • L'audio et la vidéo 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.
  • Seul le GOP fermé est accepté.
  • Le codec audio compatible est AAC, et seul l'audio à une seule piste est accepté.

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

HDR

La vidéo HDR (High Dynamic Range) est compatible avec le codec HEVC et présente les exigences supplémentaires suivantes :

  • Les normes de couleur compatibles sont PQ 10 bits et HLG avec une 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 Rec. 2020 avec une luminance non constante.
  • 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. 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 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 pour la ressource liveStreams.

Obtenir une URL d'ingestion HLS à partir de YouTube Studio

Dans l'interface Web de YouTube 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 traits d'union. Cette clé secrète identifie à la fois le créateur et le flux auprès de 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. Par 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 des 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 ou d'un segment multimédia à la fin de l'URL, ce qui complète 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 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 l'URL du nom de fichier.
  • 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 un nom de fichier de 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 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 exactement un flux encodé avec la résolution la plus élevée que vous souhaitez proposer aux utilisateurs (résolution et codec uniques).
  • multiplexer 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 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 multimédia indique au serveur les segments multimédias à attendre et comment les ordonner correctement dans le flux réassemblé.

Conditions requises

  • Le nom de 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 par le numéro de séquence 0 , et le numéro de séquence doit augmenter de manière monotone.

  • Le tag 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 attente. 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 multimédia 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 200 (OK) ou 202 (Accepted) réponse 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 les données si une playlist multimédia est perdue.

  • Lorsque le serveur accuse 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 tags EXT-X-KEY et EXT-X-SESSION-KEY ne sont pas acceptés.

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'un flux vidéo en direct. Comme l'exemple provient du milieu d'un flux, le tag EXT-X-MEDIA-SEQUENCE a une valeur différente de zéro.

#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 des segments multimédias dans l'URL doivent avoir l'extension .ts et correspondre aux noms de fichiers de la playlist.
    • Les noms de fichiers des 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 doivent s'initialiser automatiquement.
    • Chaque segment M2TS doit contenir un seul programme MPEG-2.
    • Le segment M2TS doit contenir une PAT et une PMT, et les deux premiers paquets de flux de transport d'un segment doivent être une PAT et une PMT.
  • Contenu
    • L'audio et la vidéo doivent être multiplexés.
    • Les codecs vidéo compatibles sont H.264 et HEVC.
    • Le HDR avec HEVC est accepté (voir les exigences concernant le HDR).
    • Les fréquences d'images jusqu'à 60 FPS sont acceptées.
    • Seul le GOP fermé est accepté.
    • 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 avoir une durée supérieure à 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 des segments multimédias

Nous nous attendons à ce que l'ingestion HLS soit utilisée pour les contenus premium qui nécessitent une qualité et une résolution élevées. 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 multimédia comprise entre une et quatre secondes, car des segments multimédias plus petits peuvent entraîner une latence plus faible, mais au prix d'un taux de mise en mémoire tampon 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 durer plus de cinq secondes.

Débits

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

Notez que le codec HEVC génère généralement une compression des données de 25 à 50 % supérieure à celle du codec H.264 pour la même qualité vidéo. Par conséquent, les valeurs de débit situées dans la partie inférieure des plages suggérées peuvent être utilisées avec le codec 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 est compatible avec deux options pour l'envoi de sous-titres :

  • Envoyez des sous-titres à l'aide de requêtes HTTP POST distinctes. Cette méthode fonctionne pour toutes les ingestions HLS.
  • Les sous-titres 608/708 intégrés fonctionnent avec les ingestions HLS qui utilisent le codec vidéo H264, mais pas avec les ingestions 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 renvoyés par YouTube en réponse aux segments et playlists multimédias fournis à l'aide du protocole 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 gérée correctement.

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 que le client supprime une ressource dans le flux, et il 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. Cela indique au client qu'il doit envoyer la playlist multimédia contenant ce segment multimédia dès que possible pour éviter un délai de traitement de ce segment. Notez que cela ne posera pas de 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 (Requête incorrecte) 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 acceptés
401 (Opération non autorisée)

Une réponse HTTP 401 (Opération non autorisée) indique que le paramètre cid de l'URL de base du point de terminaison HLS de YouTube 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 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 réessayer la requête avec un intervalle exponentiel entre les tentatives.