YouTube-Liveinhalte über HLS bereitstellen

In diesem Dokument wird erläutert, wie Sie das HLS-Protokoll (HTTP Live Streaming) verwenden, um Live-Daten von einem Encoder auf YouTube zu streamen. Dieses Dokument richtet sich an Encoder-Anbieter, die ihren Produkten Unterstützung für die HLS-Datenaufnahme hinzufügen möchten. Die HLS-Datenaufnahme ist eine gute Wahl für Premium-Inhalte, die eine hohe Qualität und hohe Auflösung bei einer relativ höheren Latenz erfordern. Einen kurzen Vergleich verschiedener Datenaufnahmeprotokolle, die von YouTube Live Streaming unterstützt werden, finden Sie unter Vergleich der Datenaufnahmeprotokolle für YouTube Live Streaming.

Um Live-Daten mit HLS zu streamen, sollte der Encoder eine Reihe von Media Playlists und Media Segments mit HTTP PUT- oder POST-Anfragen an den HLS-Endpunkt von YouTube senden. Aus Sicht des Encoders ist der HLS-Endpunkt von YouTube ein passiver HTTP-Server.

Jedes Media Segment stellt den eigentlichen Multimedia-Inhalt für einen kurzen Teil des Streams dar, der zwischen einer und vier Sekunden dauert. Jede Media Playlist beschreibt, wie die Media Segments in der richtigen Streamreihenfolge wieder zusammengesetzt werden.

Anforderungen an das Media-Format

Für die YouTube-HLS-Datenaufnahme gelten die folgenden Anforderungen an Video- und Audioinhalte:

• Video und Audio müssen im M2TS-Format gemuxt werden.
• Unterstützte Video-Codecs sind H.264 und HEVC.
• Bildraten von bis zu 60 fps werden unterstützt.
• Nur geschlossene GOPs werden unterstützt.
• Der unterstützte Audio-Codec ist AAC und es wird nur Audio mit einer Spur unterstützt.

Weitere Informationen finden Sie im Abschnitt zu Media Segments.

HDR

HDR-Videos (High Dynamic Range) werden mit dem HEVC-Codec unterstützt und unterliegen den folgenden zusätzlichen Anforderungen:

• Unterstützte Farbstandards sind 10-Bit-PQ und HLG mit nicht konstanter Leuchtdichte. Genauer gesagt:
  • Das Chroma-Format muss YUV 4:2:0 10-Bit sein.
  • Die Transferfunktion muss PQ (auch bekannt als SMPTE ST 2084) oder HLG (auch bekannt als ARIB STD-B67) sein.
  • Die Farbräume müssen Rec. 2020 sein.
  • Die Matrix-Koeffizienten müssen Rec. 2020, nicht konstante Leuchtdichte sein.
• Es werden sowohl eingeschränkte (oder MPEG-) als auch vollständige (oder JPEG-) Beispielwerte unterstützt. Der Bereich muss entsprechend dem Bereich der Beispielwerte festgelegt werden, der für die Inhalte verwendet wird. Es werden eingeschränkte Beispielwerte empfohlen.

HLS-Datenaufnahme-URL abrufen

HLS-Datenaufnahme-URL über die YouTube API abrufen

Um die vollständige Datenaufnahme-URL abzurufen, können Encoder die YouTube Live Streaming API verwenden, um eine liveStream Ressource mit den folgenden Eigenschaften einzufügen:

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

In der API-Antwort gibt das Feld cdn.ingestionInfo.ingestionAddress die primäre Datenaufnahme-URL und das Feld cdn.ingestionInfo.backupIngestionAddress die Backup-Datenaufnahme-URL an. Weitere Informationen finden Sie in der Dokumentation zu der liveStreams Ressource.

HLS-Datenaufnahme-URL über YouTube Studio abrufen

Achtung: Diese Methode zum Abrufen von HLS-Datenaufnahme-URLs ist eine Betafunktion und kann sich in Zukunft ändern.

Wenn der Creator in der Weboberfläche von YouTube Studio auf „Stream erstellen“ klickt, zeigt YouTube einen „Streamschlüssel“ an, der aus alphanumerischen Zeichen und Bindestrichen besteht. Dieser geheime Schlüssel identifiziert sowohl den Creator als auch den Stream für YouTube.

Sie können eine HLS-URL aus diesem Streamschlüssel erstellen:

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

Dabei ist $STREAM_KEY der Streamschlüssel, der in der Weboberfläche angezeigt wird. Beispiel: https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst&copy=0&file=

Für zusätzliche Zuverlässigkeit können Sie eine redundante zweite Kopie der Datenaufnahme an diese Backup-URL senden:

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

Die Backup-URL unterscheidet sich in zwei Punkten von der primären URL: Sowohl der Hostname als auch der Parameter copy= haben sich geändert. Bei der Backup-Datenaufnahme muss ein anderer Parameterwert copy= gesendet werden als bei der primären Datenaufnahme, um eine Beschädigung des Streams zu vermeiden.

HLS-Datenaufnahme-URL vervollständigen

URLs, die mit einer der beiden Methoden abgerufen werden, sind unvollständige Vorlagen. Jede endet mit einem leeren Suchparameter file=. Um die finale URL zu erstellen, muss der Encoder den Dateinamen einer Media Playlist oder eines Media Segments an das Ende der URL anhängen und so den Parameter file= vervollständigen.

Für den Wert des Parameters file= gelten die folgenden Regeln:

• Der Encoder kann einen Dateinamen für eine Media Playlist oder ein Media Segment aus alphanumerischen Zeichen, Unterstrichen, Schrägstrichen, Bindestrichen und Punkten erstellen. Andere Zeichen werden nicht unterstützt.
• Der Encoder darf den Dateinamen nicht URL-codieren.
• Der Encoder kann relative oder absolute Pfadkomponenten in Dateinamen einfügen, dies ist jedoch nicht erforderlich. Wenn der Encoder eine Pfadkomponente in einen Dateinamen für ein Media Segment einfügt, muss er im entsprechenden Playlist-Eintrag denselben Pfad angeben.

Anforderungen an das HLS-Protokoll

Die vom Encoder gesendeten Media Playlists und Media Segments müssen der HTTP Live Streaming 2nd Edition Specificationentsprechen.

Die HLS-Spezifikation definiert zwei Arten von Playlists: Media Playlist und Master Playlist. Da YouTube gestreamte Inhalte in verschiedene Auflösungen und Bitraten transcodiert, muss der Encoder keine Inhalte mit unterschiedlichen Bitraten an YouTube senden. Daher unterstützt YouTube nur Media Playlists für die HLS-Datenaufnahme. Master Playlists werden ignoriert. Eine Masterplaylist enthält eine Reihe von Variant Streams, die jeweils eine andere Version desselben Inhalts beschreiben.

Der Encoder muss:

• genau einen codierten Stream mit der höchsten Auflösung senden, die Sie Nutzern bereitstellen möchten (eine Auflösung und ein Codec).
• Audio und Video muxen.
• für alle Anfragen HTTPS und eine persistente Verbindung verwenden.

In den folgenden Abschnitten finden Sie genauere Anforderungen an Media Playlists und Media Segments.

Media Playlists

Eine Media Playlist enthält eine Liste von Media Segments, die verkettet werden können, um einen kontinuierlichen, decodierbaren Multimedia-Stream darzustellen. Die Media Playlist teilt dem Server mit, welche Media Segments erwartet werden und wie sie im wieder zusammengesetzten Stream richtig angeordnet werden.

Voraussetzungen

• Der Dateiname der Media Playlist muss entweder auf .m3u8 oder .m3u enden.

• Die erste Media Playlist, die für einen Stream gesendet wird, muss mit der Sequenznummer 0 beginnen und die Sequenznummer muss monoton ansteigen.

• Das Tag EXT-X-MEDIA-SEQUENCE muss die Sequenznummer des ersten in der Playlist aufgeführten Media Segments angeben.

• Eine Media Playlist darf nicht mehr als fünf ausstehende Segmente enthalten. Ein Segment ist ausstehend, wenn der Server es nicht erhalten oder den Empfang nicht bestätigt hat.

  Fügen Sie jeder Media Playlist zusätzlich zu den ausstehenden Segmenten auch einige bestätigte Segmente hinzu. So ist es weniger wahrscheinlich, dass ein Segment übersprungen wird, wenn eine Media Playlist serverseitig verloren geht. Sie können beispielsweise in jeder Media Playlist bis zu zwei bestätigte und bis zu fünf ausstehende Segmente einfügen.

  Der Server bestätigt den Empfang eines Media Segments, indem er beim Hochladen dieses Segments eine 200- (OK) oder 202-Antwort (Accepted) zurückgibt. Eine 202-Antwort gibt an, dass der Server das Segment vor einer Playlist erhalten hat, die dieses Segment identifiziert.

• Senden Sie für jedes Media Segment eine aktualisierte Media Playlist, damit der Server sich schnell erholen kann, wenn eine Media Playlist verloren geht.

• Wenn der Server den Empfang von Media Segments bestätigt, können Sie den Wert des Tags EXT-X-MEDIA-SEQUENCE erhöhen, um zu verhindern, dass die Media Playlist zu lang wird. Wenn der Server beispielsweise den Empfang der ersten neun Media Segments bereits bestätigt hat, kann die nächste Media Playlist das achte, neunte und zehnte Media Segment auflisten.

• Die Tags EXT-X-KEY und EXT-X-SESSION-KEY werden nicht unterstützt.

Beispiele

Die folgende Liste zeigt ein Beispiel für die Dateien, die der Encoder senden soll:

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
...

Das folgende Beispiel zeigt eine Media Playlist, die in der Mitte eines Live-Videostreams gesendet wird. Da sich das Beispiel in der Mitte eines Streams befindet, hat das Tag EXT-X-MEDIA-SEQUENCE einen Wert ungleich null.

#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

Media Segments

Die folgende Liste enthält Anforderungen für Media Segments:

• Dateinamen
  • Die Dateinamen der Media Segments in der URL müssen die Dateinamenerweiterung .ts haben und mit den Dateinamen in der Playlist übereinstimmen.
  • Die Dateinamen der Media Segments müssen bei Encoder-Neustarts und Stream-Neustarts eindeutig sein.
• Format
  • Media Segments müssen im M2TS-Format vorliegen und selbstinitialisierend sein.
  • Jedes M2TS-Segment muss ein einzelnes MPEG-2-Programm enthalten.
  • Das M2TS-Segment muss eine PAT und eine PMT enthalten. Die ersten beiden Transport Stream-Pakete in einem Segment sollten eine PAT und eine PMT sein.
• Inhalt
  • Video und Audio müssen gemuxt werden.
  • Unterstützte Video-Codecs sind H.264 und HEVC.
  • HDR mit HEVC wird unterstützt (siehe HDR-Anforderungen).
  • Bildraten von bis zu 60 fps werden unterstützt.
  • Nur geschlossene GOPs werden unterstützt.
  • Der unterstützte Audio-Codec ist AAC und es wird nur Audio mit einer Spur unterstützt.
  • Media Segments sollten eine Länge zwischen einer und vier Sekunden haben, wie im folgenden Abschnitt erläutert. Media Segments dürfen nicht länger als 5 Sekunden sein.
  • Media Segments dürfen nur in der TLS/SSL-Schicht mit HTTPS verschlüsselt werden. Andere Verschlüsselungsmechanismen werden nicht unterstützt.

Länge von Media Segments

Wir gehen davon aus, dass die HLS-Datenaufnahme für Premium-Inhalte verwendet wird, die eine hohe Qualität und hohe Auflösung erfordern. Die HLS-Datenaufnahme hat in der Regel eine höhere Latenz als die auf RTMP und WebRTC basierenden Datenaufnahmen, da sie segmentbasiert ist.

Wir empfehlen eine Länge von ein bis vier Sekunden für Media Segments, da kleinere Media Segments zu einer geringeren Latenz führen können, allerdings auf Kosten einer höheren Rebuffer-Rate und einer geringeren Codierungseffizienz. Wie im vorherigen Abschnitt erwähnt, dürfen Media Segments nicht länger als 5 Sekunden sein.

Bitraten

In der YouTube-Hilfe finden Sie Richtlinien für die Bitrateneinstellungen.

HEVC bietet im Allgemeinen eine 25 bis 50 % höhere Datenkomprimierung bei gleicher Videoqualität im Vergleich zu H.264. Daher können mit HEVC Bitratenwerte im unteren Bereich der empfohlenen Bereiche verwendet werden, um Bandbreite zu sparen. Das ist besonders nützlich für 4K-Inhalte.

Andere Anforderungen

• Encoder sollten den Header User-Agent in der HTTP-Anfrage mit der folgenden Syntax festlegen, die den Namen des Herstellers, den Modellnamen und die Version enthält:

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

  Hinweis: Diese Informationen werden nur zu Debugging-Zwecken verwendet. Sie werden nicht für funktionale Entscheidungen bei der Streamverarbeitung verwendet.

Untertitel

Die HLS-Datenaufnahme unterstützt zwei Optionen zum Senden von Untertiteln:

• Untertitel mit separaten HTTP POST-Anfragen senden. Diese Option funktioniert für alle HLS-Datenaufnahmen.
• Eingebettete 608/708-Untertitel funktionieren mit HLS-Datenaufnahmen, die den H264 Video-Codec verwenden, aber nicht mit Datenaufnahmen, die den HEVC-Video-Codec verwenden. Weitere Informationen finden Sie in der YouTube-Hilfe unter Anforderungen an automatische Untertitel.

HTTP-Antwortcodes

In den folgenden Abschnitten werden die Antwortcodes erläutert, die YouTube als Antwort auf Media Segments und Media Playlists zurückgibt, die mit HLS bereitgestellt werden.

200 (OK)

Als Antwort auf eine PUT- oder POST-Anfrage gibt eine HTTP-Antwort 200 (OK) an, dass der YouTube-Server einen erwarteten Vorgang erhalten und erfolgreich verarbeitet hat.

Als Antwort auf eine DELETE-Anfrage gibt eine HTTP-Antwort 200 (OK) an, dass der YouTube-Server die Anfrage erhalten und ignoriert hat. Der YouTube-Server erfordert nicht, dass der Client Ressourcen im Stream löscht, und er ignoriert DELETE-Anfragen. Aus Leistungsgründen empfiehlt YouTube, dass Clients keine DELETE-Anfragen senden.

202 (Akzeptiert)

Eine HTTP-Antwort 202 (Akzeptiert) gibt an, dass der YouTube-Server das Media Segment erhalten hat, bevor er eine Media Playlist erhalten hat, die dieses Media Segment enthält. Dies weist den Client darauf hin, dass er die Media Playlist, die dieses Media Segment enthält, so schnell wie möglich senden sollte, um eine Verzögerung bei der Verarbeitung dieses Segments zu vermeiden. Dieses Problem tritt nicht auf, wenn der Encoder für jedes Media Segment eine aktualisierte Media Playlist sendet.

400 (Bad Request)

Eine HTTP-Antwort 400 (Bad Request) gibt an, dass eines der folgenden Probleme aufgetreten ist:

• Die URL ist fehlerhaft.
• Die Playlist kann nicht geparst werden oder enthält nicht unterstützte Tags.

401 (Unauthorized)

Eine HTTP-Antwort 401 (Unauthorized) gibt an, dass der Parameter `cid` in der Basis-URL für den HLS-Endpunkt von YouTube beschädigt oder abgelaufen ist. Der Client sollte den Parameter cid aktualisieren, um fortzufahren.

405 (Method Not Allowed)

Eine HTTP-Antwort 405 (Method Not Allowed) gibt an, dass die Anfrage keine POST-, PUT- oder DELETE-Anfrage war.

500 (Internal Server Error)

Eine HTTP-Antwort 500 (Internal Server Error) gibt an, dass der Server die Anfrage nicht verarbeiten konnte. Bei diesem Fehler empfehlen wir, die Anfrage mit exponentiellem Backoff zu wiederholen.