YouTube-Liveinhalte über DASH bereitstellen

In diesem Dokument finden Sie Richtlinien für die Verwendung des DASH-Übertragungsformats (Dynamic Adaptive Streaming over HTTP) zum Streamen von Live-Daten auf YouTube über einen Encoder. Es soll Encoder-Anbietern helfen, ihren Produkten Unterstützung für die DASH-Bereitstellung hinzuzufügen.

DASH

In der folgenden Liste sind einige wichtige DASH-Funktionen und ‑Attribute aufgeführt:

• Basierend auf offenen Standards.
• HTTP-basiert. DASH ist daher internetinfrastrukturfreundlich und kann Firewalls durchlaufen.
• Unterstützt hohe Übertragungsbitraten. DASH unterstützt mehrere gleichzeitige HTTP-Sitzungen und die nicht sequenzielle Segmentübertragung. Dadurch ist das Protokoll robuster als Protokolle, die auf einer einzelnen TCP-Verbindung basieren.
• Sichere Auslieferung über HTTPS
• Verlustfreie Bereitstellung über HTTP und HTTPS.
• Codec-unabhängig.
• Unterstützt MP4 mit H264 und AAC sowie WebM mit VP8/VP9 und Vorbis/Opus.

Spezifikationen

• DASH wird in ISO/IEC 23009-1:2014 Information technology -- Dynamic adaptive streaming over HTTP (DASH) beschrieben.
• WebM über DASH wird in der WebM DASH-Spezifikation beschrieben.

Voraussetzungen

In den folgenden Unterabschnitten werden die Anforderungen für die Verwendung von DASH zur Bereitstellung von Livestreams auf YouTube erläutert.

Timing

Der YouTube-DASH-Endpunkt verhält sich wie ein passiver HTTP-Server, der PUT-Methodenaufrufe aufzeichnet, die von einem Encoder gesendet werden.

• Der DASH-Endpunkt unterstützt gleichzeitige TCP-Verbindungen. Sie können Verbindungen gemäß HTTP/1.1 wiederverwenden.
• Die MPD- und Initialisierungssegmente sollten innerhalb von 3 Sekunden nach dem ersten Media-Segment per PUT-Methode übertragen werden. Wir empfehlen, das Initialisierungssegment in die MPD aufzunehmen.
• Für jedes Segment oder jede MPD muss eine separate PUT-Anfrage verwendet werden. Der mehrteilige Upload mehrerer Segmente wird nicht unterstützt.
• PUT-Vorgänge für Media-Segmente können sich zeitlich überschneiden, um die Uploadbandbreite zu verbessern.
• Segmente können innerhalb eines Zeitfensters von etwa 3 Sekunden in nicht sequenzieller Reihenfolge bereitgestellt werden.
• Die MPD- und Initialisierungssegmente sollten mindestens alle 60 Sekunden mit einem aktualisierten availabilityStartTime und startNumber aktualisiert werden. Wie oben erwähnt, kann das Initialisierungssegment im MPD enthalten sein. In diesem Fall kann mit einer PUT-Anfrage beide Segmente aktualisiert werden.)

URL-Struktur

Ihr Encoder muss PUT-URLs erstellen, indem er einen String an die YouTube-Endpunkt-Basis-URL anhängt. Du musst den DASH-Aufnahmeendpunkt mit der YouTube Live Streaming API erstellen.

Der Encoder kann die Basis-URL des Endpunkts anschließend programmatisch über die YouTube Live Streaming API abrufen. Die Basis-URL ist auch in der YouTube Live-Events-Benutzeroberfläche sichtbar, wenn Sie die URL manuell im Encoder eingeben möchten.

Der String, der an die Basis-URL angehängt wird, kann die folgenden ASCII-Zeichen enthalten:

• Kleinbuchstaben: a–z
• Großbuchstaben: A–Z
• Ziffern: 0–9
• Sonderzeichen: _ (Unterstrich), - (Bindestrich), . (Punkt)

MPD-URLs

Zusätzlich zu der oben genannten Anforderung muss die MPD-URL mit .mpd enden, damit der YouTube-Server die MPD-Datei leicht identifizieren kann. Andere Segment-URLs dürfen nicht mit .mpd enden.

Initialisierung und Media-Segment-URLs

Die URL des Initialisierungssegments und alle URLs der Media-Segmente müssen mit .mp4 enden, wenn sich die Daten in einem ISO BMFF-Container befinden, oder mit .webm, wenn sich die Daten in einem WebM-Container befinden.

MPD-Inhalte

Die MPD muss vollständig sein und dem DASH-Standard entsprechen. Es muss genau eines der folgenden Elemente enthalten. In dieser Liste werden Elemente aufgeführt, die speziell von YouTube benötigt werden. Im DASH-Standard sind möglicherweise weitere erforderliche Elemente enthalten. Die Elemente werden mit der XPath-Syntax dargestellt und entsprechen dem DASH-Standard.

• /mpd:MPD/attribute::type
• /mpd:MPD/mpd:Period
• /mpd:MPD/mpd:Period/mpd:AdaptationSet
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/attribute::mimeType (video/mp4 or video/webm)
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::media
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::initialization
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::startNumber

Beachten Sie die folgenden Anforderungen an Elementwerte:

• Das Attribut minimumUpdatePeriod des Elements <MPD> muss auf einen Wert gesetzt werden, der kleiner oder gleich 60 Sekunden (PT60S) ist.
• Das Attribut media des Elements <SegmentTemplate> muss angeben, dass Mediensegment-URLs mit $Number$ generiert werden. Das Attribut startNumber gibt die Nummer an, die dem ersten Media-Segment zugewiesen wird.

Länge des Initialisierungssegments

Das Initialisierungssegment darf nicht länger als 100 KB sein. In der Regel ist ein Initialisierungssegment viel kleiner. Wenn das Initialisierungssegment in der MPD enthalten ist, darf die data:-URL, die das Segment enthält, nicht länger als 100 KB sein.

Encoder-Ausgabe

Das Initialisierungssegment und die Media-Segmente müssen einen gemultiplexten ISO BMFF- oder WebM-Dateistream mit geschlossenen GOPs (Bildergruppen) bilden.

• Die GOP-Größe sollte etwa 2 Sekunden betragen und darf nicht mehr als 8 Sekunden betragen.
• Der gemultiplexte Stream muss sowohl Audio- als auch Videotracks enthalten.

Zusätzliche Best Practices

Verschlüsselung

YouTube unterstützt die Streamverschlüsselung über HTTPS. Wir empfehlen dringend, diese Funktion zu verwenden.

Initialisierungssegmente in MPD

Sie können das Initialisierungssegment direkt in der MPD mit einer data:-URL gemäß RFC 2397 darstellen. Das vereinfacht die Einrichtung des Streams und verringert die Wahrscheinlichkeit, dass das Initialisierungssegment nicht mit dem Rest des Streams übereinstimmt.

Der XPath für dieses Element lautet:

/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute:data

Dauer von Zielsegmenten

Für eine gute Aufnahmeleistung und ein gutes Verhältnis zwischen Durchsatz und Latenz sollte die Länge Ihrer Media-Segmente zwischen 1 und 5 Sekunden liegen. Wir empfehlen dringend, die Zieldauer dieser Segmente in der MPD mit den folgenden beiden Elementen anzugeben:

• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::duration
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::timescale

Die aus diesen Attributen berechnete Dauer sollte innerhalb eines Faktors von 2 aller tatsächlichen Segmentdauern liegen, da sonst die Streaming-Leistung beeinträchtigt werden kann.

Die Zieldauer für die Aufnahme entspricht nicht der Chunks-Dauer für den Livestream, der von YouTube erstellt wird. YouTube transcodiert und segmentiert die Eingabe neu. Die Zieldauer der Ausgabe hängt davon ab, ob ein Stream für Streamingqualität oder für Latenz optimiert ist.

Wiederholungsversuche und exponentieller Backoff

Alle HTTP PUT-Anfragen sollten mit einem Zeitlimit ausgeführt werden. Wir empfehlen, dieses Zeitlimit auf einen Wert festzulegen, der 500 Millisekunden über der Segmentdauer liegt.

Eine PUT-Anfrage für ein Media-Segment, die fehlschlägt (unabhängig davon, ob aufgrund einer Zeitüberschreitung oder anderer Fehler), entspricht einer Lücke im Videostream. Daher sollten Sie alle solchen Anfragen mit einem zufälligen binären exponentiellen Backoff wiederholen:

1. Warten Sie nach einem Fehler einen zufälligen Zeitraum zwischen [0 ... 100] Millisekunden und wiederholen Sie die Anfrage.
2. Wenn die Anfrage noch einmal fehlschlägt, warten Sie einen zufälligen Zeitraum zwischen [0 ... 200] Millisekunden und wiederholen Sie den Vorgang.
3. Wenn die Anfrage noch einmal fehlschlägt, warten Sie einen zufälligen Zeitraum zwischen [0 ... 400] Millisekunden und wiederholen Sie den Vorgang.
4. usw.

Wiederholte Fehler sollten dem Encoder-Operator gemeldet werden, da sie auf eine fehlgeschlagene Übertragung hinweisen.

HTTP-Antwortcodes

In den folgenden Abschnitten werden die Antwortcodes erläutert, die YouTube als Reaktion auf über DASH bereitgestellte Segmente zurückgibt.

200 (OK)

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

202 (Akzeptiert)

Eine HTTP-202-Antwort (Accepted) auf einen PUT- oder POST-Vorgang gibt an, dass der Vorgang unerwartet war und für die verzögerte Verarbeitung akzeptiert wurde. Der verzögerte Vorgang kann jedoch erfolgreich sein oder fehlschlagen. Die Antwort garantiert also nicht, dass YouTube den Vorgang tatsächlich erfolgreich verarbeiten kann.

Diese Antwort tritt am häufigsten auf, wenn ein Segment nicht sequenziell bereitgestellt wird. Normalerweise kann YouTube das akzeptierte Segment nach Erhalt der vorherigen Segmente korrekt verarbeiten. Sie müssen das Segment dann nicht noch einmal senden.

YouTube kann beispielsweise in den folgenden Fällen eine 202-Antwort zurückgeben:

• Ein Initialisierungssegment wird vor der MPD empfangen.
• Media-Segmente werden vor dem MPD und den Initialisierungssegmenten empfangen.
• Ein Media-Segment wird vor einem früheren Segment empfangen, z. B. Segment 3 vor Segment 2.

Eine 202-Antwort kann jedoch auch darauf hinweisen, dass die Artikel-ID falsch ist, wenn YouTube die ID nach Erhalt der POST- oder PUT-Anfrage nicht vollständig validieren kann. Das kann beispielsweise passieren, wenn YouTube ein Initialisierungssegment empfängt und akzeptiert, bevor die MPD empfangen wird, sich das Initialisierungssegment jedoch als ungültig erweist. In diesem Fall akzeptiert YouTube das Initialisierungssegment und gibt den Statuscode 202 zurück. Anschließend wird beim Empfang der MPD geprüft, ob das Segment gültig ist. Sie können dieses Szenario vermeiden, indem Sie das Initialisierungssegment in die MPD aufnehmen.

400 (Bad Request)

Eine HTTP 400-Antwort (Fehlerhafte Anfrage) weist auf eines der folgenden Probleme hin:

• Die URL ist fehlerhaft.
• Der Beitrag ist zu groß (> 10 MB).
• Die MPD-Datei kann nicht geparst werden.
• Das Initialisierungssegment im MPD ist beschädigt.

401 (Unauthorized)

Eine HTTP 401-Antwort (Unauthorized) weist darauf hin, dass die Basis-URL für den YouTube-DASH-Endpunkt beschädigt oder abgelaufen ist.

405 (Method Not Allowed)

Eine HTTP 405-Antwort (Method Not Allowed) weist darauf hin, dass eine andere Anfrage als POST oder PUT gesendet wurde.

409 (Konflikt)

Eine HTTP 409-Antwort (Konflikt) auf einen PUT- oder POST-Vorgang gibt an, dass YouTube die Anfrage nicht verarbeiten kann. Diese Antwort kann beispielsweise auftreten, wenn der Anfragende zahlreiche Media-Segmente gesendet hat, YouTube aber immer noch nicht die MPD, das Initialisierungssegment oder beides hat. In diesem Beispiel müsste der Encoder die MPD- und Initialisierungssegmente noch einmal übertragen, bevor er die fehlgeschlagene Anfrage wiederholt.

500 (Interner Serverfehler)

Eine HTTP 500-Antwort (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.

Beispiele

URL-Sequenz

Die folgende URL-Sequenz zeigt eine Reihe von PUT-Anfragen, die zum Bereitstellen von Inhalten über DASH gesendet werden. Bei der Sequenz wird davon ausgegangen, dass die Basis-URL für den YouTube-DASH-Endpunkt folgende ist:

http://upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=

In der Sequenz werden das MPD- und das Initialisierungssegment separat gesendet. Das Initialisierungssegment kann jedoch direkt in der MPD-Datei dargestellt werden. Das wird auch empfohlen. Außerdem sollten das MPD und die Initialisierungssegmente mindestens alle 60 Sekunden aktualisiert werden. Die URLs für diese Segmente würden also irgendwann wieder in dieser Reihenfolge auftreten, gefolgt von URLs für weitere Media-Segmente.

PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=dash.mpd
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media001.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media002.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media003.mp4
...

WebM-Segmente

MPD mit eingebettetem Initialisierungssegment

Die folgende Beispiel-MPD enthält ein eingebettetes Initialisierungssegment in einer RFC 2397-Daten-URL. Wir empfehlen, das Initialisierungssegment auf diese Weise einzubetten, anstatt es separat zu senden.

Dieses Beispiel entspricht den Anforderungen für die Aufnahme von WebM-Dateien (VP8 oder VP9, Opus) auf YouTube. Der Großteil der Daten-URL wurde aus Gründen der Lesbarkeit ausgeblendet:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic" 
     profiles="urn:mpeg:dash:profile:isoff-live:2011" 
     minimumUpdatePeriod="PT60S"
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:52:58" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/webm">
      <ContentComponent contentType="video" id="1"/>
      <SegmentTemplate timescale="1000"
           duration="2000"
           startNumber="1"
           initialization="data:video/mp4;base64,AAAAGGZ0eXBpc...AAA"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media-$Number%09d$.webm"/>
      <Representation id="1" width="1920" height="1080">
        <SubRepresentation contentComponent="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

MPD

Das folgende Beispiel-MPD ohne eingebettetes Initialisierungssegment entspricht ebenfalls den Anforderungen für die Aufnahme von WebM-Dateien (VP8 oder VP9, Opus) auf YouTube:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic" 
     profiles="urn:mpeg:dash:profile:isoff-live:2011" 
     minimumUpdatePeriod="PT60S"
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:52:58" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/webm">
      <ContentComponent contentType="video" id="1"/>
      <SegmentTemplate timescale="1000"
           duration="2000"
           startNumber="1"
           initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.webm"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media-$Number%09d$.webm"/>
      <Representation id="1" width="1920" height="1080">
        <SubRepresentation contentComponent="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

Initialisierung

Das folgende Beispiel zeigt das Layout eines WebM-Initialisierungssegments. Er besteht aus dem Teil des WebM-Streams bis zum ersten Cluster, aber ohne diesen.

Medien

Im Folgenden sehen Sie das Layout eines Beispiel-WebM-Media-Segments. Sie besteht aus einem einzelnen WebM-Cluster. Wie bei einem ISO BMFF-Stream sollte durch das Initialisierungssegment, das einer Reihe von Clustern vorangestellt wird, ein gültiger WebM-Stream erzeugt werden.

ISO BMFF-Segmente

MPD mit eingebettetem Initialisierungssegment

Die folgende Beispiel-MPD enthält ein eingebettetes Initialisierungssegment in einer RFC 2397-Daten-URL. Wir empfehlen, das Initialisierungssegment auf diese Weise einzubetten, anstatt es separat zu senden.

Dieses Beispiel entspricht den Anforderungen für die Aufnahme von ISO BMFF-Dateien (H.264, AAC) auf YouTube. Der Großteil der Daten-URL wurde aus Gründen der Lesbarkeit ausgeblendet:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="urn:mpeg:dash:schema:mpd:2011"   
    xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" 
    type="dynamic"
    minimumUpdatePeriod="PT30S" 
    availabilityStartTime="2016-05-04T20:47:25" 
    minBufferTime="PT12S" 
    profiles="urn:mpeg:dash:profile:isoff-live:2011">
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2">
      <ContentComponent contentType="video" id="1"/>
      <ContentComponent contentType="audio" id="2"/>
      <SegmentTemplate timescale="600"
             media="/dash_upload?cid=ug50-xg26-cbc1-2p0h&staging=1&copy=0&file=media$Number%09d$.mp4"
             initialization="data:video/mp4;base64,AAAAGGZ0eXBpc281AA...AA"
             duration="306"
             startNumber="1"/>
      <Representation id="1" width="640" height="360" bandwidth="526952">
        <SubRepresentation contentComponent="1" bandwidth="526952" 
codecs="avc1.4d401e"/>
        <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

MPD

Das folgende Beispiel für eine MPD ohne eingebettetes Initialisierungssegment entspricht ebenfalls den Anforderungen für die ISO BMFF-Aufnahme (H.264, AAC) auf YouTube:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic"
     profiles="urn:mpeg:dash:profile:isoff-live:2011"
     minimumUpdatePeriod="PT60S" 
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:51:31" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2">
      <ContentComponent contentType="video" id="1"/>
      <ContentComponent contentType="audio" id="2"/>
      <SegmentTemplate timescale="600"
           duration="1200"
           startNumber="1"
           initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.mp4"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media$Number%09d$.mp4"/>
      <Representation id="1" width="640" height="360" bandwidth="526952">
        <SubRepresentation contentComponent="1" bandwidth="526952" codecs="avc1.4d401e"/>
        <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

Initialisierung

Das folgende Diagramm zeigt das Layout eines Beispiel-Initialisierungssegments für multiplexiertes ISO BMFF. YouTube verwendet die Atome nicht unbedingt, aber dies ist ein konformes Beispiel. Insbesondere werden sowohl Audio- als auch Videotracks dargestellt.

Medien

Das folgende Diagramm zeigt das Layout eines Beispiel-Multiplex-ISO BMFF-Media-Segments. YouTube verwendet nicht unbedingt alle Atome, aber dies ist ein konformes Beispiel. Insbesondere werden sowohl Audio- als auch Videotracks dargestellt. Eine Reihe dieser Segmente kann an ein Initialisierungssegment angehängt werden, um einen gültigen und vollständigen gemultiplexten ISO BMFF-Stream zu erstellen.

Bekannte Einschränkungen

RTMP- und DASH-Aufnahmen

Es ist nicht möglich, RTMP- und DASH-Streams auf YouTube zu mischen. Das gilt sowohl für den Wechsel zwischen den beiden während einer Übertragung als auch für die Verwendung einer Methode als primäre Aufnahmemethode und der anderen für die Backup-Aufnahme.