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ę przetwarzania HLS. Przetwarzanie HLS jest dobrym rozwiązaniem w przypadku treści premium, które wymagają wysokiej jakości i wysokiej rozdzielczości przy stosunkowo większym opóźnieniu. Krótkie porównanie różnych protokołów przetwarzania obsługiwanych przez YouTube na żywo znajdziesz w artykule Porównanie protokołów przetwarzania YouTube na żywo.

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

Każdy segment multimediów reprezentuje rzeczywistą treść multimedialną przez krótki czas trwania strumienia, który wynosi 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 przetwarzania HLS w YouTube obowiązują te wymagania dotyczące treści wideo i audio:

  • Wideo i audio muszą być multipleksowane w formacie M2TS.
  • Obsługiwane kodeki wideo to H.264 i HEVC.
  • Obsługiwana jest liczba klatek 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.

Więcej szczegółowych wymagań znajdziesz w sekcji Segmenty multimediów.

HDR

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

  • Obsługiwane standardy kolorów to 10-bitowy PQ i HLG o zmiennej luminancji. Dokładniej:
    • Format chrominancji musi być YUV 4:2:0 10-bitowy.
    • 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ą zarówno wartości próbek o ograniczonym zakresie (lub zakresie MPEG), jak i o pełnym zakresie (lub zakresie JPEG). Ważne jest, aby zakres był ustawiony zgodnie z zakresem wartości próbek używanych przez treść. Zalecane są wartości próbek o ograniczonym zakresie.

Uzyskiwanie adresu URL przetwarzania HLS

Uzyskiwanie adresu URL przetwarzania HLS z interfejsu API YouTube

Aby uzyskać pełny adres URL przetwarzania, kodery mogą 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 podstawowy adres URL przetwarzania, a pole cdn.ingestionInfo.backupIngestionAddress – zapasowy adres URL przetwarzania. Więcej informacji znajdziesz w dokumentacji zasobu liveStreams.

Uzyskiwanie adresu URL przetwarzania HLS z YouTube Studio

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

Na podstawie tego klucza strumienia możesz utworzyć adres URL HLS 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ć nadmiarową drugą kopię przetwarzania na ten zapasowy adres URL:

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

Zapasowy adres URL różni się od podstawowego 2 elementami: zmieniła się zarówno nazwa hosta, jak i parametr copy=. Aby uniknąć uszkodzenia strumienia, zapasowe przetwarzanie musi wysyłać inną wartość parametru copy= niż podstawowe przetwarzanie.

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ć do końca adresu URL nazwę pliku playlisty lub segmentu multimediów, uzupełniając w ten sposób parametr file=.

W przypadku wartości parametru file= obowiązują te reguły:

  • Koder może utworzyć nazwę pliku playlisty lub segmentu multimediów z znaków alfanumerycznych, podkreśleń, ukośników, łączników i kropek. Inne znaki nie są obsługiwane.
  • Koder nie może kodować nazwy pliku za pomocą URL.
  • Koder może uwzględniać w nazwach plików względne lub bezwzględne komponenty ścieżki, ale nie jest to wymagane. Jeśli koder uwzględnia 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 i segmenty multimediów wysyłane przez koder muszą być zgodne ze specyfikacją Transmisja na żywo przez HTTP 2nd Edition.

Specyfikacja HLS definiuje 2 typy playlist: playlista multimediów i playlista główna. Ponieważ YouTube transkoduje przesyłane strumieniowo treści do różnych rozdzielczości i szybkości transmisji bitów, koder nie musi wysyłać do YouTube treści o różnych szybkościach transmisji bitów. W związku z tym YouTube obsługuje tylko playlisty multimediów w przypadku przetwarzania HLS, a playlisty reklam nadrzędnych są ignorowane. (Playlista reklamy nadrzędnej zawiera zestaw strumieni wariantów, z których każdy opisuje inną wersję tej samej treści).

Koder musi:

  • wysyłać dokładnie 1 zakodowany strumień o najwyższej rozdzielczości, którą chcesz udostępniać użytkownikom (pojedyncza rozdzielczość i kodek);
  • multipleksować audio i wideo;
  • 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 playlist i segmentów multimediów.

Playlisty multimediów

Playlista multimediów zawiera listę segmentów multimediów, które można połączyć, aby utworzyć ciągły, dekodowalny strumień multimediów. Playlista multimediów informuje serwer, jakich segmentów multimediów ma się spodziewać i jak je prawidłowo uporządkować w ponownie złożonym strumieniu.

Wymagania

  • Nazwa pliku playlisty multimediów musi kończyć się rozszerzeniem .m3u8 lub .m3u.

  • Pierwsza playlista multimediów wysłana dla strumienia musi zaczynać się od numeru sekwencji 0 , a numer sekwencji musi się zwiększać monotonicznie.

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

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

    Oprócz widocznych segmentów do każdej playlisty multimediów dołącz też kilka potwierdzonych segmentów. Dzięki temu segment będzie mniej narażony na pominięcie, jeśli playlista multimediów zostanie utracona po stronie serwera. Na przykład do każdej playlisty multimediów możesz dołączyć maksymalnie 2 potwierdzone segmenty i maksymalnie 5 widocznych segmentów.

    Pamiętaj, że serwer potwierdza otrzymanie segmentu multimediów, zwracając odpowiedź 200 (OK) lub 202 (Accepted) po przesłaniu tego segmentu. Odpowiedź 202 oznacza, że serwer otrzymał segment przed playlistą identyfikującą ten segment.

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

  • Gdy serwer potwierdzi otrzymanie segmentów multimediów, możesz zwiększyć wartość tagu EXT-X-MEDIA-SEQUENCE, aby playlista multimediów nie stała się zbyt długa. Jeśli na przykład serwer potwierdził już otrzymanie pierwszych 9 segmentów multimediów, następna playlista multimediów może zawierać segmenty multimediów 8, 9 i 10.

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

Przykłady

Poniżej znajdziesz przykład 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
...

Poniższy przykład przedstawia playlistę multimediów wysłaną w trakcie transmisji 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 multimediów

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

  • Nazwy plików
    • Nazwy plików segmentów multimediów w adresie URL muszą mieć rozszerzenie .ts i muszą być zgodne z nazwami plików na playliście.
    • Nazwy plików segmentów multimediów muszą być unikalne w przypadku ponownego uruchomienia kodera i ponownego uruchomienia strumienia.
  • Format
    • Segmenty multimediów muszą być w formacie M2TS i powinny być samoinicjujące.
    • Każdy segment M2TS musi zawierać 1 program MPEG-2.
    • Segment M2TS musi zawierać PAT i PMT, a pierwsze 2 pakiety strumienia transportowego 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ługiwana jest liczba klatek 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.
    • Zalecamy, aby segmenty multimediów trwały od 1 do 4 sekund, jak opisano w sekcji poniżej. Segmenty multimediów 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 przetwarzanie HLS będzie używane w przypadku treści premium, które wymagają wysokiej jakości i wysokiej rozdzielczości. Przetwarzanie HLS zwykle ma większe opóźnienie niż przetwarzanie oparte na RTMP i WebRTC, ponieważ przetwarzanie HLS jest oparte na segmentach.

Zalecamy, aby segmenty multimediów trwały od 1 do 4 sekund, ponieważ mniejsze segmenty multimediów mogą skutkować mniejszym opóźnieniem, ale kosztem wyższego współczynnika ponownego buforowania i niższej wydajności kodowania. Jak wspomnieliśmy w poprzedniej sekcji, segmenty multimediów nie mogą trwać dłużej niż 5 sekund.

Szybkość transmisji bitów

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

Pamiętaj, że HEVC zwykle zapewnia 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

  • Kodery powinny ustawić nagłówek User-Agent w żądaniu HTTP za pomocą tej składni, która zawiera nazwę producenta, nazwę modelu i wersję:

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

Napisy

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

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

Kody odpowiedzi HTTP

W sekcjach poniżej znajdziesz wyjaśnienie kodów odpowiedzi, które YouTube zwraca w odpowiedzi na segmenty i playlisty 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 pomyślnie ją obsłużył.

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

202 (Przyjęto)

Odpowiedź HTTP 202 (Przyjęto) oznacza, że serwer YouTube otrzymał segment multimediów przed otrzymaniem playlisty multimediów zawierającej ten segment. Informuje to klienta, że powinien jak najszybciej wysłać playlistę multimediów zawierającą ten segment, aby uniknąć opóźnienia w przetwarzaniu tego segmentu. Pamiętaj, że nie będzie to problem, jeśli koder będzie wysyłać zaktualizowaną playlistę multimediów dla każdego segmentu multimediów.

400 (Nieprawidłowe żądanie)

Odpowiedź HTTP 400 (Nieprawidłowe żądanie) oznacza, ż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 (Brak autoryzacji) oznacza, że parametr cid w podstawowym adresie URL punktu końcowego HLS w YouTube jest uszkodzony lub wygasł. Aby kontynuować, klient powinien zaktualizować parametr cid.

405 (Niedozwolona metoda)

Odpowiedź HTTP 405 (Niedozwolona metoda) oznacza, ż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.