Porównanie protokołu przetwarzania transmisji na żywo w YouTube
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
YouTube Live Streaming obsługuje te protokoły przetwarzania dla klientów zewnętrznych:
Protokół przetwarzania |
Zaszyfrowane |
Obsługiwane kodeki wideo |
Komentarz |
RTMP |
Nie |
H.264 |
Odpowiednie do transmitowania na żywo z normalnym, małym lub bardzo małym opóźnieniem. |
RTMPS |
Tak |
H.264 |
Odpowiednie do transmitowania na żywo z normalnym, małym lub bardzo małym opóźnieniem. |
HLS |
Tak |
H.264, H.265 (HEVC) |
Lepszy w przypadku rozdzielczości 4K ze względu na obsługę HEVC. Obsługuje HDR. Nieodpowiednie w przypadku bardzo małych opóźnień. |
DASH |
Tak |
H.264, VP9 |
Lepsza w przypadku rozdzielczości 4K ze względu na obsługę kodeka VP9. Nieodpowiednie w przypadku bardzo małych opóźnień. |
Protokół RTMPS jest powszechnie używanym protokołem do strumieniowej transmisji wideo, który jest akceptowany przez YouTube Live od początku istnienia tej usługi.
Real Time Messaging Protocol Secure (RTMPS) to bezpieczne rozszerzenie protokołu RTMP.
RTMPS chroni zarówno twórców treści, jak i widzów, zapobiegając atakom typu „man-in-the-middle” po stronie przesyłania transmisji na żywo. Dzięki temu wszystkie dane transmisji na żywo twórcy, w tym sygnały wideo, audio i sterujące, są bezpiecznie przesyłane na serwery YouTube, co chroni je przed manipulacją lub przechwyceniem podczas przesyłania.
Protokoły przetwarzania Transmisja na żywo przez HTTP (HLS) i Dynamiczne adaptacyjne strumieniowe przesyłanie danych przez HTTP (DASH) są również szyfrowane, podobnie jak RTMPS. Obsługują też kodeki, których nie obsługują protokoły RTMP i RTMPS. Kodeki wideo nowej generacji, takie jak VP9 i High Efficiency Video Coding (HEVC), mogą zapewnić znacznie lepszą kompresję w porównaniu z H.264, co pozwala użytkownikom przesyłać strumieniowo treści w wyższej jakości przy danej szybkości transmisji lub przesyłać strumieniowo treści w tej samej jakości przy niższej szybkości transmisji, co może zmniejszyć buforowanie. Dlatego przesyłanie strumieniowe HLS lub DASH jest dobrym wyborem w przypadku treści premium, które wymagają wyższej jakości i rozdzielczości, ale przy stosunkowo większym opóźnieniu. Pamiętaj, że przesyłanie w formatach HLS i DASH zwykle powoduje większe opóźnienie niż RTMP, ponieważ HLS i DASH są oparte na segmentach.
O ile nie stwierdzono inaczej, treść tej strony jest objęta licencją Creative Commons – uznanie autorstwa 4.0, a fragmenty kodu są dostępne na licencji Apache 2.0. Szczegółowe informacje na ten temat zawierają zasady dotyczące witryny Google Developers. Java jest zastrzeżonym znakiem towarowym firmy Oracle i jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-08-21 UTC.
[null,null,["Ostatnia aktualizacja: 2025-08-21 UTC."],[[["\u003cp\u003eYouTube Live Streaming supports four ingestion protocols: RTMP, RTMPS, HLS, and DASH, each with different features and capabilities.\u003c/p\u003e\n"],["\u003cp\u003eRTMP and RTMPS are suitable for normal, low, or ultra-low latency live streaming, with RTMPS providing secure, encrypted transmission.\u003c/p\u003e\n"],["\u003cp\u003eHLS and DASH are encrypted, support advanced codecs like HEVC and VP9, and are better suited for 4K and high-resolution streaming but have higher latency.\u003c/p\u003e\n"],["\u003cp\u003eHLS and DASH offer improved video compression compared to H.264, allowing for higher quality at the same bitrate or equivalent quality with a lower bitrate.\u003c/p\u003e\n"]]],["YouTube Live Streaming uses RTMP, RTMPS, HLS, and DASH protocols. RTMP and RTMPS, the latter being a secure extension, support H.264 and are suitable for low-latency streams. Encrypted HLS supports H.264 and H.265 (HEVC), while encrypted DASH supports H.264 and VP9, both being ideal for 4K and HDR content. HLS and DASH are segment based and offer better compression, but are not suitable for ultra-low latency.\n"],null,["# YouTube Live Streaming Ingestion Protocol Comparison\n\nYouTube Live Streaming supports the following ingestion protocols for\nthird-party clients:\n\n| Ingestion Protocol | Encrypted | Video Codecs Supported | Comment |\n|----------------------------------------------------|-----------|------------------------|-----------------------------------------------------------------------------------------------------|\n| RTMP | No | H.264 | Suitable for normal, low, or ultra-low latency live streaming. |\n| [RTMPS](/youtube/v3/live/guides/rtmps-ingestion) | Yes | H.264 | Suitable for normal, low, or ultra-low latency live streaming. |\n| [HLS](/youtube/v3/live/guides/hls-ingestion) | Yes | H.264, H.265 (HEVC) | Better for 4K resolution because of HEVC support. Supports HDR. Not suitable for ultra-low latency. |\n| [DASH](/youtube/v3/live/guides/encoding-with-dash) | Yes | H.264, VP9 | Better for 4K resolution because of VP9 support. Not suitable for ultra-low latency. |\n\n*Real Time Messaging Protocol (RTMPS)* is a widely-used protocol for video\nstreaming that YouTube Live has accepted since the service began.\n\n*Real Time Messaging Protocol Secure (RTMPS)* is a secure extension to RTMP.\nRTMPS benefits both content creators and viewers by preventing man-in-the-middle\nattacks on the ingestion side of livestreams. This ensures that all of a\ncreator's live streaming data---including video, audio, and control signals---is\nsecurely transmitted to YouTube's servers, protecting it from tampering or\ninterception in transit.\n\nThe *HTTP Live Streaming (HLS)* and *Dynamic Adaptive Streaming over HTTP\n(DASH)* ingestion protocols are also encrypted, like RTMPS. They also support\ncodecs that RTMP and RTMPS don't. Next-generation video codecs such as VP9 and\n*High Efficiency Video Coding (HEVC)* can offer much better compression relative\nto H.264, allowing users to either stream with higher quality for a given\nbitrate or stream with the same quality while using a lower bitrate, which could\ndecrease buffering. This makes HLS or DASH ingestion a good choice for premium\ncontent that requires higher quality and higher resolution, albeit at a\nrelatively higher latency. Note that HLS and DASH ingestion typically incur\ngreater latency than RTMP because HLS and DASH are segment-based."]]