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

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 est destiné aux les fournisseurs d'encodeurs qui souhaitent ajouter la prise en charge de l'ingestion HLS à leurs produits. HLS est un bon choix pour les contenus premium qui nécessitent haute résolution avec une latence relativement élevée. En bref Comparaison des différents protocoles d'ingestion utilisés sur YouTube En direct Le streaming est compatible avec comparatif des protocoles d'ingestion de diffusions en direct sur YouTube.

Pour diffuser des données en direct à l'aide du HLS, l'encodeur doit envoyer une série d'éléments multimédias Playlists et segments multimédias vers le point de terminaison HLS de YouTube à l'aide de HTTP PUT ou Requêtes POST. Du point de vue de l'encodeur, le point de terminaison YouTube semble être un serveur HTTP passif.

Chaque segment multimédia représente le contenu multimédia réel pour un bref passage du flux pendant une durée entre une et quatre secondes. Chaque playlist de contenus multimédias explique comment reconstituer les segments multimédias dans le bon ordre de diffusion.

Exigences relatives au format des supports

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

Les contenus audio et 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 images par seconde sont acceptées.
Seuls les GOP fermés sont acceptés.
Le codec audio AAC est pris en charge. Seule une piste audio unique est acceptée.

Consultez la section Segments multimédias pour en savoir plus sur les exigences à respecter.

HDR

Les vidéos HDR (High Dynamic Range) sont compatibles avec le codec HEVC et possèdent la exigences supplémentaires suivantes:

Les normes de couleur compatibles sont les PQ 10 bits et les HLG à luminance non constante. Plus précisément: <ph type="x-smartling-placeholder">
- 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é ARIB STD-B67).
- Les primaires de couleur doivent être des valeurs "Rec". 2020.
- Les coefficients matriciels doivent être conformes au paramètre Rec. Luminance non constante de 2020.
Échantillon à plage limitée (ou MPEG) et à plage complète (ou JPEG) sont prises en charge. Il est important que la plage soit définie en fonction exemple de plage de valeurs utilisée par le contenu. Les valeurs d'échantillon à plage limitée sont recommandé.

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 la page Streaming en direct sur YouTube API pour insérer une diffusion en direct par les éléments suivants : propriétés:

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

Obtenir une URL d'ingestion HLS depuis YouTube Creator Studio

Dans l'interface Web de YouTube Creator Studio, après que le créateur a cliqué sur "Créer" "Stream" (Flux), YouTube affiche une "clé de flux" composée de caractères alphanumériques caractères et traits d'union. Cette clé secrète identifie à la fois le créateur et le diffuser 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 est 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'inventaire à 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 est et le paramètre copy= ont changé. L'ingestion des sauvegardes doit envoyer une valeur de paramètre copy= différente de celle de l'ingestion principale pour éviter corrompre le flux.

Complétez l'URL d'ingestion HLS.

Les URL obtenues à l'aide de l'une ou l'autre méthode sont des modèles incomplets. chaque se termine avec 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 ; 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 ou de segment multimédia à partir de Les caractères alphanumériques, les traits de soulignement, les barres obliques, les traits d'union et les points aucun autre caractère n'est pris en charge.
L'encodeur ne doit pas encoder en URL le nom de fichier.
L'encodeur peut inclure des composants de chemin relatif ou absolu dans les noms de fichiers, mais ce n'est jamais obligatoire. Si l'encodeur inclut un composant de chemin dans le nom de fichier d'un segment multimédia, il doit faire référence au même chemin d'accès dans le la playlist correspondante.

Exigences concernant le protocole HLS

Les listes de lecture et les segments multimédias envoyés par l'encodeur doivent être conformes au le service HTTP Live Streaming 2nd Edition Spécification.

La spécification HLS définit deux types de playlists: les playlists multimédias et les playlists principales. Playlist. YouTube transcode les contenus diffusés à différentes résolutions et l'encodeur n'a pas besoin d'envoyer du contenu avec des débits différents YouTube Par conséquent, YouTube n'accepte que les playlists de contenus multimédias pour l'ingestion HLS, et les playlists maîtres sont ignorées. Une playlist principale propose plusieurs variantes flux, chacun décrivant une version différente du même contenu)

L'encodeur doit:

d'envoyer exactement un flux encodé avec la résolution la plus élevée que vous souhaitez sont diffusées auprès des utilisateurs (résolution unique et codec).
mux audio et vidéo.
utilisent HTTPS et une connexion persistante pour toutes les requêtes.

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

Playlists de contenus multimédias

Une playlist de contenus multimédias contient une liste de segments multimédias qui peuvent être concaténés représentent un flux multimédia continu et décodable. La playlist multimédia indique au serveur quels sont les segments multimédias attendus et comment les organiser correctement dans 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 le numéro de séquence doivent augmenter de façon monotone.
La balise EXT-X-MEDIA-SEQUENCE doit identifier le numéro de séquence de la le premier segment multimédia de la playlist.
Une playlist multimédia ne doit pas contenir plus de cinq segments en attente. A segment est en attente si le serveur ne l'a pas reçu ou n'en a pas accusé réception. à sa réception.

Outre les segments en suspens, incluez également quelques segments reconnus dans chaque playlist de contenus multimédias. Ainsi, il est moins probable qu'un segment à ignorer si une playlist multimédia est perdue côté serveur. Pour Par exemple, vous pouvez inclure jusqu'à deux segments confirmés et jusqu'à cinq segments en suspens dans chaque playlist de média.

Notez que le serveur accuse réception d'un segment multimédia en renvoyant un 200 (OK) ou 202 (Accepted) pour l'importation de ce segment. A La réponse 202 indique que le serveur a reçu le segment avant une la playlist qui identifie ce segment.
Envoyez une playlist de contenus multimédias mise à jour pour chaque segment multimédia, afin que peut récupérer rapidement en cas de perte d'une playlist multimédia.
Lorsque le serveur accuse réception des segments multimédias, vous pouvez incrémenter la valeur Valeur de balise EXT-X-MEDIA-SEQUENCE pour empêcher la playlist multimédia de devenir Trop long. Par exemple, si le serveur a déjà accusé réception de la les neuf premiers segments multimédias, la playlist suivante peut inclure le 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 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 présente une playlist multimédia envoyée au milieu d'une vidéo en direct. flux. Étant donné que l'exemple provient du milieu d'un flux, La valeur de la balise EXT-X-MEDIA-SEQUENCE est 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 définit les exigences relatives aux segments multimédias:

Noms de fichiers
- Les noms de fichiers de segments multimédias dans l'URL doivent porter le nom .ts. et doit correspondre aux noms de fichiers de la playlist.
- Les noms de fichier de segment multimédia 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 s'auto-initialiser.
- Chaque segment M2TS doit contenir un seul programme MPEG-2.
- Le segment M2TS doit contenir un PAT et un PMT, et les deux premiers Les paquets du flux de transport dans un segment doivent être des PAT et des PMT.
Contenu
- La vidéo et l'audio doivent être multiplexés.
- Les codecs vidéo compatibles sont H.264 et HEVC.
- Le format HDR avec HEVC est compatible (voir les conditions requises pour la technologie HDR).
- Les fréquences d'images jusqu'à 60 images par seconde sont acceptées.
- Seuls les GOP fermés sont acceptés.
- Le codec audio compatible est AAC et seul le contenu audio monopiste est compatibles.
- La durée recommandée pour les segments multimédias est comprise entre un et quatre secondes, comme expliqué 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 compatibles.

Durée du segment multimédia

L'ingestion HLS devrait être utilisée pour le contenu premium qui nécessite un niveau élevé en haute résolution. L'ingestion HLS présente généralement une latence plus élevée que le protocole RTMP, et les ingestions basées sur WebRTC, car l'ingestion HLS est basée sur des segments.

Nous recommandons une durée du segment multimédia d'une à quatre secondes, car de petits segments multimédias peut réduire la latence, mais pour un coût une fréquence de mise en mémoire tampon réduite et 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

L'Aide YouTube d'accessibilité fournit des consignes concernant les paramètres de débit.

Notez que le format HEVC offre généralement 25 à 50 % de compression des données en plus en même temps par rapport à la norme H.264. Par conséquent, les valeurs de débit situées dans la partie inférieure les plages suggérées peuvent être utilisées avec le format 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 méthode qui inclut le nom du fabricant, le nom du modèle et version:
```
User-Agent: <manufacturer> / <model> / <version>
```
Remarque :Ces informations ne seront utilisées qu'à des fins de débogage. Elle ne sera pas utilisée pour prendre des décisions fonctionnelles dans la gestion des flux.

Sous-titres

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

Envoyez des sous-titres à l'aide de requêtes HTTP POST distinctes. Cela fonctionne pour tous Ingestions HLS.
Les sous-titres intégrés 608/708 fonctionnent avec les ingestions HLS qui utilisent le format H264 le codec vidéo, mais pas avec les ingestions utilisant le codec vidéo HEVC. Pour plus consultez les Exigences concernant les sous-titres instantanés. dans le centre d'aide YouTube.

Codes de réponse HTTP

Les sections suivantes décrivent les codes de réponse renvoyés par YouTube réponse aux segments de médias et aux playlists de médias diffusées via le 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 l'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 demande. Le serveur YouTube effectue n'exigent pas du client DELETE les ressources du flux, et ignore DELETE. Pour des raisons de performances, YouTube recommande aux clients n'envoyez pas de DELETE.

202 (Accepté)

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

400 (Requête incorrecte)

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

Format d'URL incorrect
Impossible d'analyser la playlist, ou celle-ci contient des balises non compatibles

401 (Opération non autorisée)

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

405 (Méthode non autorisée)

Une réponse HTTP 405 (Méthode non autorisée) indique que la requête a été et non 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 a été ne peut pas traiter la demande. Pour cette erreur, nous vous recommandons de relancer la à l'aide d'une requête entre les tentatives.