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

Z tego dokumentu dowiesz się, jak używać protokołu Transmisja na żywo przez HTTP (HLS) do przesyłania strumieniowego danych na żywo w YouTube z kodera. Ten dokument jest przeznaczony dla dostawców koderów, którzy chcą dodać do swoich produktów obsługę przesyłania danych HLS. Przesyłanie strumieniowe HLS to dobry wybór w przypadku treści premium, które wymagają wysokiej jakości i rozdzielczości przy stosunkowo większym opóźnieniu. Krótkie porównanie różnych protokołów przetwarzania obsługiwanych przez transmisje na żywo w YouTube znajdziesz w artykule Porównanie protokołów przetwarzania transmisji na żywo w YouTube.

Aby przesyłać strumieniowo dane na żywo za pomocą HLS, koder powinien wysyłać serię playlist multimedialnych i segmentów multimedialnych do punktu końcowego HLS w YouTube za pomocą żądań HTTP PUT lub POST. Z punktu widzenia kodera punkt końcowy HLS w YouTube wygląda jak pasywny serwer HTTP.

Każdy segment multimedialny reprezentuje rzeczywistą treść multimedialną w krótkim fragmencie strumienia trwającym od 1 do 4 sekund. Każda playlista multimediów opisuje, jak ponownie złożyć segmenty multimediów w prawidłowej kolejności strumienia.

Wymagania dotyczące formatu multimediów

W przypadku przesyłania treści wideo i audio w formacie HLS do YouTube obowiązują te wymagania:

• Wideo i audio muszą być multipleksowane w formacie M2TS.
• Obsługiwane kodeki wideo to H.264 i HEVC.
• Obsługiwane są liczby klatek na sekundę do 60 kl./s.
• Obsługiwana jest tylko zamknięta grupa GOP.
• Obsługiwany kodek audio to AAC, a obsługiwany jest tylko dźwięk z 1 ścieżki.

Szczegółowe wymagania znajdziesz w sekcji Segmenty mediów.

HDR

Filmy High Dynamic Range (HDR) są obsługiwane przy użyciu kodeka HEVC i muszą spełniać te dodatkowe wymagania:

• Obsługiwane standardy kolorów to 10-bitowy PQ i HLG z nieustaloną luminancją. Więcej szczegółów:
  • Format chrominancji musi być 10-bitowy YUV 4:2:0.
  • Funkcja transferu musi być PQ (znana też jako SMPTE ST 2084) lub HLG (znana też jako ARIB STD-B67).
  • Kolory podstawowe muszą być zgodne z Rec. 2020.
  • Współczynniki matrycy muszą być zgodne z Rec. 2020 o zmiennej luminancji.
• Obsługiwane są wartości próbne z zakresu ograniczonego (lub zakresu MPEG) i pełnego (lub zakresu JPEG). Ważne jest, aby zakres był ustawiony zgodnie z zakresem wartości próbki, którego używają treści. Zalecane są wartości próbki o ograniczonym zakresie.

Uzyskiwanie adresu URL przetwarzania HLS

Uzyskiwanie adresu URL przetwarzania HLS z interfejsu YouTube API

Aby uzyskać pełny adres URL przetwarzania, koder może użyć interfejsu YouTube Live Streaming API do wstawienia zasobu liveStream z tymi właściwościami:

"cdn": {
  "ingestionType": "hls",
  "frameRate": "variable",
  "resolution": "variable"
}

W odpowiedzi interfejsu API pole cdn.ingestionInfo.ingestionAddress określa główny adres URL przetwarzania, a pole cdn.ingestionInfo.backupIngestionAddress określa zapasowy adres URL przetwarzania. Więcej informacji znajdziesz w dokumentacji dotyczącej zasobu liveStreams.

Uzyskiwanie adresu URL do przesyłania HLS w YouTube Studio

W interfejsie internetowym YouTube Studio po kliknięciu przez twórcę opcji „Utwórz strumień” YouTube wyświetla „Klucz strumienia” składający się ze znaków alfanumerycznych i myślników. Ten tajny klucz identyfikuje zarówno twórcę, jak i strumień w YouTube.

Adres URL HLS możesz utworzyć z tego klucza strumienia w ten sposób:

https://a.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=0&file=

… gdzie $STREAM_KEY to klucz strumienia wyświetlany w interfejsie internetowym. Przykład: https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst&copy=0&file=

Aby zwiększyć niezawodność, możesz przesłać drugą kopię danych do tego zapasowego adresu URL:

https://b.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=1&file=

Zwróć uwagę, że kopia zapasowa różni się od głównego adresu URL w 2 elementach: zmieniła się zarówno nazwa hosta, jak i parametr copy=. Proces przesyłania kopii zapasowej musi wysyłać inną wartość parametru copy= niż proces przesyłania podstawowego, aby uniknąć uszkodzenia strumienia.

Uzupełnianie adresu URL przetwarzania HLS

Adresy URL uzyskane za pomocą obu metod są niekompletnymi szablonami. Każdy z nich kończy się pustym parametrem zapytania file=. Aby utworzyć końcowy adres URL, koder musi dołączyć nazwę pliku listy odtwarzania multimediów lub segmentu multimediów na końcu adresu URL, uzupełniając w ten sposób parametr file=.

Wartość parametru file= podlega tym zasadom:

• Koder może utworzyć nazwę pliku listy odtwarzania multimediów lub segmentu multimediów ze znaków alfanumerycznych, podkreśleń, ukośników, łączników i kropek. Nie są obsługiwane żadne inne znaki.
• Koder nie może kodować nazwy pliku za pomocą URL-i.
• Koder może zawierać w nazwach plików komponenty ścieżki względnej lub bezwzględnej, ale nie jest to wymagane. Jeśli koder zawiera komponent ścieżki w nazwie pliku segmentu multimediów, musi odwoływać się do tej samej ścieżki w odpowiednim wpisie na playliście.

Wymagania dotyczące protokołu HLS

Playlisty multimedialne i segmenty multimedialne wysyłane przez koder muszą być zgodne ze specyfikacją HTTP Live Streaming w wersji 2.

Specyfikacja HLS definiuje 2 typy playlist: playlistę multimedialną i playlistę główną. YouTube przekodowuje przesyłane strumieniowo treści do różnych rozdzielczości i szybkości transmisji, więc koder nie musi wysyłać do YouTube treści o różnych szybkościach transmisji. W związku z tym YouTube obsługuje tylko playlisty multimedialne do przesyłania HLS, a playlisty główne są ignorowane. (Lista odtwarzania głównego zawiera zestaw strumieni wariantów, z których każdy opisuje inną wersję tego samego materiału).

Koder musi:

• przesyłać dokładnie 1 zakodowany strumień o najwyższej rozdzielczości, który chcesz wyświetlać użytkownikom (jedna rozdzielczość i jeden kodek);
• multipleksować dźwięk i obraz.
• używać protokołu HTTPS i trwałego połączenia w przypadku wszystkich żądań;

W sekcjach poniżej znajdziesz bardziej szczegółowe wymagania dotyczące list odtwarzania multimediów i segmentów multimediów.

Playlisty multimedialne

Lista odtwarzania multimediów zawiera listę segmentów multimediów, które można połączyć, aby utworzyć ciągły, dekodowalny strumień multimediów. Lista odtwarzania multimediów informuje serwer, jakich segmentów multimediów oczekuje i jak je prawidłowo uporządkować w zrekonstruowanym strumieniu.

Wymagania

• Nazwa pliku listy odtwarzania multimediów musi kończyć się znakiem .m3u8 lub .m3u.

• Pierwsza lista odtwarzania multimediów wysłana w przypadku strumienia musi zaczynać się od numeru sekwencji 0, a numer sekwencji musi rosnąć monotonicznie.

• Tag EXT-X-MEDIA-SEQUENCE musi określać numer sekwencyjny pierwszego segmentu multimediów wymienionego na playliście.

• Lista odtwarzania multimediów nie może zawierać więcej niż 5 widocznych segmentów. Segment jest nieprzetworzony, jeśli serwer go nie otrzymał lub nie potwierdził jego otrzymania.

  Oprócz wyróżniających się segmentów w każdej playliście multimedialnej umieść też kilka uznanych segmentów. Dzięki temu segment jest mniej narażony na pominięcie, jeśli playlista multimediów zostanie utracona po stronie serwera. Na przykład każda lista odtwarzania multimediów może zawierać maksymalnie 2 potwierdzone segmenty i 5 oczekujących segmentów.

  Pamiętaj, że serwer potwierdza otrzymanie segmentu multimedialnego, zwracając odpowiedź 200 (OK) lub 202 (Accepted) po przesłaniu tego segmentu. Odpowiedź A 202 oznacza, że serwer otrzymał segment przed listą odtwarzania, która go identyfikuje.

• Wysyłaj zaktualizowaną playlistę multimediów dla każdego segmentu multimediów, aby serwer mógł szybko odzyskać playlistę multimediów w przypadku jej utraty.

• Gdy serwer potwierdzi otrzymanie segmentów multimediów, możesz zwiększyć wartość tagu EXT-X-MEDIA-SEQUENCE, aby zapobiec nadmiernemu wydłużeniu playlisty z multimediami. Jeśli na przykład serwer potwierdził już otrzymanie pierwszych 9 segmentów multimediów, następna playlista z multimediami może zawierać 8., 9. i 10. segment multimediów.

• Tagi EXT-X-KEY i EXT-X-SESSION-KEY nie są obsługiwane.

Przykłady

Poniżej znajdziesz przykładową listę plików, które koder powinien wysłać:

Media Playlist file with seqnum #0
Media Segment file #0
Media Playlist file with seqnum #0-#1
Media Segment file #1
Media Playlist file with seqnum #0-#2
Media Segment file #2
Media Playlist file with seqnum #1-#3
Media Segment file #3
...

Przykład poniżej pokazuje listę odtwarzania multimediów wysłaną w trakcie transmisji wideo na żywo. Ponieważ przykład pochodzi ze środka strumienia, tag EXT-X-MEDIA-SEQUENCE ma wartość różną od zera.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:3.975,
fileSequence2680.ts
#EXTINF:3.941,
fileSequence2681.ts
#EXTINF:3.975,
fileSequence2682.ts

Segmenty multimedialne

Poniżej znajdziesz listę wymagań dotyczących segmentów mediów:

• Nazwy plików
  • Nazwy plików segmentów multimediów w adresie URL muszą mieć rozszerzenie .ts i być zgodne z nazwami plików na liście odtwarzania.
  • Nazwy plików segmentów multimediów muszą być unikalne w przypadku ponownego uruchomienia kodera i ponownego uruchomienia strumienia.
• Format
  • Segmenty multimedialne muszą być w formacie M2TS i powinny być samoinicjujące.
  • Każdy segment M2TS musi zawierać jeden program MPEG-2.
  • Segment M2TS musi zawierać PAT i PMT, a pierwsze 2 pakiety Transport Stream w segmencie powinny być PAT i PMT.
• Treść
  • Wideo i audio muszą być multipleksowane.
  • Obsługiwane kodeki wideo to H.264 i HEVC.
  • Obsługiwany jest HDR z HEVC (patrz wymagania dotyczące HDR).
  • Obsługiwane są liczby klatek na sekundę do 60 kl./s.
  • Obsługiwana jest tylko zamknięta grupa GOP.
  • Obsługiwany kodek audio to AAC, a obsługiwany jest tylko dźwięk z 1 ścieżki.
  • Zalecana długość segmentów multimedialnych to od 1 do 4 sekund, jak opisano w następnej sekcji. Segmenty multimedialne nie mogą trwać dłużej niż 5 sekund.
  • Segmenty multimediów muszą być szyfrowane tylko w warstwie TLS/SSL za pomocą protokołu HTTPS. Inne mechanizmy szyfrowania nie są obsługiwane.

Czas trwania segmentu multimediów

Oczekujemy, że przesyłanie HLS będzie używane w przypadku treści premium, które wymagają wysokiej jakości i wysokiej rozdzielczości. Przesyłanie HLS ma zwykle większe opóźnienie niż przesyłanie RTMP i WebRTC, ponieważ przesyłanie HLS jest oparte na segmentach.

Zalecamy, aby czas trwania segmentu multimediów wynosił od 1 do 4 sekund, ponieważ mniejsze segmenty multimediów mogą skutkować mniejszym opóźnieniem, ale kosztem wyższego wskaźnika ponownego buforowania i niższej wydajności kodowania. Jak wspomnieliśmy w poprzedniej sekcji, segmenty multimedialne nie mogą być dłuższe niż 5 sekund.

Szybkość transmisji bitów

W Centrum pomocy YouTube znajdziesz wytyczne dotyczące ustawień szybkości transmisji.

Pamiętaj, że HEVC zapewnia zwykle o 25–50% większą kompresję danych przy tej samej jakości wideo w porównaniu z H.264. Dlatego w przypadku HEVC można używać wartości szybkości transmisji bitów z dolnego zakresu sugerowanych wartości, aby oszczędzać przepustowość, co jest szczególnie przydatne w przypadku treści w rozdzielczości 4K.

Inne wymagania

• Koder powinien ustawić nagłówek User-Agent w żądaniu HTTP, używając tej składni, która zawiera nazwę producenta, nazwę modelu i wersję:

  User-Agent: <manufacturer> / <model> / <version>
  

Napisy

Przesyłanie HLS obsługuje 2 opcje wysyłania napisów:

• Wysyłaj napisy kodowane za pomocą osobnych żądań HTTP POST. Działa to w przypadku wszystkich transmisji HLS.
• Osadzone napisy 608/708 działają w przypadku przetwarzania HLS, które korzysta z kodeka wideo H264, ale nie w przypadku przetwarzania, które korzysta z kodeka wideo HEVC. Więcej informacji znajdziesz w artykule Wymagania dotyczące napisów na żywo w Centrum pomocy YouTube.

Kody odpowiedzi HTTP

W sekcjach poniżej znajdziesz opis kodów odpowiedzi, które YouTube zwraca w odpowiedzi na segmenty multimediów i listy odtwarzania multimediów dostarczane za pomocą HLS.

200 (OK)

W odpowiedzi na żądanie PUT lub POST odpowiedź HTTP 200 (OK) oznacza, że serwer YouTube otrzymał oczekiwaną operację i obsłużył ją prawidłowo.

W odpowiedzi na żądanie DELETE odpowiedź HTTP 200 (OK) oznacza, że serwer YouTube otrzymał i zignorował żądanie. Serwer YouTube nie wymaga od klienta usuwania żadnych zasobów w strumieniu i ignoruje żądania DELETE. Ze względu na wydajność YouTube zaleca klientom, aby nie wysyłali żądań DELETE.

202 (Przyjęto)

Odpowiedź HTTP 202 (Accepted) oznacza, że serwer YouTube otrzymał segment multimedialny przed otrzymaniem listy odtwarzania multimediów zawierającej ten segment. Wskazuje to klientowi, że powinien jak najszybciej wysłać listę odtwarzania multimediów zawierającą ten segment multimedialny, aby zapobiec opóźnieniu w przetwarzaniu tego segmentu. Pamiętaj, że nie będzie to problemem, jeśli koder będzie wysyłać zaktualizowaną listę odtwarzania multimediów dla każdego segmentu multimediów.

400 (nieprawidłowe żądanie)

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

• Adres URL jest uszkodzony
• Nie można przeanalizować playlisty lub zawiera ona nieobsługiwane tagi

401 (brak autoryzacji)

Odpowiedź HTTP 401 (Unauthorized) oznacza, że parametr cid w podstawowym adresie URL punktu końcowego YouTube HLS jest uszkodzony lub wygasł. Aby kontynuować, klient powinien zaktualizować parametr cid.

405 (Niedozwolona metoda)

Odpowiedź HTTP 405 (Method Not Allowed) wskazuje, że żądanie nie było żądaniem POST, PUT ani DELETE.

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 ze wzrastającym czasem do ponowienia.