Dokument ten zawiera wskazówki dotyczące używania formatu wyświetlania DASH do strumieniowego przesyłania danych w YouTube z kodera. Ma na celu pomóc dostawcom koderów w dostawie ich obsługi DASH.
Informacje o DASH
Poniższa lista zawiera najważniejsze funkcje i atrybuty DASH:
- Na podstawie otwartych standardów.
- Na podstawie HTTP. W rezultacie DASH jest przystosowana do infrastruktury internetowej i może przechodzić przez 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ą wytrzymałość niż protokoły oparte na pojedynczym połączeniu TCP.
- Bezpieczne dostarczanie przez HTTPS.
- Bezproblemowe dostarczanie przez HTTP i HTTPS.
- Niezależne od kodeka.
- Obsługuje pliki MP4 zawierające H264 i AAC oraz WebM zawierające VP8/VP9 i Vorbis/Opus.
Specyfikacja
- DASH opisano w artykule Technologia informacyjna ISO/IEC 23009-1:2014 – dynamiczne adaptacyjne strumieniowe przesyłanie danych przez HTTP (DASH).
- Standard WebM w DASH jest opisany w specyfikacji WebM DASH.
Wymagania
W poniższych podsekcjach opisano wymagania dotyczące korzystania z 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 równoczesne połączenia TCP. Zgodnie z protokołem HTTP/1.1 możesz używać połączeń ponownie.
- Segmenty MPD i inicjowania powinny być PUT w ciągu 3 sekund pierwszego segmentu multimediów. (zalecamy uwzględnienie segmentu Inicjalizacja w pliku MPD).
- Każdy segment lub plik MPD musi mieć osobne żądanie PUT. Nie można przesyłać wielu części naraz.
- Operacje PUT w segmentach multimediów mogą się nakładać w czasie, aby zwiększyć przepustowość przesyłania.
- Segmenty mogą być wyświetlane w niesekwencyjnej kolejności w ciągu około 3 sekund.
- Segmenty MPD i inicjowania należy aktualizować co najmniej co 60 sekund, a informacje o wartościach
availabilityStartTimeistartNumbernależy aktualizować. (Jak wspomnieliśmy wcześniej, segment inicjalizacji można uwzględnić w MPD). W takim przypadku jedno żądanie PUT może zaktualizować oba segmenty).
Struktura adresów URL
Twój koder musi utworzyć adresy URL PUT, dołączając ciąg 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 potem automatycznie uzyskiwać podstawowy adres URL punktu końcowego za pomocą interfejsu YouTube Live Streaming API. Podstawowy URL jest też widoczny w interfejsie wydarzeń na żywo w YouTube, jeśli chcesz ręcznie podawać adres URL w koderze.
Ciąg znaków dołączony 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 MPD
Oprócz powyższego wymogu adres URL MPD musi kończyć się ciągiem .mpd, aby serwer YouTube mógł łatwo zidentyfikować MPD.Adresy URL innych segmentów nie mogą kończyć się na „.mpd”.
URL-e segmentów inicjujących i multimediów
URL segmentu inicjowania i wszystkie adresy URL segmentów multimediów muszą kończyć się ciągiem .mp4, jeśli dane są w kontenerze ISO BMFF, lub adresem .webm, jeśli dane są umieszczone w kontenerze WebM.
Zawartość MPD
Element MPD musi być kompletny i zgodny ze standardem DASH. Musi zawierać dokładnie jeden z następujących elementów. Na liście znajdują się elementy wymagane przez YouTube, a standard DASH może uwzględniać dodatkowe wymagane elementy. Elementy są przedstawione 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
minimumUpdatePeriodelementu<MPD>musi mieć wartość równą 60 sekund (PT60S) lub mniejszą. - Atrybut
mediaelementu<SegmentTemplate>musi określać, że adresy URL segmentów multimediów są generowane za pomocą$Number$. (atrybutstartNumberokreśla liczbę, która zostanie przypisana do pierwszego segmentu multimediów).
Długość segmentu inicjowania
Segment inicjalizacji nie może być większy niż 100 kB. (Zwykle segment inicjowania jest znacznie mniejszy). Jeśli segment inicjuje się w pliku MPD, adres URL data: zawierający ten segment nie może być dłuższy niż 100 KB.
Dane wyjściowe kodera
Segment inicjowania i segmenty multimediów muszą być składankami strumieniowanych plików ISO BMFF lub WebM z grupami GOP (grupami zdjęć).
- Rozmiar grupy GOP powinien wynosić około 2 sekund i nie może przekraczać 8 sekund.
- Strumień Multiplex musi zawierać ścieżki audio i wideo.
Dodatkowe sprawdzone metody
Szyfrowanie
YouTube obsługuje szyfrowanie strumieni przez HTTPS. Zdecydowanie zalecamy korzystanie z tej funkcji.
Segmenty inicjujące w MPD
Możesz zainicjować segment inicjowania bezpośrednio w MPD za pomocą adresu URL data: zgodnie z RFC 2397. Ułatwia to konfigurację strumienia i zmniejsza ryzyko, że segment Inicjacja nie będzie odpowiadać pozostałej części strumienia.
Ścieżka XPath do tego elementu to:
/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute:data
Czasy trwania segmentów docelowych
Aby zachować dobrą jakość przetwarzania i odpowiednią równowagę między przepustowością a czasem oczekiwania, długość segmentów multimedialnych powinna wynosić od 1 do 5 sekund.Zdecydowanie zalecamy podanie w MPD docelowego czasu 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
Obliczony czas trwania dla tych atrybutów powinien mieścić się w granicach 2 rzeczywistych czasów trwania segmentów lub może to negatywnie wpływać na wydajność strumieniowego przesyłania danych.
Pamiętaj, że docelowy czas trwania przetwarzania nie jest równy czasowi transmisji w trakcie transmisji na żywo w YouTube. YouTube transkoduje treści i ponownie je dzieli, a czas trwania wyjścia zależy od tego, czy transmisja jest zoptymalizowana pod kątem jakości czy czasu oczekiwania.
Ponawianie prób i wzrastające ponawianie
Wszystkie żądania HTTP PUT 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 mediów, które zakończyło się niepowodzeniem, z powodu przekroczenia limitu czasu lub innych błędów, odpowiada luki w strumieniu wideo. W związku z tym spróbuj ponownie wykonać każde żądanie za pomocą losowego binarnego wzrastającego czasu do ponowienia:
- Po nieudanej próbie odczekaj
[0 ... 100]milisekund i spróbuj ponownie. - Jeśli to nie pomoże, odczekaj
[0 ... 200]milisekundy i spróbuj jeszcze raz. - Jeśli to nie pomoże, odczekaj
[0 ... 400]milisekundy i spróbuj jeszcze raz. - itd.
Pamiętaj, że powtarzające się awarie powinny być sygnalizowane operatorowi kodera, ponieważ odpowiadają one komunikatowi o niepowodzeniu.
Kody odpowiedzi HTTP
W kolejnych sekcjach opisujemy kody odpowiedzi zwracane przez YouTube w odpowiedzi na segmenty dostarczone przez DASH.
200 (OK)
Odpowiedź HTTP 200 (OK) wskazuje, że serwer YouTube otrzymał oczekiwaną operację i został nią obsłużony.
202 (Przyjęto)
Odpowiedź HTTP 202 (zaakceptowana) do dowolnej operacji PUT lub POST wskazuje, że była nieoczekiwana i akceptowana na potrzeby odroczenia przetwarzania. Jednak odroczona operacja może się zakończyć lub nie udać, więc odpowiedź nie gwarantuje, że YouTube uda się ją zrealizować.
Ta odpowiedź pojawia się najczęściej, gdy segment wyświetla się niesekwencyjnie. YouTube może prawidłowo przetworzyć akceptowany segment po otrzymaniu poprzednich segmentów, przy czym nie trzeba wysyłać ponownie segmentu.
YouTube może zwrócić odpowiedź 202 w dowolnym z tych przypadków:
- Segment inicjujący jest odbierany przed MPD.
- Segmenty multimediów są wysyłane przed segmentami MPD i inicjowania.
- Segment multimedialny jest pobierany przed wcześniejszym segmentem, np. segment 3 jest odbierany przed segmentem 2.
Odpowiedź 202 może jednak wskazywać, że identyfikator elementu jest nieprawidłowy, jeśli YouTube nie może w pełni zweryfikować identyfikatora po otrzymaniu żądania POST lub PUT. Może się tak zdarzyć, jeśli np. YouTube otrzyma i zaakceptuje segment inicjujący przed otrzymaniem pliku MPD, ale segment inicjowania okazuje się nieprawidłowy. W takim przypadku YouTube akceptuje segment inicjowania i zwraca błąd 202, a następnie określa, czy segment jest prawidłowy po otrzymaniu MPD. Aby tego uniknąć, dodaj segment inicjalizacji do MPD.
400 (Nieprawidłowe żądanie)
Odpowiedź HTTP 400 (złe żądanie) oznacza, że wystąpił jeden z tych problemów:
- Adres URL jest uszkodzony
- Post jest za duży (> 10 MB)
- Nie można przeanalizować MPD
- Segment inicjalizacji w pliku MPD jest uszkodzony
401 (Brak autoryzacji)
Odpowiedź HTTP 401 (Brak autoryzacji) wskazuje, że podstawowy adres URL punktu końcowego YouTube DASH jest uszkodzony lub wygasł.
405 (Niedozwolona metoda)
Odpowiedź HTTP 405 (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 wskazuje, że YouTube nie może przetworzyć żądania. Ta odpowiedź może na przykład wystąpić, gdy zgłaszający wysłał wiele segmentów multimedialnych, ale YouTube wciąż nie ma MPD, segmentu inicjowania lub obu tych elementów. W tym przykładzie koder będzie musiał ponownie przesłać segmenty MPD i inicjowania przed ponowną próbą wykonania nieudanego żądania.
500 (wewnętrzny błąd serwera)
Odpowiedź HTTP 500 (wewnętrzny błąd serwera) wskazuje, że serwer nie może przetworzyć żądania. W przypadku tego błędu zalecamy ponowne wykonanie żądania za pomocą wykładniczego ponawiania.
Przykłady
Sekwencja adresów URL
Poniższa sekwencja adresów URL pokazuje serię żądań PUT, które zostaną przesłane w celu dostarczenia treści za pomocą DASH. Sekwencja zakłada, że podstawowy adres URL punktu końcowego YouTube DASH to:
http://upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=
Sekwencja pokazuje segmenty MPD i inicjowania wysyłane oddzielnie. Segment inicjalizacji można jednak reprezentować bezpośrednio w MPD i zalecamy tę praktykę. Dodatkowo segmenty MPD i inicjowania powinny być aktualizowane co najmniej co 60 sekund. Ostatecznie adresy URL tych segmentów pojawią się ponownie w takiej sekwencji, a później adresy URL kolejnych segmentów.
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=dash.mpd PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=init.mp4 PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media001.mp4 PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media002.mp4 PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media003.mp4 ...
Segmenty WebM
Element MPD z umieszczonym segmentem inicjowania
Ten przykładowy plik MPD ma wbudowany segment inicjowania w adresie URL danych RFC 2397. Zalecamy umieszczenie segmentu Inicjacja w ten sposób zamiast wysyłania go osobno.
Ten przykład jest zgodny z przetwarzaniem WebM (VP8 lub VP9, Opus) w YouTube. Większość adresów URL danych została usunięta, aby była bardziej czytelna:
<?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©=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 inicjowania, jest również 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©=0&file=init.webm"
media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=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 pokazano układ przykładowego segmentu inicjowania WebM. Składa się z części strumienia WebM, która nie obejmuje pierwszego klastra.
Media
Poniżej znajduje się układ przykładowego segmentu multimediów WebM. Składa się z jednego klastra WebM. Podobnie jak w przypadku strumienia ISO BMFF, segment inicjowania dołączony do serii klastrów powinien wygenerować prawidłowy strumień WebM.
Segmenty BMFF ISO
Element MPD z umieszczonym segmentem inicjowania
Ten przykładowy plik MPD ma wbudowany segment inicjowania w adresie URL danych RFC 2397. Zalecamy umieszczenie segmentu Inicjacja w ten sposób zamiast wysyłania go osobno.
Ten przykład jest zgodny z przetwarzaniem ISO BMFF (H.264, AAC) w YouTube. Większość adresów URL danych została usunięta, aby była bardziej czytelna:
<?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©=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 plik MPD, który nie zawiera osadzonego segmentu inicjowania, jest również zgodny z przetwarzaniem 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©=0&file=init.mp4"
media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=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 ISO BMFF. YouTube nie zawsze używa atomów, ale to jest zgodny przykład. Przede wszystkim przedstawione są ścieżki audio i wideo.
Media
Poniższy diagram przedstawia układ przykładowego multipleksu segmentu ISO BMFF. YouTube nie musi wykorzystać wszystkich atomów, ale to jest zgodny przykład. Przede wszystkim przedstawione są ścieżki audio i wideo. Szereg tych segmentów można dołączyć do segmentu inicjowania w celu utworzenia poprawnego i zakończonego strumieniem ISO BMFF.
Znane ograniczenia
Przetwarzanie RTMP i DASH
Przetwarzania RTMP i DASH nie można łączyć w YouTube.Obejmuje to przełączanie się między obiema transmisjami i używanie jednej z nich jako podstawowej metody pozyskiwania, a drugiej – zapasowej.