Przesyłanie treści na żywo w YouTube za pomocą DASH

Ten dokument zawiera wytyczne dotyczące korzystania z formatu dynamicznego przesyłania adaptacyjnego przez HTTP (DASH) do transmitowania danych na żywo w YouTube za pomocą kodera. Ma ona za zadanie pomóc dostawcom koderów w dodawaniu obsługi wyświetlania DASH w ich usługach.

Informacje o DASH

Na liście poniżej znajdziesz najważniejsze funkcje i atrybuty DASH:

• Na podstawie otwartych standardów.
• Oparta na protokole HTTP. Oznacza to, że DASH jest przyjazny dla infrastruktury internetowej i może ominąć zapory sieciowe.
• Obsługuje wysoką szybkość transmisji bitów. DASH obsługuje wiele jednoczesnych sesji HTTP i niesekwencyjne dostarczanie segmentów, co zapewnia większą odporność niż protokoły korzystające z jednego połączenia TCP.
• Bezpieczne przesyłanie przez HTTPS.
• Bezstratne dostarczanie przez HTTP i HTTPS.
• Niezależność od kodeka.
• Obsługuje format MP4 zawierający H264 i AAC, a także format WebM zawierający VP8/VP9 i Vorbis/Opus.

Specyfikacja

• Format DASH został opisany w dokumencie ISO/IEC 23009-1:2014 Technologia informacyjna – dynamiczne strumieniowanie adaptacyjne przez HTTP (DASH).
• WebM nad DASH opisano w specyfikacji WebM DASH.

Wymagania

W kolejnych podsekcjach wyjaśniamy, jakie są wymagania dotyczące używania DASH do wyświetlania transmisji na żywo w YouTube.

Czas

Punkt końcowy DASH w YouTube działa jak pasywny serwer HTTP i rejestruje wywołania metody PUT wysyłane przez koder.

• Punkt końcowy DASH obsługuje jednoczesne połączenia TCP. Możesz używać połączeń wielokrotnie zgodnie z protokołem HTTP/1.1.
• Segmenty MPD i Zdarzenie inicjujące powinny być typu PUT w ciągu 3 sekund od pierwszego segmentu multimediów. (zalecamy uwzględnienie segmentu inicjowania w MPD).
• każdy segment lub MPD musi używać osobnego żądania PUT; przesyłanie wieloczęściowe wielu segmentów nie jest obsługiwane.
• Operacje PUT segmentów multimediów mogą się nakładać z czasem, aby zwiększyć przepustowość przesyłania.
• Segmenty mogą być podawane w kolejności nieciągłej w przedziale czasu trwającym około 3 sekund.
• Segmenty MPD i Inicjacja powinny być aktualizowane przynajmniej co 60 sekund za pomocą zaktualizowanych elementów availabilityStartTime i startNumber. (Jak wspomnieliśmy powyżej, segment inicjowania można uwzględnić w MPD). W takim przypadku jedno żądanie PUT może zaktualizować oba segmenty).

Struktura adresów URL

Koder musi tworzyć adresy URL typu PUT przez dołączenie ciągu do podstawowego adresu URL punktu końcowego YouTube. Punkt końcowy przetwarzania DASH musisz utworzyć za pomocą interfejsu YouTube Live Streaming API.

Koder może następnie uzyskać podstawowy adres URL punktu końcowego w sposób zautomatyzowany, korzystając z interfejsu YouTube Live Streaming API. Podstawowy URL jest też widoczny w interfejsie YouTube Wydarzenia na żywo, jeśli chcesz ręcznie podać URL koderowi.

Ciąg dołączany do podstawowego adresu URL może zawierać następujący zestaw znaków ASCII:

• małe litery: a–z
• Wielkie litery: A–Z
• Cyfry: 0–9
• Znaki specjalne: _ (podkreślenie), - (łącznik), . (kropka)

Adresy URL opisu prezentacji multimedialnej (MPD)

Oprócz powyższego wymogu adres URL opisu prezentacji multimedialnej (MPD) musi kończyć się ciągiem .mpd, co umożliwia serwerowi YouTube łatwą identyfikację opisu prezentacji multimedialnej (MPD).Adresy URL innych segmentów nie mogą kończyć się ciągiem .mpd.

Adresy URL inicjowania i segmentów multimediów

Adres URL segmentu inicjowania i wszystkie adresy URL segmentów multimediów muszą kończyć się ciągiem .mp4, jeśli dane znajdują się w kontenerze ISO BMFF, lub .webm, jeśli dane znajdują się w kontenerze WebM.

Treści MPD

Opis prezentacji multimedialnej (MPD) musi być kompletny i zgodny ze standardem DASH. Musi zawierać dokładnie jeden z poniższych elementów. Ta lista zawiera elementy wymagane przez YouTube, a standard DASH może identyfikować dodatkowe wymagane elementy. Elementy są reprezentowane za pomocą składni XPath i są zgodne ze standardem DASH.

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

Pamiętaj o tych wymaganiach dotyczących wartości elementów:

• Atrybut minimumUpdatePeriod elementu <MPD> musi mieć wartość nie większą niż 60 sekund (PT60S).
• Atrybut media elementu <SegmentTemplate> musi określać, że adresy URL segmentów multimediów są generowane za pomocą parametru $Number$. Atrybut startNumber określa numer, który zostanie przypisany do pierwszego segmentu multimediów.

Długość segmentu inicjowania

Segment inicjowania nie może być dłuższy niż 100 kb. (Zwykle segment inicjowania jest znacznie mniejszy). Jeśli w MPD uwzględniony jest segment inicjujący, adres URL data:, który zawiera ten segment, nie może być dłuższy niż 100 KB.

Dane wyjściowe kodera

Segment inicjowania i segmenty multimediów muszą stanowić zwielokrotniony strumień plików ISO BMFF lub WebM z zamkniętymi grupami GOP (grupami obrazów).

• Rozmiar grupy GOP powinien wynosić około 2 sekund i musi być krótszy niż 8 sekund.
• Multipleksowany strumień musi zawierać zarówno ścieżki audio, jak i wideo.

Dodatkowe sprawdzone metody

Szyfrowanie

YouTube obsługuje szyfrowanie strumienia przez HTTPS. Zdecydowanie zalecamy korzystanie z tej funkcji.

Segmenty inicjowania w MPD

Segment inicjowania możesz reprezentować bezpośrednio w MPD za pomocą adresu URL data: zgodnie z RFC 2397. Upraszcza to konfigurację strumienia i zmniejsza ryzyko, że segment inicjowania nie będzie odpowiadać reszty strumienia.

Ścieżka XPath dla tego elementu to:

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

Czasy trwania segmentu docelowego

Aby zapewnić dobrą wydajność pozyskiwania danych i zapewnić kompromis między przepustowością a opóźnieniem, długość segmentów multimediów powinna wynosić od 1 do 5 sekund.Zdecydowanie zalecamy, aby informować w MPD o docelowym czasie trwania tych segmentów za pomocą tych 2 elementów:

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

Czas trwania obliczony na podstawie tych atrybutów powinien mieścić się w wysokości 2 stopni względem rzeczywistej długości segmentów. W przeciwnym razie może wystąpić spadek wydajności strumieniowania.

Pamiętaj, że docelowy czas trwania przetwarzania nie jest taki sam jak czas trwania fragmentu transmisji na żywo prowadzonej przez YouTube. YouTube transkoduje dane wejściowe i dziele je na fragmenty. Docelowy czas trwania wyjścia zależy od tego, czy transmisja jest zoptymalizowana pod kątem jakości strumieniowania, czy pod kątem czasu oczekiwania.

Ponowne próby i wykładniczy czas do ponowienia

Wszystkie żądania HTTP PUT powinny być wykonywane z upływem czasu oczekiwania, który zalecamy ustawić na wartość 500 milisekund większą niż czas trwania segmentu.

Żądanie PUT segmentu multimediów, które nie zostało zrealizowane z powodu przekroczenia limitu czasu lub innych błędów, odpowiada przerwie w strumieniu wideo. Dlatego każde takie żądanie należy ponawiać, stosując losowy binarny wykładniczy czas do ponowienia:

1. Po awarii odczekaj losowy okres wynoszący [0 ... 100] milisekundy i spróbuj ponownie.
2. Jeśli żądanie ponownie się nie powiedzie, poczekaj losowy okres o długości [0 ... 200] milisekund i spróbuj jeszcze raz.
3. Jeśli żądanie ponownie się nie powiedzie, poczekaj losowy okres o długości [0 ... 400] milisekund i spróbuj jeszcze raz.
4. itd.

Pamiętaj, że powtarzające się błędy należy zasygnalizować operatorowi kodera, ponieważ dotyczą one nieudanej transmisji.

Kody odpowiedzi HTTP

W kolejnych sekcjach znajdziesz informacje o kodach odpowiedzi, które YouTube wyświetla w odpowiedzi na segmenty przesyłane za pomocą DASH.

200 (OK)

Odpowiedź HTTP 200 (OK) oznacza, że serwer YouTube odebrał oczekiwaną operację i zakończył ją pomyślnie.

202 (Przyjęto)

Odpowiedź HTTP 202 (zaakceptowana) na dowolną operację PUT lub POST oznacza, że operacja była nieoczekiwana i została zaakceptowana w przypadku odroczonego przetwarzania. Jednak odroczenie może zakończyć się sukcesem lub niepowodzeniem, więc odpowiedź nie gwarantuje, że YouTube będzie w stanie wykonać tę operację.

Ta reakcja występuje najczęściej, gdy segment jest realizowany w sposób niesekwencyjny. Zwykle YouTube może prawidłowo przetworzyć zaakceptowany segment po otrzymaniu poprzednich segmentów. Nie ma potrzeby wysyłania go ponownie.

YouTube może na przykład zwrócić odpowiedź 202 w dowolnym z tych przypadków:

• Segment inicjowania jest odbierany przed opisem opisu prezentacji multimedialnej (MPD).
• Segmenty multimediów są odbierane przed segmentami MPD i Inicjalizacji.
• Segment multimediów został odebrany przed segmentem 2, np. segment 3 został odebrany przed segmentem 2.

Odpowiedź 202 może jednak również wskazywać, że identyfikator produktu jest nieprawidłowy, jeśli YouTube nie może w pełni go zweryfikować po otrzymaniu żądania POST lub PUT. Na przykład czasami dzieje się tak, gdy YouTube odbiera i akceptuje segment inicjujący przed otrzymaniem opisu prezentacji multimedialnej (MPD), ale okazuje się on nieprawidłowy. W takim przypadku YouTube akceptuje segment inicjujący i zwraca kod 202. Następnie ustala, czy po otrzymaniu MPD jest on prawidłowy. Aby uniknąć tego konkretnego scenariusza, uwzględnij segment inicjowania w MPD.

400 (Nieprawidłowe żądanie)

Odpowiedź HTTP 400 (Nieprawidłowe żądanie) oznacza, że wystąpił jeden z tych problemów:

• Adres URL jest uszkodzony.
• Post jest za duży (ponad 10 MB).
• Nie można przeanalizować opisu prezentacji multimedialnej (MPD).
• Segment inicjowania w MPD jest uszkodzony.

401 (Brak autoryzacji)

Odpowiedź HTTP 401 (Brak autoryzacji) oznacza, że podstawowy adres URL punktu końcowego DASH w YouTube jest uszkodzony lub wygasł.

405 (niedozwolona metoda)

Odpowiedź HTTP 405 (metoda niedozwolona) wskazuje, że zostało wysłane żądanie inne niż POST lub PUT.

409 (Konflikt)

Odpowiedź HTTP 409 (konflikt) na dowolną operację PUT lub POST oznacza, że YouTube nie może przetworzyć żądania. Odpowiedź może się pojawić na przykład wtedy, gdy osoba zgłaszająca prośbę wysłała wiele segmentów multimediów, ale YouTube nadal nie ma opisu opisu prezentacji multimedialnej (MPD), segmentu inicjowania ani obu tych elementów. W takim przypadku koder musiałby ponownie przesłać segmenty MPD i Inicjacja, zanim ponownie spróbuje wysłać nieudane żądanie.

500 (wewnętrzny błąd serwera)

Odpowiedź HTTP 500 (wewnętrzny błąd serwera) oznacza, że serwer nie może przetworzyć żądania. W przypadku tego błędu zalecamy ponowienie żądania z wykładniczym ponowieniem.

Przykłady

Sekwencja adresów URL

Poniższa sekwencja adresów URL przedstawia serię żądań PUT, które zostałyby wysłane, by dostarczyć treści za pomocą DASH. W sekwencji zakładamy, że podstawowy adres URL punktu końcowego DASH w YouTube to:

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

Sekwencja pokazuje segmenty MPD i Inicjalizacji wysyłane oddzielnie. Segment inicjowania może być jednak reprezentowany bezpośrednio w MPD, dlatego zalecamy takie działanie. Dodatkowo segmenty MPD i Zdarzenie inicjujące należy aktualizować co najmniej co 60 sekund. W końcu adresy URL tych segmentów wystąpią ponownie w tej kolejności, a po nich następują adresy URL kolejnych segmentów multimediów.

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

Segmenty WebM

Opis prezentacji multimedialnej (MPD) z osadzonym segmentem inicjowania

Poniższy przykładowy MPD ma osadzony segment inicjowania w adresie URL danych RFC 2397. Zalecamy osadzenie segmentu inicjowania w ten sposób zamiast wysyłania go oddzielnie.

Ten przykład jest zgodny z przetwarzaniem danych WebM (VP8 lub VP9, Opus) do YouTube. Większość adresów URL danych została wycofana ze względu na czytelność:

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

Ten przykładowy MPD, który nie ma osadzonego segmentu inicjowania, jest też zgodny z przetwarzaniem WebM (VP8 lub VP9, Opus) w 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>

Zdarzenie inicjujące

Poniżej przedstawiono układ przykładowego segmentu inicjowania WebM. Składa się z części strumienia WebM nieprzekraczającej pierwszego klastra.

Multimedia

Poniżej przedstawiono układ przykładowego segmentu multimediów WebM. Składa się z jednego klastra WebM. Tak jak w przypadku strumienia ISO BMFF, segment inicjalizacji dołączony do serii klastrów powinien generować prawidłowy strumień WebM.

Segmenty ISO BMFF

Opis prezentacji multimedialnej (MPD) z osadzonym segmentem inicjowania

Poniższy przykładowy MPD ma osadzony segment inicjowania w adresie URL danych RFC 2397. Zalecamy osadzenie segmentu inicjowania w ten sposób zamiast wysyłania go oddzielnie.

Ten przykład jest zgodny z przetwarzaniem w YouTube zgodnie z normą ISO BMFF (H.264, AAC). Większość adresów URL danych została wycofana ze względu na czytelność:

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

Ten przykładowy MPD, który nie ma osadzonego segmentu inicjowania, jest też zgodny z przetwarzaniem treści w formacie ISO BMFF (H.264, AAC) w 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>

Zdarzenie inicjujące

Poniższy diagram przedstawia układ przykładowego zwielokrotnionego segmentu inicjowania ISO BMFF. YouTube niekoniecznie używa atomów, ale to jest właśnie odpowiedni przykład. W szczególności reprezentowane są zarówno ścieżki audio, jak i ścieżki wideo.

Multimedia

Poniższy diagram przedstawia układ przykładowego segmentu multimediów ISO BMFF. YouTube niekoniecznie wykorzystuje wszystkie atomy, ale to jest właśnie odpowiedni przykład. W szczególności reprezentowane są zarówno ścieżki audio, jak i ścieżki wideo. Seria takich segmentów można dołączyć do segmentu inicjowania, aby utworzyć prawidłowy i kompletny zwielokrotniony strumień ISO BMFF.

Znane ograniczenia

Przetwarzanie RTMP i DASH

Nie można łączyć z YouTube przetwarzania danych RTMP i DASH.Dotyczy to przełączania się między obiema metodami podczas transmisji oraz używania jednej z nich jako głównej metody przetwarzania, a drugiej do przetwarzania kopii zapasowej.