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

Ten dokument wyjaśnia, jak używać protokołu HTTP Live Streaming (HLS) do przesyłać strumieniowo dane na żywo do YouTube za pomocą kodera. Ten dokument jest przeznaczony dla dostawców koderów, którzy chcą dodać do swoich usług obsługę przetwarzania HLS. HLS przetwarzania danych to dobry wybór w przypadku treści premium, które wymagają i wysokiej rozdzielczości przy stosunkowo większych opóźnieniach. Krótkie podsumowanie Porównanie protokołów przetwarzania danych na żywo w YouTube na żywo. Obsługę strumieniowania znajdziesz w artykule Porównanie protokołu przetwarzania transmisji na żywo w YouTube.

Aby przesyłać strumieniowo dane na żywo przez HLS, koder powinien wysłać serię multimediów segmentów playlist i multimediów do punktu końcowego HLS YouTube za pomocą parametru HTTP PUT lub Prośby: POST. Z punktu widzenia kodera: punkt końcowy HLS w YouTube że to pasywny serwer HTTP.

Każdy segment multimediów reprezentuje przez krótką chwilę rzeczywiste treści multimedialne trwało od 1 do 4 sekund. Każda playlista multimediów opisuje, jak ponownie złożyć segmenty multimediów w odpowiedniej kolejności w strumieniu.

Wymagania dotyczące formatu multimediów

Przetwarzanie wideo i audio w YouTube wiąże się z następującymi wymaganiami treść:

  • Obraz i dźwięk muszą być zmusowane w formacie M2TS.
  • Obsługiwane kodeki wideo to H.264 i HEVC.
  • Obsługujemy szybkość do 60 kl./s.
  • Obsługiwana jest tylko zamknięta grupa GOP.
  • Obsługiwany kodek audio to AAC. Obsługiwany jest tylko dźwięk z jedną ścieżką.

Bardziej szczegółowe wymagania znajdziesz w sekcji Segmenty multimediów.

HDR

Filmy High Dynamic Range (HDR) są obsługiwane przez kodek HEVC i mają następujące dodatkowe wymagania:

  • Obsługiwane standardy kolorów to 10-bitowy PQ i HLG o zmiennej luminancji. Więcej szczegółów:
    • Format kolorów musi być 10-bitowy w formacie YUV 4:2:0.
    • Funkcja transferu musi być typu PQ (inaczej SMPTE ST 2084) lub HLG (znanej też jako ARIB STD-B67).
    • Kolory podstawowe muszą być typu Rec. 2020 r.
    • Współczynniki matrycy muszą być Rec. z 2020 r. o zmiennej luminancji.
  • Zarówno próbka o ograniczonym zakresie (lub zakres MPEG), jak i pełny zakres (lub w formacie JPEG) są obsługiwane. Ważne jest, aby ten zakres był ustawiony zgodnie z przykładowy zakres wartości, z którego korzysta treść. Przykładowe wartości o ograniczonym zakresie: zalecane.

Uzyskiwanie adresu URL przetwarzania HLS

Uzyskiwanie adresu URL przetwarzania HLS z interfejsu YouTube API

Aby uzyskać pełny adres URL przetwarzania, kodery mogą skorzystać z funkcji Transmisja na żywo w YouTube API do wstawienia transmisji na żywo z podanymi niżej wartościami właściwości:

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

W odpowiedzi interfejsu API pole cdn.ingestionInfo.ingestionAddress określa podstawowy adres URL przetwarzania i pole cdn.ingestionInfo.backupIngestionAddress określa adres URL przetwarzania kopii zapasowej. Aby dowiedzieć się więcej, zapoznaj się z dokumentacją usługi zasób liveStreams.

Uzyskiwanie adresu URL przetwarzania HLS ze Studia twórców YouTube

W interfejsie internetowym Studia twórców YouTube, gdy twórca kliknie „Utwórz” Transmisja”, YouTube wyświetli „Klucz strumienia”. składające się z znaków alfanumerycznych znaków i łączników. Ten tajny klucz identyfikuje zarówno twórcę, jak i 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ć nadmiarową drugą kopię przetwarzania na ten zapasowy adres URL:

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

Pamiętaj, że kopia zapasowa różni się od podstawowego adresu URL na dwa sposoby: nazwa hosta i parametr copy= uległ zmianie. Przetwarzanie kopii zapasowej musi wysłać inną wartość parametru copy= niż w przypadku przetwarzania podstawowego, którego należy uniknąć który uszkodzi strumień.

Wypełnianie adresu URL przetwarzania HLS

Adresy URL uzyskane za pomocą dowolnej z tych metod są niepełnymi szablonami. każdy kończy się z pustym parametrem zapytania file=. Aby utworzyć końcowy adres URL, koder musi dołącz nazwę pliku playlisty lub segmentu multimediów na końcu adresu URL, w ten sposób wypełniamy parametr file=.

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

  • Koder może utworzyć nazwę pliku playlisty multimediów lub segmentu multimediów na podstawie znaki alfanumeryczne, podkreślenia, ukośniki, łączniki i kropki; Żadne inne znaki nie są obsługiwane.
  • Koder nie może kodować nazwy pliku w adresie URL.
  • Koder może zawierać w nazwach plików komponenty ścieżki względnej lub bezwzględnej, chociaż nigdy 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 polu odpowiadający wpisowi playlisty.

Wymagania protokołu HLS

Playlisty multimediów i segmenty multimediów wysyłane przez koder muszą spełniać wymagania HTTP Live Streaming 2nd Edition Specyfikacja.

Specyfikacja HLS definiuje 2 typy playlist: playlisty multimedialne i reklamy nadrzędne. Playlista. Ponieważ YouTube transkoduje treści przesyłane strumieniowo do różnych rozdzielczości i koder nie musi przesyłać treści z różnymi szybkościami do YouTube Dlatego do przetwarzania HLS YouTube obsługuje tylko playlisty multimediów. i Playlisty główne są ignorowane. (Playlista główna zawiera zestaw wariantów strumienie, z których każdy opisuje inną wersję tych samych treści).

Koder musi:

  • możesz wysyłać tylko jeden zakodowany strumień o najwyższej rozdzielczości, jaką chcesz wyświetlać treści użytkownikom (pojedyncza rozdzielczość i kodek).
  • audio i wideo w trybie mux.
  • używanie protokołu HTTPS i trwałego połączenia dla wszystkich żądań.

W poniższych 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ć. reprezentują ciągły strumień multimedialny, który można dekodować. Playlista multimediów informuje serwera, jakich segmentów multimediów należy się spodziewać i jak należy je poprawnie ułożyć z powrotem.

Wymagania

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

  • Pierwsza playlista multimediów wysłana w związku ze strumieniem musi zaczynać się od numeru sekwencyjnego 0 i numer sekwencyjny muszą zwiększać się monotonicznie.

  • Tag EXT-X-MEDIA-SEQUENCE musi określać numer porządkowy funkcji pierwszy segment multimediów na playliście.

  • Playlista multimediów może zawierać maksymalnie pięć segmentów do umieszczenia. O segment jest zaległy, jeśli serwer go nie otrzymał lub nie potwierdził jego otrzymania.

    Oprócz zaległych segmentów uwzględnij też kilka potwierdzonych segmentów na każdej playliście multimediów. Dzięki temu prawdopodobieństwo, że segment, który ma być pominięty, jeśli po stronie serwera zostanie utracona playlista multimediów. Dla: Na przykład możesz uwzględnić maksymalnie dwa potwierdzone segmenty i maksymalnie pięć segmentów wyróżniających się na każdej playliście multimedialnej.

    Pamiętaj, że serwer potwierdza odbiór segmentu multimediów, zwracając 200 (OK) lub 202 (Accepted) odpowiedź po przesłaniu tego segmentu. O Odpowiedź 202 wskazuje, że serwer odebrał segment przed playlisty identyfikującej dany segment.

  • Wysyłaj zaktualizowaną playlistę dla każdego segmentu multimediów, aby w przypadku utraty playlisty multimediów można szybko odzyskać połączenie.

  • Gdy serwer potwierdza odbiór segmentów multimediów, możesz zwiększać EXT-X-MEDIA-SEQUENCE, by zapobiec zmianie stanu playlisty z multimediami jest za długa. Jeśli na przykład serwer potwierdził już otrzymanie z pierwszych 9 segmentów, kolejna playlista może zawierać ósmą, Dziewiąty i dziesiąty segment multimediów.

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

Przykłady

Na liście poniżej znajdziesz przykładowe pliki, które koder powinien wykonać wyślij:

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 znajduje się w środku strumienia, Tag EXT-X-MEDIA-SEQUENCE ma wartość inną niż zero.

#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ższa lista zawiera wymagania dotyczące segmentów multimediów:

  • Nazwy plików
    • Nazwy plików segmentów multimediów w adresie URL muszą mieć nazwę pliku .ts musi odpowiadać nazwom plików na playliście.
    • Nazwy plików segmentów multimediów muszą być unikalne przy restartach kodera. strumieniowanie zostanie uruchomione ponownie.
  • Format
    • Segmenty multimediów muszą mieć format M2TS i powinny się inicjować samodzielnie.
    • Każdy segment M2TS musi zawierać jeden program MPEG-2.
    • Segment M2TS musi zawierać PAT i PMT, a pierwsze 2 – Pakiety strumienia transportu w segmencie powinny mieć identyfikatory PAT i PMT.
  • Treść
    • Obraz i dźwięk muszą być zmuszone.
    • Obsługiwane kodeki wideo to H.264 i HEVC.
    • Obsługiwany jest tryb HDR z HEVC (zobacz wymagania HDR).
    • Obsługujemy szybkość do 60 kl./s.
    • Obsługiwana jest tylko zamknięta grupa GOP.
    • Obsługiwany kodek audio to AAC, a tylko jedna ścieżka dźwiękowa obsługiwane.
    • Segmenty multimediów powinny mieć czas trwania od 1 do 4 omówiono w następnej sekcji. Segmenty multimediów nie mogą mają czas trwania dłuższy niż 5 sekund.
    • Segmenty multimediów mogą być szyfrowane tylko w warstwie 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 wysokiej rozdzielczości. Pozyskiwanie danych przez HLS ma zwykle większe opóźnienie niż RTMP i przetwarzanie oparte na WebRTC, ponieważ przetwarzanie HLS odbywa się na podstawie segmentów.

Segment multimediów powinien mieć długość 1–4 sekundy, ponieważ mniejsze segmenty multimediów mogą skutkować mniejszym czasem oczekiwania, ale kosztem większej częstotliwości ponownego buforowania i mniejszej wydajności kodowania. Jak wspomnieliśmy w poprzedniej sekcji, Segmenty multimediów nie mogą być dłuższe niż 5 sekund.

Szybkość transmisji bitów

Centrum pomocy YouTube Na środku zawiera wytyczne dotyczące ustawień szybkości transmisji bitów.

Warto zauważyć, że kompresja HEVC pozwala zwykle uzyskać o 25–50% większą kompresję danych przy tym samym jakości obrazu w porównaniu z kodowaniem H.264. W związku z tym wartości szybkości transmisji bitów na dole sugerowanych zakresów można używać z HEVC, aby oszczędzać przepustowość, co jest szczególnie co przydaje się w przypadku treści 4K.

Inne wymagania

  • Kodery powinny ustawiać nagłówek User-Agent w żądaniu HTTP za pomocą metody poniższej składni, która zawiera nazwę producenta, modelu oraz wersja:

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

Napisy

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

  • Wysyłanie napisów za pomocą osobnych żądań HTTP POST. Działa w każdym przypadku Przetwarzanie HLS.
  • Osadzone napisy 608/708 działają podczas przetwarzania HLS, które korzystają z H264 kodeka wideo, ale nie w przypadku przetwarzania wykorzystującego kodek wideo HEVC. Więcej Więcej informacji znajdziesz w artykule Wymagania dotyczące napisów na żywo. w Centrum pomocy YouTube.

Kody odpowiedzi HTTP

W poniższych sekcjach znajdziesz informacje o kodach odpowiedzi zwracanych przez YouTube odpowiedzi na segmenty i playlisty multimediów dostarczone za pomocą HLS.

200 (OK)

W odpowiedzi na żądanie PUT lub POST odpowiedź HTTP 200 (OK) wskazuje, że serwer YouTube odebrał oczekiwaną operację i przetworzył ją .

W odpowiedzi na żądanie DELETE odpowiedź HTTP 200 (OK) oznacza, że serwer YouTube odebrał i zignorował żądanie. Serwer YouTube nie wymaga od klienta USUNIĘCIA żadnego zasobu w strumieniu, co zignoruje Żądania DELETE. Aby osiągnąć lepsze wyniki, YouTube zaleca klientom nie wysyłaj instrukcji DELETE.

202 (Przyjęto)

Odpowiedź HTTP 202 (Zaakceptowana) oznacza, że serwer YouTube odebrał segment multimediów, zanim otrzymasz playlistę multimediów, która zawiera ten segment multimediów. Informuje to klienta, że powinien przesłać playlistę multimediów zawierającą jak najszybciej, aby uniknąć opóźnień w przetwarzaniu segmentację. Nie będzie to stanowiło problemu, jeśli koder wyśle zaktualizowany plik Playlista multimediów dla każdego segmentu multimediów.

400 (Nieprawidłowe żądanie)

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

  • 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 podstawowy adres URL punktu końcowego HLS YouTube jest uszkodzony lub stracił ważność. Klient powinien zaktualizować parametr cid, aby kontynuować.

405 (niedozwolona metoda)

Odpowiedź HTTP 405 (metoda niedozwolona) wskazuje, że żądanie zostało a nie POST, PUT ani DELETE.

500 (wewnętrzny błąd serwera)

Odpowiedź HTTP 500 (wewnętrzny błąd serwera) oznacza, że serwer nie może przetworzyć żądania. W przypadku tego błędu zalecamy ponowne wykonanie żądanie z funkcją wykładniczą czas ponowienia.