YouTube-Liveinhalte über HLS bereitstellen

In diesem Dokument wird erläutert, wie Sie mit dem HLS-Protokoll (HTTP Live Streaming) Livedaten auf YouTube über einen Encoder streamen. Dieses Dokument richtet sich an Personen, Encoder-Anbieter, die Unterstützung für die HLS-Datenaufnahme in ihre Produkte aufnehmen möchten HLS ist eine gute Wahl für Premiuminhalte, die einen hohen und eine hohe Auflösung bei relativ höherer Latenz. Kurze Beschreibung Vergleich der verschiedenen Datenaufnahmeprotokolle, die in YouTube Live Informationen zu Streaming-Unterstützung finden Sie unter Vergleich des YouTube-Live-Streaming-Aufnahmeprotokolls.

Um Livedaten mit HLS zu streamen, sollte der Encoder eine Reihe von Playlists und Mediensegmente mit HTTP PUT zum HLS-Endpunkt von YouTube hinzufügen oder Anfragen vom Typ „POST“. Aus der Sicht des Encoders wird der HLS-Endpunkt von YouTube ein passiver HTTP-Server zu sein.

Jedes Mediensegment repräsentiert in einem kurzen Teil den tatsächlichen Multimedia-Inhalt. des Streams zwischen einer und vier Sekunden. Jede Medienplaylist wird beschrieben, wie Sie die Mediasegmente in der richtigen Streamreihenfolge zusammenstellen.

Anforderungen an Medienformate

Bei der HLS-Aufnahme in YouTube gelten die folgenden Anforderungen für Video- und Audioinhalte Inhalt:

  • Video und Audio müssen im M2TS-Format gemuxt sein.
  • Unterstützte Video-Codecs sind H.264 und HEVC.
  • Framerates von bis zu 60 fps werden unterstützt.
  • Nur geschlossene GoP wird unterstützt.
  • Als Audio-Codec wird AAC unterstützt und nur Single-Track-Audioinhalte werden unterstützt.

Weitere Informationen zum Abschnitt "Mediensegmente"

HDR

HDR-Videos (High Dynamic Range) werden mit dem HEVC-Codec unterstützt und haben folgende zusätzliche 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 Übertragungsfunktion muss PQ (auch als SMPTE ST 2084 bezeichnet) oder HLG sein (auch bekannt als ARIB STD-B67).
    • Grundfarben müssen Rec. 2020
    • Matrix-Koeffizienten müssen Rec.- 2020 nicht konstante Leuchtdichte.
  • Sowohl Sample mit begrenztem (oder MPEG-Bereich) als auch des Full-Range- bzw. JPEG-Bereichs werden unterstützt. Es ist wichtig, dass der Bereich entsprechend dem Beispielwertbereich, den der Inhalt verwendet. Beispielwerte mit begrenztem Bereich sind wird empfohlen.

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-Livestreaming-Funktion API zum Einfügen eines Livestreams Ressource mit dem folgenden Eigenschaften:

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

In der API-Antwort gibt das Feld cdn.ingestionInfo.ingestionAddress Folgendes an: die primäre Aufnahme-URL und das Feld cdn.ingestionInfo.backupIngestionAddress gibt die URL für die Sicherungsaufnahme an. Weitere Informationen finden Sie in der Dokumentation zu Die Ressource liveStreams.

HLS-Aufnahme-URL aus YouTube Creator Studio abrufen

In der Weboberfläche von YouTube Creator Studio, nachdem der Creator auf „Erstellen“ geklickt hat Stream“ angezeigt wird, zeigt YouTube einen bestehend aus alphanumerischen und Bindestriche enthalten. Dieser geheime Schlüssel identifiziert sowohl den Ersteller als auch den auf YouTube streamen.

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

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

Dabei ist $STREAM_KEY der Streamschlüssel, der auf 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 mehr Zuverlässigkeit können Sie eine redundante zweite Kopie der Datenaufnahme in diese Back-up-URL ein:

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

Die Sicherung unterscheidet sich in zweierlei Hinsicht von der primären URL: und der copy=-Parameter haben sich geändert. Die Back-up-Datenaufnahme muss einen anderen Wert für copy= als bei der primären Aufnahme, um den Stream beschädigen.

HLS-Aufnahme-URL vervollständigen

URLs, die mit einer der beiden Methoden abgerufen wurden, sind unvollständige Vorlagen. jedes Ende mit einem leeren file=-Abfrageparameter. Um die finale URL zu erstellen, muss der Encoder den Dateinamen einer Medienplaylist oder eines Mediensegments an das Ende der URL anhängen, sodass der Parameter file= ausgefüllt wird.

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

  • Der Encoder kann eine Medienplaylist oder einen Mediensegment-Dateinamen aus alphanumerische Zeichen, Unterstriche, Schrägstriche, Bindestriche und Punkte; werden keine anderen Zeichen unterstützt.
  • Der Encoder darf den Dateinamen nicht URL-codieren.
  • Der Encoder kann relative oder absolute Pfadkomponenten in Dateinamen, Dies ist jedoch nie erforderlich. Encoder mit Pfadkomponente innerhalb eines Mediensegmentnamens muss dieser auf denselben Pfad im zum entsprechenden Playlist-Eintrag.

HLS-Protokollanforderungen

Die vom Encoder gesendeten Medien-Playlists und Mediensegmente müssen den HTTP Live Streaming 2nd Edition Spezifikation.

Die HLS-Spezifikation definiert zwei Arten von Playlists: Medienplaylist und Masterplaylist. Playlist. Da YouTube gestreamte Inhalte in verschiedene Auflösungen und muss der Encoder keine Inhalte mit unterschiedlichen Bitraten an die YouTube Aus diesem Grund unterstützt YouTube nur Medien-Playlists für die HLS-Aufnahme, und Master-Playlists ignoriert. Eine Masterplaylist bietet eine Reihe von Varianten, Streams, die jeweils eine andere Version desselben Inhalts beschreiben)

Für den Encoder muss Folgendes gelten:

  • genau einen codierten Stream mit der höchsten Auflösung senden, für Nutzer ausgeliefert werden (mit derselben Auflösung und einem einzigen Codec).
  • Mux-Audio und -Video.
  • HTTPS und eine dauerhafte Verbindung für alle Anfragen verwenden.

In den folgenden Abschnitten finden Sie spezifischere Anforderungen für Medien-Playlists und Mediensegmente.

Medienplaylists

Eine Medienplaylist enthält eine Liste von Mediensegmenten, die mit stellen einen kontinuierlichen, entschlüsselbaren Multimedia-Stream dar. Die Medienplaylist zeigt, welche Mediensegmente zu erwarten sind und wie sie im wieder zusammengebauten Stream.

Voraussetzungen

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

  • Die erste für einen Stream gesendete Medienplaylist muss mit der Sequenznummer beginnen. 0 und die Sequenznummer müssen monoton zunehmen.

  • Das EXT-X-MEDIA-SEQUENCE-Tag muss die Sequenznummer des in der Playlist zuerst aufgeführt.

  • Eine Medienplaylist darf nicht mehr als fünf ausstehende Segmente enthalten. A Das Segment steht aus, wenn es vom Server nicht empfangen oder bestätigt wurde. erhalten.

    Fügen Sie neben den ausstehenden Segmenten auch einige anerkannte in den einzelnen Medienplaylists. Dadurch sinkt die Wahrscheinlichkeit, Segment, das übersprungen wird, wenn eine Medienplaylist auf Serverseite verloren geht. Für Sie können beispielsweise bis zu zwei bestätigte Segmente und bis zu fünf für jede Medienplaylist ausgefallene Segmente.

    Beachten Sie, dass der Server den Empfang eines Mediensegments bestätigt, indem er eine 200 (OK) oder 202 (Accepted) Antwort auf den Upload dieses Segments. A Die 202-Antwort gibt an, dass der Server das Segment vor einem Playlist identifiziert, die dieses Segment identifiziert.

  • Senden Sie für jedes Mediensegment eine aktualisierte Medienplaylist, kann bei Verlust einer Medienplaylist schnell wiederhergestellt werden.

  • Wenn der Server den Empfang von Mediensegmenten bestätigt, können Sie den Wert für EXT-X-MEDIA-SEQUENCE, um zu verhindern, dass aus der Medienplaylist zu lang. Wenn der Server beispielsweise den Empfang der E-Mail-Adresse neun Mediensegmente enthält, könnte die nächste Medienplaylist das achte, des neunten und zehnten Mediensegments.

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

Beispiele

Die folgende Liste zeigt ein Beispiel für die Dateien, die der Encoder voraussichtlich verarbeiten soll. Senden:

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 Live-Video gesendet wird. . Da das Beispiel aus der Mitte eines Streams stammt, Das EXT-X-MEDIA-SEQUENCE-Tag hat 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
    • Namen von Mediensegmenten in der URL müssen den Dateinamen .ts haben Dateiendung und muss mit den Dateinamen in der Playlist übereinstimmen.
    • Namen von Mediensegmenten müssen bei Encoder-Neustarts und wird der Stream neu gestartet.
  • Format
    • Mediensegmente müssen im M2TS-Format vorliegen und sollten selbstinitialisiert werden.
    • Jedes M2TS-Segment muss ein einzelnes MPEG-2-Programm enthalten.
    • Das M2TS-Segment muss ein PAT und ein PMT enthalten. Die ersten beiden Transportstream-Pakete in einem Segment sollten ein PAT und ein PMT sein.
  • Inhalt
    • Video und Audio müssen gemuxt sein.
    • Unterstützte Video-Codecs sind H.264 und HEVC.
    • HDR mit HEVC wird unterstützt (siehe HDR-Anforderungen).
    • Framerates von bis zu 60 fps werden unterstützt.
    • Nur geschlossene GoP wird unterstützt.
    • Der unterstützte Audio-Codec ist AAC und nur Single-Track-Audio ist unterstützt.
    • Für Mediensegmente wird eine Dauer zwischen eins und vier empfohlen wie im folgenden Abschnitt erläutert. Mediensegmente dürfen nicht eine Dauer von mehr als 5 Sekunden haben.
    • Mediensegmente dürfen nur auf der TLS/SSL-Ebene 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, für die eine hohe Qualität und hoher Auflösung. Die HLS-Aufnahme hat in der Regel eine höhere Latenz als die RTMP- und WebRTC-basierte Aufnahmen, da die HLS-Aufnahme segmentbasiert ist.

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

Bitraten

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

Beachten Sie, dass HEVC im Allgemeinen 25% bis 50% mehr Datenkomprimierung bei gleichbleibender im Vergleich zu H.264. Daher werden Bitratenwerte am unteren Ende des mit HEVC können vorgeschlagene Bereiche verwendet werden, um Bandbreite zu sparen, nützlich für 4K-Inhalte.

Andere Anforderungen

  • Encoder sollten den User-Agent-Header in der HTTP-Anfrage mithilfe der Syntax, die den Namen des Herstellers, den Modellnamen und Version:

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

Untertitel

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

  • Senden Sie Untertitel mithilfe separater HTTP-POST-Anfragen. Das funktioniert für alle HLS-Aufnahmen
  • Eingebettete 608/708-Untertitel funktionieren mit HLS-Aufnahmen, die das H264-Format verwenden. Video-Codec, aber nicht mit Datenaufnahmen, die den HEVC-Video-Codec verwenden. Weitere Informationen Weitere Informationen finden Sie in den Anforderungen für automatische Untertitel. in der YouTube-Hilfe.

HTTP-Antwortcodes

In den folgenden Abschnitten werden die Antwortcodes erläutert, die YouTube in Antwort auf Mediensegmente und Medienplaylists, die mithilfe von HLS bereitgestellt wurden.

200 (OK)

Als Antwort auf eine PUT- oder POST-Anfrage gibt eine HTTP 200-Antwort (OK) Folgendes an: Der YouTube-Server hat einen erwarteten Vorgang erhalten und verarbeitet. erfolgreich war.

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 bietet nicht verlangen, dass der Client eine Ressource im Stream LÖSCHEN muss, und ignoriert DELETE-Anfragen. YouTube empfiehlt Kunden aus Leistungsgründen, Senden Sie keine DELETE-Anfragen.

202 (Akzeptiert)

Die Antwort „HTTP 202 (Accepted)“ gibt an, dass der YouTube-Server Mediensegment bevor du eine Medienplaylist erhältst, die dieses Mediensegment enthält. Damit wird dem Kunden mitgeteilt, dass er die Medien-Playlist mit um eine Verzögerung bei der Verarbeitung zu vermeiden, Segment. Das ist kein Problem, wenn der Encoder eine aktualisierte Medienplaylist für jedes Mediensegment

400 (Bad Request)

Der HTTP-Statuscode 400 (Ungültige Anfrage) weist auf eines der folgenden Probleme hin: aufgetreten:

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

Der HTTP-Statuscode 401 (Nicht autorisiert) gibt an, dass der cid-Parameter in der Die Basis-URL für den YouTube-HLS-Endpunkt ist beschädigt oder abgelaufen. Der Kunde den cid-Parameter aktualisieren, um fortzufahren.

405 (Methode nicht zulässig)

Der HTTP-Statuscode 405 (Methode nicht zulässig) gibt an, dass die Anfrage keine POST-, PUT- oder DELETE-Anfrage.

500 (Interner Serverfehler)

Die Antwort HTTP 500 (Interner Serverfehler) zeigt an, dass der Server kann die Anfrage nicht verarbeiten. Für diesen Fehler empfehlen wir, den mit exponentieller Backoff.