YouTube-Liveinhalte über HLS bereitstellen

In diesem Dokument wird beschrieben, wie du das HLS-Protokoll (HTTP Live Streaming) verwendest, 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-Aufnahme hinzufügen möchten. Die HLS-Aufnahme ist eine gute Wahl für Premium-Inhalte, die eine hohe Qualität und Auflösung bei einer relativ hohen Latenz erfordern. Einen kurzen Vergleich der verschiedenen Aufnahmeprotokolle, die YouTube-Livestreaming unterstützt, findest du unter Vergleich der Aufnahmeprotokolle für YouTube-Livestreaming.

Wenn du Live-Daten per HLS streamen möchtest, muss der Encoder eine Reihe von Mediaplaylists und ‑segmenten über HTTP PUT- oder POST-Anfragen an den HLS-Endpunkt von YouTube senden. Aus Sicht des Encoders ist der YouTube-HLS-Endpunkt ein passiver HTTP-Server.

Jedes Media-Segment steht für den tatsächlichen Multimedia-Content eines kurzen Teils des Streams mit einer Dauer von ein bis vier Sekunden. Jede Media Playlist beschreibt, wie die Media Segments in der richtigen Streamreihenfolge wieder zusammengesetzt werden.

Anforderungen an Medienformate

Für die YouTube-HLS-Aufnahme gelten die folgenden Anforderungen für Video- und Audioinhalte:

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

Weitere Informationen finden Sie im Abschnitt Media-Segmente.

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 Luminanz. Noch spezifischer:
    • 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 entsprechen.
    • Die Matrix-Koeffizienten müssen „Rec. 2020, nicht konstante Leuchtdichte“ sein.
  • Es werden sowohl eingeschränkte (oder MPEG-Bereich) als auch vollständige (oder JPEG-Bereich) Beispielwerte unterstützt. Der Bereich muss entsprechend dem Bereich der Beispielwerte festgelegt werden, die im Inhalt verwendet werden. 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 Aufnahme-URL zu erhalten, 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 Ingestion-URL und das Feld cdn.ingestionInfo.backupIngestionAddress die Backup-Ingestion-URL an. Weitere Informationen finden Sie in der Dokumentation zur liveStreams-Ressource.

HLS-Aufnahme-URL aus YouTube Studio abrufen

Wenn der Creator in der YouTube Creator Studio-Weboberfläche auf „Stream erstellen“ klickt, wird ein „Streamschlüssel“ angezeigt, der aus alphanumerischen Zeichen und Bindestrichen besteht. Mit diesem geheimen Schlüssel werden sowohl der Creator als auch der Stream auf YouTube identifiziert.

So können Sie eine HLS-URL aus diesem Stream-Schlüssel erstellen:

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

… wobei $STREAM_KEY der im Webinterface angezeigte Streamschlüssel ist. Beispiel: https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst&copy=0&file=

Zur Erhöhung der Zuverlässigkeit können Sie eine redundante zweite Kopie der Aufnahme an diese Backup-URL senden:

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

Das Backup unterscheidet sich in zwei Punkten von der primären URL: Sowohl der Hostname als auch der Parameter copy= haben sich geändert. Beim Backup-Ingest muss ein anderer copy=-Parameterwert als beim primären Ingest gesendet werden, um den Stream nicht zu beschädigen.

HLS-Aufnahme-URL vervollständigen

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

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

  • Der Encoder kann einen Media-Playlist- oder Media-Segment-Dateinamen 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 nie erforderlich. Wenn der Encoder eine Pfadkomponente in einem Dateinamen für ein Media-Segment enthält, muss im entsprechenden Playlist-Eintrag auf denselben Pfad verwiesen werden.

HLS-Protokollanforderungen

Die vom Encoder gesendeten Media-Playlists und Media-Segmente müssen der HTTP Live Streaming-Spezifikation, 2. Ausgabe entsprechen.

In der HLS-Spezifikation werden zwei Arten von Playlists definiert: Media Playlist und Master Playlist. 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 Media-Playlists für die HLS-Aufnahme. Master-Playlists werden ignoriert. Eine Master-Playlist enthält eine Reihe von Variant Streams, die jeweils eine andere Version desselben Inhalts beschreiben.

Der Encoder muss folgende Voraussetzungen erfüllen:

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

In den folgenden Abschnitten finden Sie genauere Anforderungen für Media-Wiedergabelisten und Media-Segmente.

Medien-Playlists

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

Voraussetzungen

  • Der Dateiname der Media-Playlist muss mit .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 steigen.

  • Mit dem EXT-X-MEDIA-SEQUENCE-Tag muss die Sequenznummer des ersten in der Playlist aufgeführten Mediasegments angegeben werden.

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

    Füge jeder Media-Playlist nicht nur die ausstehenden Segmente, sondern auch einige bestätigte Segmente hinzu. So ist es weniger wahrscheinlich, dass ein Segment übersprungen wird, wenn eine Media-Playlist auf dem Server verloren geht. Sie können beispielsweise bis zu zwei bestätigte und bis zu fünf ausstehende Segmente in jede Media-Playlist aufnehmen.

    Der Server bestätigt den Empfang eines Media-Segments durch die Rückgabe einer 200- (OK) oder 202-Antwort (Accepted) beim Upload dieses Segments. Eine 202-Antwort gibt an, dass der Server das Segment vor einer Playlist empfangen hat, in der das Segment identifiziert wird.

  • Senden Sie für jedes Mediasegment eine aktualisierte Media-Playlist, damit der Server schnell wiederhergestellt werden kann, wenn eine Media-Playlist verloren geht.

  • Wenn der Server den Empfang von Mediasegmenten bestätigt, können Sie den Wert des Tags EXT-X-MEDIA-SEQUENCE erhöhen, um zu verhindern, dass die Mediaplaylist zu lang wird. Wenn der Server beispielsweise den Empfang der ersten neun Media-Segmente bereits bestätigt hat, werden in der nächsten Media-Playlist möglicherweise das achte, neunte und zehnte Media-Segment aufgeführt.

  • 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 das Beispiel aus der Mitte eines Streams stammt, 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-Segmente

In der folgenden Liste sind die Anforderungen für Media-Segmente aufgeführt:

  • Dateinamen
    • Die Dateinamen von Media-Segmenten in der URL müssen die Dateiendung .ts haben und mit den Dateinamen in der Playlist übereinstimmen.
    • Dateinamen von Media-Segmenten müssen bei Encoder-Neustarts und Stream-Neustarts eindeutig sein.
  • Format
    • Media-Segmente müssen im M2TS-Format vorliegen und sollten 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).
    • Es werden Framerates von bis zu 60 fps unterstützt.
    • Nur geschlossene GOP wird unterstützt.
    • Der unterstützte Audio-Codec ist AAC und es wird nur Audio mit einem Track unterstützt.
    • Wie im folgenden Abschnitt beschrieben, sollten Media-Segmente eine Dauer zwischen einer und vier Sekunden haben. Media-Segmente dürfen nicht länger als 5 Sekunden sein.
    • Media-Segmente dürfen nur in der TLS/SSL-Schicht mit HTTPS verschlüsselt werden. Andere Verschlüsselungsmechanismen werden nicht unterstützt.

Dauer des Media-Segments

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

Wir empfehlen eine Dauer von ein bis vier Sekunden für Media-Segmente, da kleinere Media-Segmente 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-Segmente nicht länger als 5 Sekunden sein.

Bitraten

In der YouTube-Hilfe findest du Richtlinien für Bitrateneinstellungen.

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

Andere Anforderungen

  • Encoder sollten 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

Für die HLS-Aufnahme gibt es zwei Optionen zum Senden von Untertiteln:

  • Senden Sie Untertitel mit separaten HTTP-POST-Anfragen. Das funktioniert für alle HLS-Aufnahmen.
  • Eingebettete 608/708-Untertitel funktionieren bei HLS-Aufnahmen, die den H264-Video-Codec verwenden, aber nicht bei Aufnahmen, die den HEVC-Video-Codec verwenden. Weitere Informationen findest du in der YouTube-Hilfe unter Anforderungen an automatische Untertitel.

HTTP-Antwortcodes

In den folgenden Abschnitten werden die Antwortcodes erläutert, die YouTube als Reaktion auf mit HLS bereitgestellte Media-Segmente und Media-Playlists zurückgibt.

200 (OK)

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

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

202 (Akzeptiert)

Eine HTTP 202-Antwort (Accepted) gibt an, dass der YouTube-Server das Media-Segment vor dem Empfang einer Media-Playlist mit diesem Media-Segment empfangen hat. Dies weist den Client darauf hin, dass er die Media-Playlist mit diesem Media-Segment so schnell wie möglich senden sollte, um eine Verzögerung bei der Verarbeitung dieses Segments zu vermeiden. Das ist kein Problem, wenn der Encoder für jedes Media-Segment eine aktualisierte Media-Playlist sendet.

400 (Bad Request)

Eine HTTP 400-Antwort (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)

Die Antwort „HTTP 401 (Unauthorized)“ weist darauf hin, dass der Parameter „cid“ in der Basis-URL für den YouTube-HLS-Endpunkt beschädigt oder abgelaufen ist. Der Client muss den Parameter cid aktualisieren, um fortzufahren.

405 (Method Not Allowed)

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

500 (Interner Serverfehler)

Eine HTTP-Antwort mit dem Code 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.