Live-YouTube-Inhalte über DASH bereitstellen

Dieses Dokument enthält Richtlinien zur Verwendung des DASH-Bereitstellungsformats zum Streamen von Live-Daten auf YouTube über einen Encoder. Sie soll Encoder-Anbieter dabei unterstützen, die Unterstützung der DASH-Bereitstellung in ihre Produkte aufzunehmen.

DASH

Die folgende Liste enthält wichtige DASH-Features und -Attribute:

• Basierend auf offenen Standards.
• HTTP-basiert. Daher ist DASH für die Internetinfrastruktur geeignet und kann Firewalls umgehen.
• Unterstützt eine hohe Übertragungsbitrate. DASH unterstützt mehrere gleichzeitige HTTP-Sitzungen und die Bereitstellung nicht sequentieller Segmente. Dies sorgt für mehr Ausfallsicherheit als Protokolle, die auf einer einzelnen TCP-Verbindung beruhen.
• 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 Informationstechnologie ISO/IEC 23009-1:2014 – Dynamisches adaptives Streaming über 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.

Dauer

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

• Der DASH-Endpunkt unterstützt gleichzeitige TCP-Verbindungen. Sie können Verbindungen gemäß HTTP/1.1 wiederverwenden.
• Die Segmente für MPD und Initialisierung sollten innerhalb von drei Sekunden nach dem ersten Mediasegment platziert werden. Wir empfehlen, das Initialisierungssegment in die MPD-Datei aufzunehmen.
• Für jedes Segment oder jede MPD-Datei muss eine separate PUT-Anfrage verwendet werden. Ein mehrteiliger 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 einer nicht sequenziellen Reihenfolge innerhalb eines Zeitfensters von etwa 3 Sekunden bereitgestellt werden.
• Die Segmente für MPD und Initialisierung sollten mindestens alle 60 Sekunden mit availabilityStartTime und startNumber aktualisiert werden. Wie oben erwähnt, kann das Initialisierungssegment in die MPD-Datei aufgenommen werden. In diesem Fall kann eine PUT-Anfrage beide Segmente aktualisieren.

URL-Struktur

Der Encoder muss PUT-URLs bilden, indem er einen String an die Basis-URL des YouTube-Endpunkts anhängt. Du musst den DASH-Aufnahmeendpunkt mithilfe der YouTube Live Streaming API erstellen.

Der Encoder kann die Basis-URL des Endpunkts programmatisch über die YouTube Live Streaming API abrufen. Die Basis-URL ist auch in der Benutzeroberfläche von YouTube Live Events sichtbar, wenn du die URL manuell im Encoder angeben möchtest.

Der an die Basis-URL angehängte String 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 auf .mpd enden, damit der YouTube-Server die MPD-Datei einfach identifizieren kann.Andere Segment-URLs dürfen nicht mit .mpd enden.

Initialisierungs- und Mediasegment-URLs

Die URL des Initialisierungssegments und alle Mediensegment-URLs 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-Datei muss vollständig sein und dem DASH-Standard entsprechen. Sie muss genau eines der folgenden Elemente enthalten. Diese Liste enthält Elemente, die speziell für YouTube erforderlich sind, und der DASH-Standard kann zusätzliche erforderliche Elemente identifizieren. Die Elemente werden in 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 kleiner oder gleich 60 Sekunden (PT60S) festgelegt werden.
• Im Attribut media des Elements <SegmentTemplate> muss angegeben werden, dass Mediasegment-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. In der Regel ist ein Initialisierungssegment viel kleiner. Wenn das Initialisierungssegment in der MPD-Datei enthalten ist, darf die URL data:, die das Segment enthält, nicht länger als 100 KB sein.

Encoderausgabe

Das Initialisierungssegment und die Mediasegmente müssen einen Multiplex-ISO-BMFF- oder WebM-Dateistream mit geschlossenen Bildergruppen (Bildgruppen) bilden.

• 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 die Streamverschlüsselung über HTTPS. Wir empfehlen 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 dem Rest des Streams entspricht.

Der XPath für dieses Element lautet:

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

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

Zielsegmentdauer

Für eine gute Aufnahmeleistung und einen guten Kompromiss zwischen Durchsatz und Latenz sollte die Länge Ihrer Mediasegmente zwischen 1 und 5 Sekunden liegen.Wir empfehlen Ihnen dringend, die Zieldauer dieser Segmente im 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 berechnete Dauer aus diesen Attributen muss innerhalb eines Faktors von 2 liegen, d. h. die tatsächliche Länge des Segments oder die Streamingleistung kann beeinträchtigt werden.

Die Zieldauer für die Aufnahme entspricht nicht der Chunk-Dauer für den Livestream, den YouTube generiert. YouTube transkodiert und unterteilt die Eingabe neu. Die Dauer des Ausgabeziels hängt davon ab, ob ein Stream für die Streamingqualität oder die Latenz optimiert ist.

Wiederholungsversuche und exponentieller Backoff

Alle HTTP PUT-Anfragen sollten mit einer Zeitüberschreitung ausgeführt werden. Wir empfehlen, den Wert auf einen Wert festzulegen, der 500 Millisekunden über der Segmentdauer liegt.

Eine PUT-Anfrage für ein Mediensegment, die aufgrund von Zeitüberschreitungen oder anderen Fehlern fehlschlägt, entspricht einer Lücke im Videostream. Daher sollten Sie eine solche Anfrage 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 wieder fehlschlägt, warten Sie einen zufälligen Zeitraum zwischen [0 ... 200] Millisekunden und wiederholen Sie die Anfrage.
3. Wenn die Anfrage wieder fehlschlägt, warten Sie einen zufälligen Zeitraum zwischen [0 ... 400] Millisekunden und wiederholen Sie die Anfrage.
4. und so weiter

Beachte, dass wiederholte Fehler dem Encoder-Operator angezeigt 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 Segmente zurückgibt, die über DASH ausgeliefert werden.

200 (OK)

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

202 (Akzeptiert)

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

Diese Antwort tritt am häufigsten bei nicht sequenzieller Auslieferung eines Segments auf. Normalerweise kann YouTube das akzeptierte Segment nach Erhalt der vorherigen Segmente korrekt verarbeiten, ohne dass du das Segment noch einmal senden musst.

Beispielsweise kann YouTube die Antwort „202“ in den folgenden Fällen zurückgeben:

• Ein Initialisierungssegment wird vor der MPD-Datei empfangen.
• Mediasegmente werden vor den MPD- und Initialisierungssegmenten empfangen.
• Ein Mediasegment 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 Kennung nach Erhalt der POST- oder PUT-Anforderung nicht vollständig validieren kann. Das kann z. B. passieren, wenn YouTube ein Initialisierungssegment erhält und akzeptiert, bevor die MPD-Datei empfangen wurde, das Initialisierungssegment jedoch ungültig ist. In diesem Fall akzeptiert YouTube das Initialisierungssegment, gibt einen 202-Fehler zurück und stellt dann fest, ob das Segment bei Erhalt der MPD-Datei gültig ist. Sie können dieses spezielle Szenario vermeiden, indem Sie das Segment „Initialisierung“ in die MPD-Datei aufnehmen.

400 (Bad Request)

Die Antwort „HTTP 400 (Bad Request)“ zeigt an, dass eines der folgenden Probleme aufgetreten ist:

• 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)

Die Antwort „HTTP 401 (Unauthorized)“ gibt an, dass die Basis-URL für den YouTube-DASH-Endpunkt beschädigt oder abgelaufen ist.

405 (Methode nicht zulässig)

Die Antwort „HTTP 405 (Method Not Allowed)“ gibt an, dass eine andere Anfrage als POST oder PUT gesendet wurde.

409 (Conflict)

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

Wichtig:Ein Encoder muss diesen Antwortcode richtig verarbeiten, da er jederzeit zurückgegeben werden kann, auch während des normalen Betriebs. Obwohl es keine Begrenzung für die Anzahl der Wiederholungen gibt, sollten wiederholte Fehler dem Encoder-Operator signalisiert werden, dass die Übertragung fehlschlägt.

500 (Interner Serverfehler)

Die Antwort „HTTP 500 (Interner Serverfehler)“ gibt an, dass der Server die Anfrage nicht verarbeiten konnte. Für diesen 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 gestellt werden. Bei der Sequenz wird davon ausgegangen, dass die Basis-URL für den YouTube-DASH-Endpunkt so aussieht:

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

Die Sequenz zeigt separat die Segmente für MPD und Initialisierung. Das Initialisierungssegment kann jedoch direkt in der MPD-Datei dargestellt werden. Das wird empfohlen. Darüber hinaus sollten die MPD- und Initialisierungssegmente mindestens alle 60 Sekunden aktualisiert werden. Schließlich werden die URLs für diese Segmente in dieser Sequenz wieder eingefügt, 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

Die folgende Beispiel-MPD hat ein eingebettetes Initialisierungssegment in einer RFC 2397-Daten-URL. Wir empfehlen, das Initialisierungssegment nicht auf diese Weise einzubetten, sondern separat einzubetten.

Dieses Beispiel ist konform für die WebM-Aufnahme (VP8 oder VP9, Opus) auf YouTube. Der Großteil der Daten-URL wurde aus Gründen der Lesbarkeit entfernt:

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

Die folgende MPD-Beispieldatei ohne eingebettetes Initialisierungssegment ist auch für die WebM-Aufnahme (VP8 oder VP9, Opus) mit YouTube kompatibel:

<?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 Beispiels für ein WebM-Initialisierungssegment. Es besteht aus dem Teil des WebM-Streams bis zum ersten Cluster.

Medien

Im Folgenden wird das Layout eines WebM-Beispielmediensegments gezeigt. Sie besteht aus einem einzigen WebM-Cluster. Wie bei einem ISO-BMFF-Stream sollte das Initialisierungssegment, das einer Reihe von Clustern vorangestellt ist, einen gültigen WebM-Stream erstellen.

ISO-BMFF-Segmente

MPD mit eingebettetem Initialisierungssegment

Die folgende Beispiel-MPD hat ein eingebettetes Initialisierungssegment in einer RFC 2397-Daten-URL. Wir empfehlen, das Initialisierungssegment nicht auf diese Weise einzubetten, sondern separat einzubetten.

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

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

Die folgende Beispiel-MPD hat kein eingebettetes Initialisierungssegment und ist auch für die Aufnahme von YouTube nach ISO BMFF (H.264, AAC) 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: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 Beispiels für ein Multiplex-ISO-BMFF-Initialisierungssegment. 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-Mediensegments. 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 abgeschlossenen Multiplex-ISO-BMFF-Stream zu erzeugen.

Bekannte Einschränkungen

RTMP- und DASH-Datenaufnahme

Es ist nicht möglich, RTMP- und DASH-Aufnahmen mit YouTube zu mischen.Dies gilt sowohl für den Wechsel zwischen den beiden Diensten während einer Übertragung als auch für die Verwendung einer Methode als primäre Aufnahmemethode und die andere für die Sicherung der Datenaufnahme.