Ta strona została przetłumaczona przez Cloud Translation API.

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

Ten dokument wyjaśnia, jak używać protokołu Transmisja na żywo przez HTTP (HLS), aby przesyłać strumieniowo dane 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 to dobry wybór w przypadku treści premium, które wymagają wysokiej jakości i wysokiej rozdzielczości przy stosunkowo dłuższym czasie oczekiwania. Krótkie porównanie różnych protokołów przetwarzania, które obsługuje YouTube Live Streaming, znajdziesz w artykule Porównanie protokołów przetwarzania YouTube Live Streaming.

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

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

Wymagania dotyczące formatu multimediów

Przetwarzanie HLS w YouTube jest objęte tymi wymaganiami dotyczącymi treści wideo i audio:

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

Więcej szczegółowych wymagań znajdziesz w sekcji Segmenty odbiorcó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 niestabilną luminancją. Więcej szczegółów:
- Format chroma musi być YUV 4:2:0 10-bitowy.
- Funkcja transferu musi być PQ (inaczej SMPTE ST 2084) lub HLG (inaczej ARIB STD-B67).
- Kolory podstawowe muszą być zgodne z standardem Rec. 2020.
- Współczynniki matrycy muszą być zgodne z normą Rec. 2020 o zmiennej luminancji.
Obsługiwane są wartości próbek o ograniczonym zakresie (czyli MPEG) i o pełnym zakresie (czyli JPEG). Ważne, aby zakres był ustawiony zgodnie z zakresem wartości próbki używanym w treściach. Zaleca się stosowanie wartości próby o ograniczonym zakresie.

Uzyskiwanie adresu URL przetwarzania HLS

Pobieranie adresu URL przetwarzania HLS z interfejsu YouTube API

Aby uzyskać pełny adres URL przetwarzania, kodery mogą użyć interfejsu API YouTube do transmisji na żywo, aby wstawić zasób 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 – adres URL zapasowego przetwarzania. Więcej informacji znajdziesz w dokumentacji zasobu liveStreams.

Pobieranie adresu URL przetwarzania HLS z YouTube Studio

W interfejsie internetowym YouTube Studio, gdy twórca kliknie „Utwórz strumień”, YouTube wyświetla „klucz strumienia” składający się z liter, cyfr i łączników. Ten tajny klucz identyfikuje zarówno twórcę, jak i strumień danych przesyłanych do YouTube.

Adres URL HLS możesz utworzyć na podstawie 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 przetwarzania na ten adres URL:

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

Pamiętaj, że adres URL kopii zapasowej różni się od adresu URL głównego w 2 punktach: zmienił się zarówno host, jak i parametr copy=. Przetwarzanie zapasowe musi wysyłać inną wartość parametru copy= niż przetwarzanie główne, aby uniknąć uszkodzenia strumienia.

Wypełnianie adresu URL przetwarzania HLS

Adresy URL uzyskane za pomocą obu metod są niepełnymi 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 do końca adresu URL, uzupełniając w ten sposób parametr file=.

W przypadku wartości parametru file= obowiązują te zasady:

Koder może utworzyć nazwę pliku listy odtwarzania multimediów lub segmentu multimediów z znaków alfanumerycznych, podkreśleń, ukośników, łączników i kropek. Nie są obsługiwane żadne inne znaki.
Koder nie może zakodować nazwy pliku w formacie URL.
Koder może uwzględniać w nazwach plików ścieżki względne lub bezwzględne, ale nie jest to wymagane. Jeśli koder zawiera element ścieżki w nazwie pliku segmentu multimediów, musi on wskazywać tę samą ścieżkę w odpowiednim wpisie playlisty.

Wymagania dotyczące protokołu HLS

Playlisty z multimediami i segmenty multimedialne wysyłane przez koder muszą być zgodne ze specyfikacją HTTP Live Streaming 2nd Edition.

Specyfikacja HLS definiuje 2 typy playlist: playlista z mediami i główna playlista. Ponieważ YouTube konwertuje strumieniowane treści na różne rozdzielczości i bitrate, koder nie musi wysyłać do YouTube treści z różnymi bitrate. W związku z tym YouTube obsługuje tylko playlisty multimedialne do przetwarzania HLS, a playlisty główne są ignorowane. (playlista główna zawiera zestaw strumieni wariantów, z których każdy opisuje inną wersję tej samej treści).

Koder musi:

przesyłać dokładnie 1 kodowany strumień w najwyższej rozdzielczości, którą chcesz udostępniać użytkownikom (jedna rozdzielczość i jeden kodek).
zmuxować dźwięk i obraz.
używać HTTPS i trwałego połączenia w przypadku wszystkich żądań.

W następnych sekcjach znajdziesz bardziej szczegółowe wymagania dotyczące playlist multimediów i segmentów multimediów.

Playlisty multimedialne

Playlista multimediów zawiera listę segmentów multimediów, które można połączyć, aby reprezentowały ciągły, możliwy do dekodowania strumień multimedialny. Lista odtwarzania multimediów informuje serwer, których segmentów multimediów się spodziewać i jak je prawidłowo uporządkować w zrekonstruowanym strumieniu.

Wymagania

Nazwa pliku playlisty multimediów musi kończyć się na .m3u8 lub .m3u.
Pierwsza playlista multimediów wysłana dla strumienia musi zaczynać się od numeru sekwencji 0, a numer sekwencji musi rosnąć monotonicznie.
Tag EXT-X-MEDIA-SEQUENCE musi zawierać numer sekwencyjny pierwszego segmentu multimediów wymienionego w playlistzie.
Playlista z multimediami nie może zawierać więcej niż 5 widocznych segmentów. Segment jest nierozpatrzony, jeśli serwer go nie otrzymał lub nie potwierdził jego otrzymania.

Oprócz nierozpatrzonych segmentów dodaj do każdej playlisty z multimediami kilka uznanych segmentów. Dzięki temu zmniejsza się prawdopodobieństwo pominięcia segmentu, jeśli na serwerze utracisz playlistę multimediów. Na przykład w każdej playlistzie z multimediami możesz uwzględnić maksymalnie 2 zatwierdzone segmenty i maksymalnie 5 niezatwierdzonych 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ą, która go identyfikuje.
Prześlij zaktualizowaną playlistę multimediów dla każdego segmentu multimediów, aby serwer mógł szybko przywrócić playlistę multimediów, jeśli zostanie ona utracona.
Gdy serwer potwierdzi otrzymanie segmentów multimediów, możesz zwiększyć wartość tagu EXT-X-MEDIA-SEQUENCE, aby zapobiec zbyt długiemu czasowi trwania playlisty multimediów. Jeśli na przykład serwer potwierdził już otrzymanie pierwszych 9 segmentów multimediów, następna playlista multimediów 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ład plików, które powinien wysłać koder:

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 playlistę multimediów wysłaną w środku transmisji na żywo. Ponieważ przykład pochodzi z połowy 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 mediów:

Nazwy plików
- Nazwy plików segmentu multimediów w adresie URL muszą mieć rozszerzenie .ts i mieć te same nazwy co pliki w playlistzie.
- Nazwy plików segmentów multimediów muszą być niepowtarzalne w przypadku ponownego uruchamiania i restartów strumienia.
Format
- Segmenty multimediów muszą mieć format 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 strumienia transportowego w segmencie powinny być PAT i PMT.
Treść
- Obraz i dźwięk muszą być zmiksowane.
- Obsługiwane kodeki wideo to H.264 i HEVC.
- Obsługiwana jest technologia HDR z HEVC (patrz wymagania dotyczące HDR).
- Obsługiwane są liczby klatek na sekundę do 60 fps.
- Obsługiwana jest tylko zamknięta grupa GOP.
- Obsługiwany kodek audio to AAC, a obsługiwane są tylko ścieżki audio z jednym dźwiękiem.
- Zalecamy, aby segmenty multimediów miały czas trwania od 1 do 4 sekund (patrz następna sekcja). Segmenty multimediów nie mogą trwać dłużej niż 5 sekund.
- Segmenty multimediów muszą być szyfrowane tylko na poziomie TLS/SSL za pomocą protokołu HTTPS. Inne mechanizmy szyfrowania nie są obsługiwane.

Czas trwania segmentu multimediów

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

Zalecamy, aby czas trwania segmentu multimediów wynosił od 1 do 4 sekund, ponieważ krótsze segmenty multimediów mogą powodować mniejsze opóźnienie, ale za cenę wyższego współczynnika przepełnienia i mniejszej wydajności kodowania. Jak wspomniano w poprzedniej sekcji, segmenty multimediów nie mogą być dłuższe niż 5 sekund.

Szybkość transmisji bitów

Wytyczne dotyczące ustawień szybkości transmisji danych znajdziesz w Centrum pomocy YouTube.

Pamiętaj, że HEVC zapewnia zazwyczaj 25–50% większą kompresję danych przy tej samej jakości wideo niż H.264. Dlatego wartości szybkości transmisji bitów z niższego zakresu sugerowanych wartości można stosować z HEVC, aby oszczędzać przepustowość, co jest szczególnie przydatne w przypadku treś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>
```
Uwaga: te informacje będą używane tylko do debugowania. Nie będzie on używany do podejmowania decyzji dotyczących obsługi strumienia.

Napisy

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

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

Kody odpowiedzi HTTP

W kolejnych sekcjach znajdziesz opisy kodów odpowiedzi, które YouTube zwraca w odpowiedzi na segmenty multimediów i playlisty multimedialne dostarczane za pomocą HLS.

200 (OK)

W odpowiedzi na żądanie PUT lub POST kod HTTP 200 (OK) wskazuje, że serwer YouTube otrzymał oczekiwaną operację i pomyślnie ją przetworzył.

W odpowiedzi na żądanie DELETE kod 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 usuwania. Ze względu na wydajność YouTube zaleca, aby klienci nie wysyłali żądań DELETE.

202 (Przyjęto)

Odpowiedź HTTP 202 (Akceptowana) wskazuje, że serwer YouTube otrzymał Segment multimediów przed otrzymaniem Playlisty multimediów zawierającej ten segment. Informuje on klienta, że powinien jak najszybciej wysłać listę odtwarzania multimediów zawierającą ten segment multimediów, aby uniknąć opóźnienia w jego przetwarzaniu. Pamiętaj, że nie będzie to problemem, jeśli koder wyśle 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 udało się przetworzyć playlisty lub zawiera ona nieobsługiwane tagi

401 (brak uprawnień)

Odpowiedź HTTP 401 (Brak uprawnień) oznacza, że parametr cid w adresie URL bazy danych 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) wskazuje, że żądanie nie było żądaniem POST, PUT ani DELETE.

500 (Błąd wewnętrzny serwera)

Odpowiedź HTTP 500 (Wewnętrzny błąd serwera) wskazuje, że serwer nie był w stanie przetworzyć żądania. W przypadku tego błędu zalecamy ponowne przesłanie żądania z wzrastającym czasem do ponowienia.