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

Ten dokument zawiera wskazówki dotyczące korzystania z formatu dostarczania Dynamic Adaptive Streaming over HTTP (DASH) do strumieniowego przesyłania danych na żywo w YouTube z kodera. Ma to na celu pomóc dostawcom koderów w dodaniu do swoich produktów obsługi dostarczania DASH.

Informacje o DASH

Poniżej znajdziesz listę najważniejszych funkcji i atrybutów DASH:

  • na podstawie otwartych standardów,
  • oparte na protokole HTTP. Dzięki temu DASH jest przyjazny dla infrastruktury internetowej i może przechodzić przez zapory sieciowe.
  • Obsługuje wysoką szybkość transmisji. DASH obsługuje wiele jednoczesnych sesji HTTP i dostarczanie segmentów w kolejności innej niż sekwencyjna, co zapewnia większą odporność niż protokoły oparte na jednym połączeniu TCP.
  • Bezpieczne dostarczanie za pomocą protokołu HTTPS.
  • Bezstratne przesyłanie za pomocą protokołów HTTP i HTTPS.
  • Niezależne od kodeka.
  • Obsługuje format MP4 z H264 i AAC oraz WebM z VP8/VP9 i Vorbis/Opus.

Specyfikacja

Wymagania

W podsekcjach poniżej znajdziesz wymagania dotyczące korzystania z DASH do przesyłania transmisji na żywo do YouTube.

Czas

Punkt końcowy YouTube DASH działa jak pasywny serwer HTTP, który rejestruje wywołania metody PUT wysyłane przez koder.

  • Punkt końcowy DASH obsługuje jednoczesne połączenia TCP. Połączenia można ponownie wykorzystywać zgodnie z protokołem HTTP/1.1.
  • Plik MPD i segmenty inicjujące powinny zostać przesłane w ciągu 3 sekund od pierwszego segmentu multimediów. (Zalecamy uwzględnienie segmentu inicjowania w pliku 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 dotyczące segmentów multimediów mogą się nakładać w czasie, aby zwiększyć przepustowość przesyłania.
  • Segmenty mogą być dostarczane w kolejności niechronologicznej w oknie czasowym wynoszącym około 3 sekundy.
  • Plik MPD i segmenty inicjowania powinny być aktualizowane co najmniej co 60 sekund za pomocą zaktualizowanych wartości availabilityStartTime i startNumber. (Jak wspomnieliśmy wyżej, segment inicjujący może być uwzględniony w MPD. W takim przypadku jedno żądanie PUT może zaktualizować oba segmenty).

Struktura adresów URL

Koder musi tworzyć adresy URL PUT, dodając ciąg znaków do podstawowego adresu URL punktu końcowego YouTube. Musisz utworzyć punkt końcowy przetwarzania DASH za pomocą interfejsu YouTube Live Streaming API.

Koder może następnie uzyskać podstawowy adres URL punktu końcowego programowo za pomocą interfejsu YouTube Live Streaming API. Podstawowy adres URL jest też widoczny w interfejsie wydarzeń na żywo w YouTube, jeśli chcesz podać go koderowi ręcznie.

Ciąg znaków dołączony do podstawowego adresu URL może zawierać te znaki ASCII:

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

Adresy URL MPD

Oprócz powyższego wymagania adres URL MPD musi kończyć się znakiem .mpd, co ułatwia serwerowi YouTube identyfikację MPD. Adresy URL innych segmentów nie mogą kończyć się znakiem .mpd.

Adresy URL inicjowania i segmentów multimediów

Adres URL segmentu inicjującego i wszystkie adresy URL segmentów multimedialnych muszą kończyć się znakiem .mp4, jeśli dane znajdują się w kontenerze ISO BMFF, lub znakiem .webm, jeśli dane znajdują się w kontenerze WebM.

Zawartość MPD

Plik MPD musi być kompletny i zgodny ze standardem DASH. Musi zawierać dokładnie po jednym z tych elementów: Ta lista zawiera elementy wymagane przez YouTube. Standard DASH może określać 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ą $Number$. (Atrybut startNumber określa numer, który zostanie przypisany do pierwszego segmentu multimediów).

Długość segmentu inicjującego

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

Dane wyjściowe kodera

Segment inicjujący i segmenty multimedialne muszą stanowić strumień pliku ISO BMFF lub WebM z multipleksowaniem i zamkniętymi grupami GOP (grupami obrazów).

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

Dodatkowe sprawdzone metody

Szyfrowanie

YouTube obsługuje szyfrowanie strumieni za pomocą protokołu HTTPS. Zdecydowanie zalecamy korzystanie z tej funkcji.

Segmenty inicjujące w MPD

Segment inicjujący możesz przedstawić bezpośrednio w MPD za pomocą adresu URL data: zgodnie z RFC 2397. Upraszcza to konfigurację strumienia i zmniejsza prawdopodobieństwo, że segment inicjujący nie będzie odpowiadać reszcie strumienia.

Ścieżka XPath tego elementu to:

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

Docelowe czasy trwania segmentów

Aby uzyskać dobrą wydajność przesyłania i odpowiedni kompromis między przepustowością a opóźnieniem, długość segmentów multimediów powinna wynosić od 1 do 5 sekund. Zdecydowanie zalecamy podanie docelowego czasu trwania tych segmentów w pliku MPD 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

Obliczony czas trwania na podstawie tych atrybutów powinien być w zakresie 2-krotności wszystkich rzeczywistych czasów trwania segmentów, w przeciwnym razie może dojść do pogorszenia wydajności przesyłania strumieniowego.

Pamiętaj, że docelowy czas trwania przesyłania nie jest równy czasowi trwania fragmentu transmisji na żywo, którą generuje YouTube. YouTube transkoduje i ponownie dzieli dane wejściowe na fragmenty, a docelowy czas trwania danych wyjściowych zależy od tego, czy strumień jest zoptymalizowany pod kątem jakości strumieniowania czy pod kątem opóźnienia.

Ponowne próby i wzrastający czas do ponowienia

Wszystkie żądania PUT w protokole HTTP powinny być wykonywane z uwzględnieniem przekroczenia limitu czasu. Zalecamy ustawienie wartości o 500 milisekund większej niż czas trwania segmentu.

Żądanie PUT segmentu multimediów, które nie powiedzie się z powodu przekroczenia limitu czasu lub innych błędów, odpowiada przerwie w strumieniu wideo. Dlatego w przypadku takich żądań należy ponawiać próby, stosując losowy wzrastający czas do ponowienia:

  1. Po niepowodzeniu odczekaj losowy czas z zakresu [0 ... 100] milisekund i ponów żądanie.
  2. Jeśli żądanie ponownie się nie powiedzie, odczekaj losowy okres od [0 ... 200] milisekund i ponów żądanie.
  3. Jeśli żądanie ponownie się nie powiedzie, odczekaj losowy okres od [0 ... 400] milisekund i ponów żądanie.
  4. itd.

Pamiętaj, że powtarzające się błędy należy zgłaszać operatorowi kodera, ponieważ oznaczają one nieudaną transmisję.

Kody odpowiedzi HTTP

W sekcjach poniżej znajdziesz wyjaśnienie kodów odpowiedzi, które YouTube zwraca w odpowiedzi na segmenty dostarczane za pomocą DASH.

200 (OK)

Odpowiedź HTTP 200 (OK) oznacza, że serwer YouTube otrzymał oczekiwaną operację i została ona pomyślnie obsłużona.

202 (Przyjęto)

Odpowiedź HTTP 202 (Accepted) na dowolną operację PUT lub POST oznacza, że operacja była nieoczekiwana i została zaakceptowana do późniejszego przetworzenia. Operacja odroczona może się jednak powieść lub nie, więc odpowiedź nie gwarantuje, że YouTube będzie w stanie ją przetworzyć.

Ta odpowiedź występuje najczęściej, gdy segment jest dostarczany w nieprawidłowej kolejności. Zwykle po otrzymaniu poprzednich segmentów YouTube może prawidłowo przetworzyć zaakceptowany segment i nie musisz go ponownie wysyłać.

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

  • Segment inicjujący jest odbierany przed plikiem MPD.
  • Segmenty multimedialne są odbierane przed segmentami MPD i inicjującymi.
  • Segment multimedialny jest odbierany przed wcześniejszym segmentem, np. segment 3 jest odbierany przed segmentem 2.

Odpowiedź 202 może jednak również wskazywać, że identyfikator elementu jest nieprawidłowy, jeśli YouTube nie może w pełni zweryfikować identyfikatora po otrzymaniu żądania POST lub PUT. Dzieje się tak na przykład wtedy, gdy YouTube otrzyma i zaakceptuje segment inicjujący przed otrzymaniem pliku MPD, ale okaże się, że segment inicjujący jest nieprawidłowy. W takim przypadku YouTube akceptuje segment inicjujący i zwraca kod 202, a następnie po otrzymaniu pliku MPD sprawdza, czy segment jest prawidłowy. Aby uniknąć tej sytuacji, uwzględnij w pliku MPD segment inicjowania.

400 (nieprawidłowe żądanie)

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

  • Adres URL jest zniekształcony.
  • Post jest za duży (> 10 MB).
  • Nie można przeanalizować opisu prezentacji multimedialnej (MPD).
  • Segment inicjujący w pliku MPD jest uszkodzony.

401 (brak autoryzacji)

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

405 (Niedozwolona metoda)

Odpowiedź HTTP 405 (Method Not Allowed) oznacza, że wysłano żądanie inne niż POST lub PUT.

409 (Konflikt)

Odpowiedź HTTP 409 (Conflict) na dowolną operację PUT lub POST oznacza, że YouTube nie może przetworzyć żądania. Na przykład ta odpowiedź może wystąpić, jeśli osoba wysyłająca żądanie przesłała wiele segmentów multimedialnych, ale YouTube nadal nie ma pliku MPD, segmentu inicjującego lub obu tych elementów. W tym przykładzie koder musiałby ponownie przesłać segmenty MPD i inicjujące przed ponowną próbą wysłania nieudanego żądania.

500 (wewnętrzny błąd serwera)

Odpowiedź HTTP 500 (Wewnętrzny błąd serwera) oznacza, że serwer nie mógł przetworzyć żądania. W przypadku tego błędu zalecamy ponowienie żądania z wzrastającym czasem do ponowienia.

Przykłady

Sekwencja adresów URL

Sekwencja adresów URL poniżej przedstawia serię żądań PUT, które są wysyłane w celu dostarczania treści za pomocą DASH. W sekwencji zakłada się, że podstawowy adres URL punktu końcowego YouTube DASH to:

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

Sekwencja pokazuje MPD i segmenty inicjujące wysyłane oddzielnie. Segment inicjujący może być jednak reprezentowany bezpośrednio w MPD i jest to zalecane. Dodatkowo segmenty MPD i inicjujące powinny być aktualizowane co najmniej co 60 sekund. W końcu adresy URL tych segmentów pojawią się ponownie w tej sekwencji, a po nich nastąpią adresy URL kolejnych segmentów multimedialnych.

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,

MPD z osadzonym segmentem inicjowania

Poniższy przykładowy plik MPD zawiera umieszczony segment inicjujący w adresie URL danych RFC 2397. Zalecamy osadzanie segmentu inicjującego w ten sposób zamiast wysyłania go osobno.

Ten przykład jest zgodny z wymaganiami dotyczącymi przesyłania plików WebM (VP8 lub VP9, Opus) do YouTube. Większość adresu URL danych została pominięta dla czytelności:

<?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 plik MPD, który nie zawiera osadzonego segmentu inicjującego, jest również zgodny z przetwarzaniem w YouTube plików WebM (VP8 lub VP9, Opus):

<?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 przedstawiamy układ przykładowego segmentu inicjującego WebM. Składa się z części strumienia WebM do pierwszego klastra włącznie.

Multimedia

Poniżej przedstawiono układ przykładowego segmentu multimedialnego WebM. Składa się z jednego klastra WebM. Podobnie jak w przypadku strumienia ISO BMFF, segment inicjujący dodany na początku serii klastrów powinien generować prawidłowy strumień WebM.

segmenty ISO BMFF,

MPD z osadzonym segmentem inicjowania

Poniższy przykładowy plik MPD zawiera umieszczony segment inicjujący w adresie URL danych RFC 2397. Zalecamy osadzanie segmentu inicjującego w ten sposób zamiast wysyłania go osobno.

Ten przykład jest zgodny z przesyłaniem plików ISO BMFF (H.264, AAC) do YouTube. Większość adresu URL danych została pominięta dla czytelności:

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

Poniższy przykładowy plik MPD, który nie zawiera osadzonego segmentu inicjującego, jest również zgodny z formatem ISO BMFF (H.264, AAC) na potrzeby przesyłania do 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 multipleksowanego segmentu inicjującego ISO BMFF. YouTube nie musi używać atomów, ale ten przykład jest zgodny z wymaganiami. W szczególności reprezentowane są zarówno ścieżki audio, jak i wideo.

Multimedia

Poniższy diagram przedstawia układ przykładowego multipleksowanego segmentu multimedialnego ISO BMFF. YouTube nie musi używać wszystkich atomów, ale ten przykład jest zgodny z wymaganiami. W szczególności reprezentowane są zarówno ścieżki audio, jak i wideo. Serię tych segmentów można dołączyć do segmentu inicjującego, aby uzyskać prawidłowy i kompletny strumień multipleksowany ISO BMFF.

Znane ograniczenia

Przesyłanie RTMP i DASH

Nie można łączyć transmisji RTMP i DASH w YouTube. Dotyczy to przełączania się między nimi podczas transmisji, a także używania jednej z nich jako podstawowej metody przesyłania danych, a drugiej jako metody zapasowej.