YouTube-Liveinhalte über DASH bereitstellen

Dieses Dokument enthält Richtlinien für die Verwendung des DASH-Übermittlungsformats (Dynamic Adaptive Streaming over HTTP), um Livedaten auf YouTube über einen Encoder zu streamen. Es soll Encoder-Anbietern dabei helfen, ihren Produkten DASH-Auslieferungsunterstützung hinzuzufügen.

Informationen zu DASH

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

• Basierend auf offenen Standards.
• HTTP-basiert. Daher ist DASH für die Internetinfrastruktur geeignet und kann Firewalls passieren.
• Unterstützt hohe Übertragungsbitrate. DASH unterstützt mehrere, gleichzeitige HTTP-Sitzungen und die nicht sequenzielle Segmentzustellung. Dies bietet eine höhere Ausfallsicherheit als Protokolle, die auf einer einzelnen TCP-Verbindung basieren.
• Sichere Zustellung über HTTPS
• Verlustfreie Zustellung ü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 den WebM DASH-Spezifikationen 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 DASH-Endpunkt von YouTube verhält sich wie ein passiver HTTP-Server, der von einem Encoder gesendete Aufrufe der PUT-Methode aufzeichnet.

• Der DASH-Endpunkt unterstützt gleichzeitige TCP-Verbindungen. Sie können Verbindungen gemäß HTTP/1.1 wiederverwenden.
• Die MPD- und Initialisierungssegmente sollten innerhalb von drei Sekunden nach dem ersten Mediensegment PUT ausgeführt werden. Wir empfehlen, das Initialisierungssegment in die MPD-Datei aufzunehmen.
• Für jedes Segment bzw. jede MPD-Datei muss eine separate PUT-Anfrage verwendet werden. Der mehrteilige Upload mehrerer Segmente wird nicht unterstützt.
• PUT-Vorgänge für Mediensegmente können sich mit der Zeit überschneiden, um die Uploadbandbreite zu verbessern.
• Segmente können in nicht sequenzieller Reihenfolge innerhalb eines Zeitfensters von etwa 3 Sekunden 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 in die MPD-Datei aufgenommen werden. In diesem Fall können mit einer PUT-Anfrage beide Segmente aktualisiert werden.)

URL-Struktur

Dein Encoder muss PUT-URLs bilden, indem er einen String an die Basis-URL des YouTube-Endpunkts 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 wird auch auf der YouTube-Benutzeroberfläche für Live-Veranstaltungen angezeigt, wenn du die URL manuell an den Encoder senden möchtest.

Die Zeichenfolge, die 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 den oben genannten Anforderungen muss die MPD-URL auf .mpd enden, damit die MPD-Datei vom YouTube-Server leicht identifiziert werden kann.Andere Segment-URLs dürfen nicht mit .mpd enden.

Initialisierungs- und Mediensegment-URLs

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

MPD-Inhalte

Die MPD-Datei muss vollständig sein und dem DASH-Standard entsprechen. Er muss genau eines der folgenden Elemente enthalten. Diese Liste enthält Elemente, die speziell von YouTube benötigt werden, und der DASH-Standard enthält möglicherweise zusätzliche erforderliche Elemente. Die Elemente werden mithilfe 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 für Elementwerte:

• Das minimumUpdatePeriod-Attribut des <MPD>-Elements muss auf einen Wert von maximal 60 Sekunden (PT60S) festgelegt werden.
• Das media-Attribut des <SegmentTemplate>-Elements muss angeben, dass Mediensegment-URLs mit $Number$ generiert werden. Das Attribut startNumber gibt die Nummer an, die dem ersten Mediensegment zugewiesen wird.

Länge des Initialisierungssegments

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

Encoder-Ausgabe

Das Initialisierungssegment und die Mediensegmente müssen einen Multiplex-ISO-BMFF- oder WebM-Dateistream mit geschlossenen Bildergruppen (GoPs) darstellen.

• Die Bildergruppengröße sollte etwa 2 Sekunden und weniger als 8 Sekunden betragen.
• Der Multiplex-Stream muss sowohl Audio- als auch Videotracks enthalten.

Zusätzliche Best Practices

Verschlüsselung

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

Initialisierungssegmente in MPD

Sie können das Initialisierungssegment direkt in der MPD-Datei 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

Hinweis: Die data:-URL darf nicht länger als 100.000 Byte sein.

Zielsegmentdauer

Um eine gute Aufnahmeleistung und einen guten Kompromiss zwischen Durchsatz und Latenz zu erzielen, sollte die Länge Ihrer Mediensegmente zwischen 1 und 5 Sekunden liegen.Wir empfehlen dringend, die Zieldauer dieser Segmente in der MPD-Datei mithilfe dieser beiden Elemente anzugeben:

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

Die anhand dieser Attribute berechnete Dauer sollte im Faktor 2 aller tatsächlichen Segmentdauern liegen, da sonst die Streamingleistung beeinträchtigt werden kann.

Die Zieldauer für die Aufnahme entspricht nicht der Teildauer des Livestreams, den YouTube generiert. YouTube transcodiert die Eingabe und teilt sie neu auf. Die Zieldauer für die Ausgabe hängt davon ab, ob ein Stream für die Streamingqualität oder für Latenz optimiert ist.

Wiederholungsversuche und exponentieller Backoff

Alle HTTP PUT-Anfragen sollten mit einer Zeitüberschreitung ausgeführt werden. Wir empfehlen, einen Wert festzulegen, der 500 Millisekunden länger als die Segmentdauer ist.

Eine PUT-Anfrage für ein Mediensegment, die aufgrund einer Zeitüberschreitung oder eines anderen Fehlers fehlschlägt, entspricht einer Lücke im Videostream. Daher sollten Sie jede solche Anfrage mit einem zufälligen binären exponentiellen Backoff wiederholen:

1. Warten Sie nach einem Fehler einen beliebigen Zeitraum zwischen [0 ... 100] Millisekunden und wiederholen Sie die Anfrage.
2. Wenn die Anfrage erneut fehlschlägt, warte einen zufälligen Zeitraum zwischen [0 ... 200] Millisekunden und wiederhole die Anfrage.
3. Wenn die Anfrage erneut fehlschlägt, warte einen zufälligen Zeitraum zwischen [0 ... 400] Millisekunden und wiederhole die Anfrage.
4. usw.

Beachte, dass wiederholte Fehler dem Operator des Encoders signalisiert werden müssen, da sie einer fehlerhaften Übertragung entsprechen.

HTTP-Antwortcodes

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

200 (OK)

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

202 (Akzeptiert)

Die Antwort „HTTP 202 (Accepted)“ auf einen PUT- oder POST-Vorgang gibt an, dass der Vorgang unerwartet war und für die verzögerte Verarbeitung akzeptiert wurde. Der zurückgestellte Vorgang kann jedoch erfolgreich sein oder fehlschlagen, sodass die Antwort keine Garantie dafür darstellt, dass YouTube den Vorgang tatsächlich erfolgreich verarbeiten kann.

Diese Antwort erscheint am häufigsten, wenn ein Segment nicht sequenziell ausgeliefert wird. Normalerweise kann YouTube das akzeptierte Segment nach Erhalt der vorhergehenden Segmente korrekt verarbeiten und du musst das Segment nicht noch einmal senden.

So kann YouTube beispielsweise in den folgenden Fällen den Fehler 202 zurückgeben:

• Ein Initialisierungssegment wird vor der MPD-Datei empfangen.
• Mediensegmente werden vor den MPD- und Initialisierungssegmenten empfangen.
• Ein Mediensegment 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. Dies kommt beispielsweise vor, wenn YouTube ein Initialisierungssegment vor dem Empfang der MPD-Datei empfängt und akzeptiert, das Initialisierungssegment jedoch ungültig ist. In diesem Fall akzeptiert YouTube das Initialisierungssegment, gibt den Fehler 202 zurück und prüft dann, ob das Segment nach Erhalt der MPD-Datei gültig ist. Sie können dies vermeiden, indem Sie das Initialisierungssegment in die MPD-Datei aufnehmen.

400 (Bad Request)

Die Antwort HTTP 400 (Ungültige Anfrage) weist auf eines der folgenden Probleme hin:

• Die URL weist ein fehlerhaftes Format auf.
• Der Beitrag ist zu groß (> 10 MB).
• Die MPD-Datei kann nicht geparst werden.
• Das Initialisierungssegment in der MPD-Datei ist beschädigt.

401 (Unauthorized)

Der Fehler „HTTP 401 (Nicht autorisiert)“ gibt an, dass die Basis-URL für den DASH-Endpunkt von YouTube beschädigt oder abgelaufen ist.

405 (Methode nicht zulässig)

Eine HTTP 405-Antwort (Methode nicht zulässig) gibt an, dass eine andere Anfrage als POST oder PUT gesendet wurde.

409 (Konflikt)

Eine HTTP-Antwort 409 (Konflikt) auf einen PUT- oder POST-Vorgang gibt an, dass YouTube die Anfrage nicht verarbeiten kann. Diese Antwort kann beispielsweise auftreten, wenn der Anfragende zwar mehrere Mediensegmente gesendet hat, YouTube aber immer noch weder die MPD-Datei noch das Initialisierungssegment oder beides enthält. In diesem Beispiel muss der Encoder die MPD- und Initialisierungssegmente noch einmal übertragen, bevor die fehlgeschlagene Anfrage wiederholt wird.

Wichtig:Ein Encoder MÜSSEN diesen Antwortcode korrekt verarbeiten, da er jederzeit zurückgegeben werden kann, auch während des normalen Betriebs. Die Anzahl der Wiederholungsversuche ist zwar nicht begrenzt, aber wiederholte Fehler sollten dem Encoder-Betreiber signalisiert werden, dass die Übertragung fehlschlägt.

500 (Interner Serverfehler)

Der HTTP-Statuscode 500 (Interner Serverfehler) gibt an, dass der Server die Anfrage nicht verarbeiten konnte. Für diesen Fehler empfehlen wir, die Anfrage mit dem exponentiellen Backoff noch einmal zu senden.

Beispiele

URL-Sequenz

Die URL-Sequenz unten zeigt eine Reihe von PUT-Anfragen, die gestellt werden, um Inhalte über DASH zu übermitteln. Bei der Abfolge wird davon ausgegangen, dass die Basis-URL für den YouTube-DASH-Endpunkt so lautet:

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

Die Sequenz zeigt die separat gesendeten MPD- und Initialisierungssegmente. Das Initialisierungssegment kann jedoch direkt in der MPD-Datei dargestellt werden. Dies wird empfohlen. Außerdem sollten die MPD- und Initialisierungssegmente mindestens alle 60 Sekunden aktualisiert werden. Auf diese Weise kommt es schließlich zu den URLs für diese Segmente in dieser Reihenfolge, gefolgt von URLs für weitere Mediensegmente.

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

In der folgenden Beispiel-MPD-Datei ist ein Initialisierungssegment in einer RFC 2397-Daten-URL eingebettet. Wir empfehlen, das Initialisierungssegment auf diese Weise einzubetten, anstatt es separat zu senden.

Dieses Beispiel ist konform mit der WebM-Datenaufnahme (VP8 oder VP9, Opus) in YouTube. Der Großteil der Daten-URL wurde aus Gründen der Lesbarkeit weggelassen:

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

Die folgende Beispiel-MPD, die kein eingebettetes Initialisierungssegment hat, ist auch für die WebM-Aufnahme (VP8 oder VP9, Opus) in YouTube konform:

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

Im Folgenden sehen Sie das Layout eines Beispielsegments für die WebM-Initialisierung. Sie besteht aus dem Teil des WebM-Streams bis zum ersten Cluster, jedoch nicht.

Medien

Im Folgenden sehen Sie das Layout eines Beispiel-WebM-Mediensegments. Es besteht aus einem einzelnen WebM-Cluster. Wie bei einem ISO-BMFF-Stream sollte das Initialisierungssegment, das einer Reihe von Clustern vorangestellt ist, einen gültigen WebM-Stream erzeugen.

ISO-BMFF-Segmente

MPD mit eingebettetem Initialisierungssegment

In der folgenden Beispiel-MPD-Datei ist ein Initialisierungssegment in einer RFC 2397-Daten-URL eingebettet. Wir empfehlen, das Initialisierungssegment auf diese Weise einzubetten, anstatt es separat zu senden.

Dieses Beispiel ist konform mit der Aufnahme von ISO BMFF (H.264, AAC) in YouTube. Der Großteil der Daten-URL wurde aus Gründen der Lesbarkeit weggelassen:

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

Die folgende Beispiel-MPD-Datei ohne eingebettetes Initialisierungssegment ist auch konform mit der ISO-BMFF-Aufnahme (H.264, AAC) in 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 Beispielsegments für die Multiplex-Initialisierung eines ISO BMFF-Segments. YouTube verwendet die Atome nicht unbedingt, aber dies ist ein konformes Beispiel. Insbesondere werden sowohl Audio- als auch Videotracks repräsentiert.

Medien

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

Bekannte Einschränkungen

RTMP- und DASH-Aufnahmen

Es ist nicht möglich, RTMP- und DASH-Aufnahmen auf YouTube zu kombinieren.Dies gilt für den Wechsel zwischen den beiden Methoden während einer Übertragung sowie für die Verwendung einer Methode als primäre Aufnahmemethode und der anderen für die Back-up-Datenaufnahme.