YouTube-Liveinhalte über HLS bereitstellen

In diesem Dokument wird beschrieben, wie du mit dem HLS-Protokoll (HTTP Live Streaming) Livedaten von einem Encoder auf YouTube streamst. Dieses Dokument richtet sich an Encoder-Anbieter, die ihren Produkten die Unterstützung der HLS-Aufnahme hinzufügen möchten. Die HLS-Aufnahme ist eine gute Wahl für Premiuminhalte, die eine hohe Qualität und Auflösung bei einer relativ höheren Latenz erfordern. Einen kurzen Vergleich der verschiedenen Datenaufnahmeprotokolle, die von YouTube Live unterstützt werden, findest du unter Vergleich der Datenaufnahmeprotokolle für YouTube Live-Streaming.

Wenn du Livedaten mit HLS streamen möchtest, sollte der Encoder eine Reihe von Mediaplaylists und Mediasegmenten mit HTTP PUT- oder POST-Anfragen an den HLS-Endpunkt von YouTube senden. Aus Sicht des Encoders erscheint der YouTube-HLS-Endpunkt als passiver HTTP-Server.

Jedes Mediensegment stellt die tatsächlichen Multimediainhalte für einen kurzen Teil des Streams dar, der zwischen einer und vier Sekunden dauert. In jeder Medienplaylist wird beschrieben, wie die Mediensegmente in der richtigen Streamreihenfolge wieder zusammengesetzt werden.

Anforderungen an Medienformate

Für die HLS-Aufnahme von YouTube 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.
  • Es werden Frameraten von bis zu 60 fps unterstützt.
  • Nur geschlossene GoP werden unterstützt.
  • Der unterstützte Audio-Codec ist AAC und es wird nur Audio mit einer einzelnen Spur unterstützt.

Weitere Informationen finden Sie im Abschnitt Mediensegmente.

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 Leuchtkraft. Das betrifft insbesondere Folgendes:
    • Das Chroma-Format muss YUV 4:2:0 10‑Bit sein.
    • Die Transferfunktion muss PQ (auch SMPTE ST 2084 genannt) oder HLG (auch ARIB STD-B67 genannt) sein.
    • Der Farbraum muss Rec. 2020 sein.
    • Die Matrix-Koeffizienten müssen „Rec. 2020, nicht konstante Leuchtdichte“ sein.
  • Sowohl Samplewerte mit begrenztem Bereich (MPEG-Bereich) als auch mit vollem Bereich (JPEG-Bereich) werden unterstützt. Der Bereich muss dem Bereich der Stichprobenwerte entsprechen, der in den Inhalten verwendet wird. Es wird empfohlen, Stichprobenwerte mit begrenztem Bereich zu verwenden.

HLS-Aufnahme-URL abrufen

HLS-Aufnahme-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 einzufügen, die die folgenden Eigenschaften hat:

"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 sekundäre Datenaufnahme-URL an. Weitere Informationen finden Sie in der Dokumentation zur liveStreams-Ressource.

HLS-Aufnahme-URL in YouTube Studio abrufen

In der Weboberfläche von YouTube Creator Studio wird dem Creator nach dem Klicken auf „Stream erstellen“ ein „Streamschlüssel“ angezeigt, der aus alphanumerischen Zeichen und Bindestriche besteht. Dieser geheime Schlüssel identifiziert sowohl den Creator als auch den Stream auf YouTube.

So erstellst du eine HLS-URL aus diesem Streamschlüssel:

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 Sicherungs-URL übertragen:

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

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

HLS-Aufnahme-URL fertigstellen

URLs, die mit einer der beiden Methoden abgerufen werden, sind unvollständige Vorlagen. Sie enden jeweils mit einem leeren file=-Abfrageparameter. Um die finale URL zu bilden, muss der Encoder den Dateinamen einer Medienplaylist oder eines Mediensegments an das Ende der URL anhängen, um den Parameter file= zu vervollständigen.

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

  • Der Encoder kann einen Dateinamen für eine Medienplaylist oder ein Mediensegment aus alphanumerischen Zeichen, Unterstrichen, Schrägstriche, Bindestriche 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 einem Dateinamen für ein Mediensegment enthält, muss er auf denselben Pfad im entsprechenden Playlist-Eintrag verweisen.

Anforderungen an das HLS-Protokoll

Die vom Encoder gesendeten Medienplaylists und ‑segmente müssen der HTTP Live Streaming 2nd Edition-Spezifikation entsprechen.

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

Der Encoder muss:

  • Sende genau einen codierten Stream mit der höchsten Auflösung, die du Nutzern zur Verfügung stellen möchtest (einfache Auflösung und Codec).
  • Audio- und Videostreams zusammenführen.
  • Verwenden Sie HTTPS und eine persistente Verbindung für alle Anfragen.

In den folgenden Abschnitten findest du genauere Anforderungen für Medienplaylists und Mediensegmente.

Medienplaylists

Eine Medienplaylist enthält eine Liste von Mediensegmenten, die zu einem kontinuierlichen, decodierbaren Multimedia-Stream zusammengefügt werden können. Die Medienplaylist teilt dem Server mit, welche Mediensegmente zu erwarten sind und wie sie im neu zusammengesetzten Stream richtig angeordnet werden sollen.

Voraussetzungen

  • Der Dateiname der Medienplaylist muss auf .m3u8 oder .m3u enden.

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

  • Das EXT-X-MEDIA-SEQUENCE-Tag muss die Sequenznummer des ersten Mediasegments in der Playlist angeben.

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

    Füge jeder Medienplaylist neben den ausstehenden Segmenten auch einige bestätigte Segmente hinzu. So ist es weniger wahrscheinlich, dass ein Segment übersprungen wird, wenn eine Medienplaylist auf Serverseite verloren geht. So können Sie beispielsweise bis zu zwei bestätigte und bis zu fünf ausstehende Segmente in jede Medienplaylist aufnehmen.

    Der Server bestätigt den Erhalt eines Mediensegments, indem er beim Upload dieses Segments eine Antwort vom Typ 200 (OK) oder 202 (Accepted) zurückgibt. Eine 202-Antwort gibt an, dass der Server das Segment vor einer Playlist erhalten hat, in der dieses Segment angegeben ist.

  • Sende für jedes Mediasegment eine aktualisierte Mediaplaylist, damit der Server schnell wiederhergestellt werden kann, falls eine Mediaplaylist verloren geht.

  • Sobald der Server den Erhalt von Mediasegmenten bestätigt, kannst du den Wert des EXT-X-MEDIA-SEQUENCE-Tags erhöhen, um zu verhindern, dass die Mediaplaylist zu lang wird. Wenn der Server beispielsweise den Erhalt der ersten neun Mediensegmente bereits bestätigt hat, enthält die nächste Medienplaylist möglicherweise die achten, neunten und zehnten Mediensegmente.

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

Beispiele

Die folgende Liste enthält 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 Medienplaylist, die mitten in einem Livestream gesendet wird. Da das Beispiel aus der Mitte eines Streams stammt, hat das EXT-X-MEDIA-SEQUENCE-Tag 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

Mediensegmente

In der folgenden Liste sind die Anforderungen für Mediensegmente aufgeführt:

  • Dateinamen
    • Die Dateinamen der Mediensegmente in der URL müssen die Dateiendung .ts haben und mit den Dateinamen in der Playlist übereinstimmen.
    • Dateinamen von Mediensegmenten müssen bei Neustarts des Encoders und des Streams eindeutig sein.
  • Format
    • Mediensegmente müssen im M2TS-Format vorliegen und sollten sich selbst initialisieren.
    • 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 Anforderungen für HDR).
    • Es werden Frameraten von bis zu 60 fps unterstützt.
    • Nur geschlossene GoP werden unterstützt.
    • Der unterstützte Audio-Codec ist AAC. Es wird nur Audio mit einer einzelnen Spur unterstützt.
    • Die Dauer von Mediensegmenten sollte zwischen einer und vier Sekunden liegen, wie im folgenden Abschnitt erläutert. Mediensegmente dürfen nicht länger als 5 Sekunden sein.
    • Mediensegmente dürfen nur in der TLS/SSL-Schicht mit HTTPS verschlüsselt werden. Andere Verschlüsselungsmechanismen werden nicht unterstützt.

Dauer des Mediensegments

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

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

Bitraten

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

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

Andere Anforderungen

  • Encoder müssen den User-Agent-Header 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>

Untertitel

Die HLS-Aufnahme unterstützt zwei Optionen für das Senden von Untertiteln:

  • Sende Untertitel mit separaten HTTP-POST-Anfragen. Das funktioniert für alle HLS-Aufnahmevorgänge.
  • Eingebettete 608/708-Untertitel funktionieren bei HLS-Datenaufnahmen, bei denen der H264-Video-Codec verwendet wird, aber nicht bei Aufnahmen, bei denen der HEVC-Video-Codec verwendet wird. Weitere Informationen findest du in der YouTube-Hilfe unter Anforderungen an automatische Untertitel.

HTTP-Antwortcodes

In den folgenden Abschnitten werden die Antwortcodes beschrieben, die YouTube als Antwort auf Media-Segmente und Media-Playlists zurückgibt, die mit HLS bereitgestellt werden.

200 (OK)

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

Eine HTTP 200-Antwort (OK) auf eine DELETE-Anfrage gibt an, dass der YouTube-Server die Anfrage erhalten und ignoriert hat. Der YouTube-Server erfordert vom Client keine DELETE-Anfrage für eine Ressource im Stream und ignoriert DELETE-Anfragen. Aus Leistungsgründen empfiehlt YouTube, dass Clients keine DELETE-Anfragen senden.

202 (Akzeptiert)

Eine HTTP-Antwort 202 (Accepted) gibt an, dass der YouTube-Server das Mediensegment empfangen hat, bevor er eine Medienplaylist mit diesem Mediensegment erhalten hat. Dies weist den Client an, die Medienplaylist mit diesem Mediensegment so schnell wie möglich zu senden, um eine Verzögerung bei der Verarbeitung dieses Segments zu vermeiden. Das ist jedoch kein Problem, wenn der Encoder für jedes Mediensegment eine aktualisierte Medienplaylist sendet.

400 (Bad Request)

Eine HTTP-Antwort 400 (Bad Request) weist auf eines der folgenden Probleme hin:

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

Eine HTTP-Antwort 401 (Unauthorized, Unzulässig) bedeutet, dass der cid-Parameter in der Basis-URL für den YouTube-HLS-Endpunkt beschädigt oder abgelaufen ist. Der Kunde muss den Parameter cid aktualisieren, um fortzufahren.

405 (Methode nicht zulässig)

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

500 (Interner Serverfehler)

Eine HTTP-Antwort 500 (Interner Serverfehler) gibt an, dass der Server die Anfrage nicht verarbeiten konnte. Bei diesem Fehler empfehlen wir, die Anfrage mit exponentiellem Backoff noch einmal zu versuchen.