FMUSER Wirless Transmituj wideo i audio łatwiejsze!
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Afrikaans
sq.fmuser.org -> albański
ar.fmuser.org -> arabski
hy.fmuser.org -> Armeński
az.fmuser.org -> Azerbejdżański
eu.fmuser.org -> baskijski
be.fmuser.org -> białoruski
bg.fmuser.org -> bułgarski
ca.fmuser.org -> kataloński
zh-CN.fmuser.org -> chiński (uproszczony)
zh-TW.fmuser.org -> chiński (tradycyjny)
hr.fmuser.org -> chorwacki
cs.fmuser.org -> czeski
da.fmuser.org -> duński
nl.fmuser.org -> holenderski
et.fmuser.org -> estoński
tl.fmuser.org -> filipiński
fi.fmuser.org -> fiński
fr.fmuser.org -> francuski
gl.fmuser.org -> galicyjski
ka.fmuser.org -> gruziński
de.fmuser.org -> niemiecki
el.fmuser.org -> grecki
ht.fmuser.org -> kreolski haitański
iw.fmuser.org -> hebrajski
hi.fmuser.org -> hindi
hu.fmuser.org -> węgierski
is.fmuser.org -> islandzki
id.fmuser.org -> indonezyjski
ga.fmuser.org -> irlandzki
it.fmuser.org -> włoski
ja.fmuser.org -> japoński
ko.fmuser.org -> koreański
lv.fmuser.org -> łotewski
lt.fmuser.org -> litewski
mk.fmuser.org -> macedoński
ms.fmuser.org -> malajski
mt.fmuser.org -> maltański
no.fmuser.org -> norweski
fa.fmuser.org -> perski
pl.fmuser.org -> polski
pt.fmuser.org -> portugalski
ro.fmuser.org -> rumuński
ru.fmuser.org -> rosyjski
sr.fmuser.org -> serbski
sk.fmuser.org -> słowacki
sl.fmuser.org -> słoweński
es.fmuser.org -> hiszpański
sw.fmuser.org -> suahili
sv.fmuser.org -> szwedzki
th.fmuser.org -> Tajski
tr.fmuser.org -> turecki
uk.fmuser.org -> ukraiński
ur.fmuser.org -> Urdu
vi.fmuser.org -> wietnamski
cy.fmuser.org -> walijski
yi.fmuser.org -> jidysz
1. Status quo
W dobie ogólnokrajowych transmisji na żywo każdy może wziąć urządzenie w swoje ręce i transmitować na żywo. Transmisja na żywo zapewnia pracę grupie ludzi i przynosi ogromne korzyści głównym platformom transmisji na żywo. Musi mieć wysoką jakość w obliczu ogromnego rynku. Tylko niedroga technologia transmisji na żywo może wyróżnić się na tle konkurencji i stać się liderem w branży transmisji na żywo. Pięć kluczowych procesów przesyłania strumieniowego wideo na żywo: 1. Nagrywanie 2. Kodowanie 3. Transmisja sieciowa 4. Dekodowanie 5. Odtwarzanie. Każde z tych łączy wpłynie na jakość i czas opóźnienia transmisji na żywo. Poniżej omówimy głównie trzeci punkt optymalizacji opóźnienia.
Obecna technologia transmisji na żywo na ogół wykorzystuje protokoły, takie jak RTMP, HLS, HDL (HTTP-FLV) i RTP. Najpopularniejszym protokołem wśród tych protokołów jest protokół rtmp. Obecnie wiele platform transmisji na żywo w Chinach jest nadal w użyciu, istnieje również HLS. To także bardzo duża zgoda. Zrób krótkie wprowadzenie do wyżej wymienionych umów.
2. Umowa
(1) Protokół RTMP
Jest to umowa patentowa firmy Adobe, która nie jest obsługiwana przez większość zagranicznych sieci CDN. Popularność w kraju jest bardzo wysoka. Jest kilka powodów:
1) Wsparcie oprogramowania open source i bibliotek open source jest stabilne i kompletne. Na przykład oprogramowanie OBS powszechnie używane przez Douyu anchors, bibliotekę librtmp open source i wtyczkę nginx-rtmp po stronie serwera.
2) Szybkość instalacji odtwarzacza jest wysoka. Dopóki przeglądarka obsługuje FlashPlayer, transmisja na żywo RTMP może być bardzo łatwo odtwarzana, a szczegółowy protokół może być zrozumiany przez Google. W porównaniu z innymi protokołami proces uzgadniania jest zbyt skomplikowany, gdy protokół RTMP ustanawia połączenie po raz pierwszy (dolna warstwa jest oparta na TCP, tutaj jest interakcja samego protokołu RTMP), w zależności od różnych warunków sieciowych, będzie przynieść więcej niż 100 ms opóźnienia do pierwszego otwarcia. Transmisje na żywo oparte na protokole RTMP mają zwykle opóźnienie od 2 do 5 sekund.
(2) protokół HTTP-FLV
Oznacza to, że do przesyłania strumieniowego treści multimedialnych należy używać protokołu HTTP. W porównaniu z RTMP protokół HTTP jest prostszy i dobrze znany i nie ma obawy, że zostanie porwany przez patenty Adobe. Opóźnienie zawartości można również osiągnąć przez 2 ~ 5 sekund, a prędkość otwierania jest szybsza, ponieważ sam HTTP nie ma złożonej interakcji ze stanem. Zatem z punktu widzenia opóźnienia HTTP-FLV jest lepszy niż RTMP.
(3) Umowa HLS
HLS to skrót od Http Live Streaming, czyli protokół transmisji mediów strumieniowych oparty na protokole HTTP zaproponowanym przez firmę Apple. HLS ma bardzo dużą zaletę: HTML5 można otwierać i odtwarzać bezpośrednio; Oznacza to, że łącze na żywo może być przekazywane i udostępniane przez WeChat itp. bez instalowania jakiejkolwiek niezależnej aplikacji, tylko przeglądarki, więc jest bardzo popularne. Społecznościowa aplikacja do przesyłania strumieniowego na żywo, można powiedzieć, że HLS jest po prostu potrzebna, przeanalizujmy jej zasady. Do
Podstawową zasadą HLS jest to, że kiedy zbieranie i wypychanie końca wypycha strumień wideo do serwera mediów strumieniowych, serwer buforuje odebrane informacje o strumieniu do nowego pliku ts za każdym razem, gdy jest on buforowany przez pewien czas, a serwer utworzy plik indeksu m3u8, aby zachować indeks najnowszych fragmentów ts. Gdy odtwarzacz odbiera transmisję na żywo, pobiera najnowsze fragmenty pliku wideo ts z pliku indeksu m3u8 do odtworzenia, aby zapewnić, że użytkownik zobaczy nowszą zawartość za każdym razem, gdy się połączy, zdając sobie sprawę z podobnych wrażeń z transmisji na żywo. W porównaniu z typowymi protokołami transmisji na żywo, takimi jak RTMP i RTSP, największą różnicą między HLS jest to, że klient transmisji na żywo nie otrzymuje pełnego strumienia danych, ale ciągły, krótkotrwały plik multimedialny. Pobierz i odtwórz te małe pliki. Teoretyczne minimalne opóźnienie tej metody to czas trwania jednego pliku ts i ogólnie czas trwania 2-3 plików ts. Zasadniczo zaleca się, aby strategia segmentacji HLS obejmowała segment 10-sekundowy
(4) Protokół RTP
RTP to protokół transportu w czasie rzeczywistym, protokół warstwy transportowej do strumieniowego przesyłania danych multimedialnych w Internecie. W rzeczywistych zastosowaniach protokół RTCP (RTP Control Protocol) często musi być używany razem. Można to po prostu zrozumieć, ponieważ RTCP przesyła interaktywną sygnalizację sterującą, a RTP transmituje rzeczywiste dane medialne. Do
RTP ma szeroki zakres zastosowań w nadzorze wideo, wideokonferencjach i telefonii IP, ponieważ ważne doświadczenie w wideokonferencjach i telefonii IP: treści w czasie rzeczywistym.
W porównaniu z powyższymi trzema, a właściwie dwoma protokołami, istnieje ważna różnica między RTP a nimi, że domyślnie do przesyłania danych używany jest protokół UDP, podczas gdy RTMP i HTTP są oparte na transmisji protokołu TCP. Dlaczego UDP może osiągnąć takie efekty w czasie rzeczywistym? Przeszukałem wiele artykułów na temat analizy różnicy między TCP i UDP. Nie będę ich tutaj powtarzał, ale krótko podsumuję:
1) UDP: Pojedynczy datagram, brak konieczności nawiązywania połączenia, prosta, zawodna, utrata pakietów i nieporządek;
2) TCP: przesyłanie strumieniowe, potrzeba ustanowienia połączenia, złożone, niezawodne i uporządkowane. Do
Scena przesyłania strumieniowego audio i wideo w czasie rzeczywistym nie musi być niezawodnie gwarantowana, więc nie ma potrzeby posiadania mechanizmu retransmisji. Oglądanie obrazów i dźwięków w czasie rzeczywistym, utrata niektórych treści podczas drgań sieci, rozmazane i rozmyte ekrany są zupełnie nieważne. TCP spowoduje opóźnienie i brak synchronizacji w celu ponownej transmisji. Jeśli określona treść zostanie ponownie przesłana i dotrze po 1 sekundzie, cała rozmowa zostanie opóźniona o 1 sekundę. Ponieważ sieć drga, opóźnienie wzrośnie do 2 sekund lub 3 sekund, jeśli odtwarzanie klienta nie zostanie przetworzone, poważnie wpłynie to na jakość transmisji na żywo. Do
Podsumowując: przy wyborze protokołu transmisji na żywo, jeśli wybierzesz RTMP lub HTTP-FLV, oznacza to, że występuje opóźnienie treści o 2 ~ 5 sekund, ale gdy opóźnienie jest włączone, HTTP-FLV jest lepszy niż RTMP . HLS ma opóźnienie zawartości wynoszące 5-7 sekund. Wybranie RTP do transmisji na żywo może spowodować opóźnienie transmisji na żywo w ciągu 1 sekundy. Ale o ile wiem, główni producenci CDN nie obsługują transmisji na żywo opartych na RTP, więc obecny główny nurt w kraju to nadal RTMP lub HTTP-FLV, a także pojawia się HLS.
(5) Porównanie HLS i RTMP
1) HLS
① Wady HLS:
Ogólnie rzecz biorąc, opóźnienie transmisji na żywo HLS osiągnie 20-30 sekund, a duże opóźnienie jest nie do przyjęcia w przypadku transmisji na żywo, które wymagają interaktywnego doświadczenia w czasie rzeczywistym.
HLS opiera się na krótkim połączeniu HTTP, HTTP opiera się na TCP, co oznacza, że HLS musi stale nawiązywać połączenie z serwerem. Potrójne uzgadnianie TCP za każdym razem, gdy nawiązywane jest połączenie, powolny proces uruchamiania i cztery fale rąk podczas rozłączania spowodują zużycie.
② Zalety HLS:
Dane są przesyłane za pośrednictwem protokołu HTTP, więc nie ma potrzeby rozważania problemów z zaporą lub serwerem proxy podczas korzystania z HLS.
Korzystając z krótkotrwałych pofragmentowanych plików do odtwarzania, klient może płynnie przełączać szybkość transmisji, aby dostosować się do odtwarzania w różnych warunkach przepustowości.
HLS to protokół przesyłania strumieniowego multimediów wprowadzony przez firmę Apple. Może być naturalnie obsługiwany na platformie iOS. Można go odtwarzać bezpośrednio za pomocą dostarczonego przez system AVPlayera, bez konieczności samodzielnego tworzenia odtwarzacza.
2)RTMP
W porównaniu z HLS, gdy przyjęty jest protokół RTMP, jest to strumień danych z kolekcji i wypychania do serwera mediów strumieniowych, a następnie do końca odtwarzania, więc na serwerze nie będzie plików docelowych. W ten sposób RTMP ma te zalety stosunkowo:
① Opóźnienie jest niewielkie, zwykle 1-3 s.
② W przypadku długiego połączenia TCP nie ma potrzeby wielokrotnego ustanawiania połączenia.
Dlatego większość usług transmisji na żywo w branży wybierze RTMP jako protokół mediów strumieniowych. Zwykle strumień danych jest hermetyzowany do pliku FLV i dostarczany za pośrednictwem protokołu HTTP. Jest jednak kilka problemów, które należy rozwiązać:
① Platforma iOS nie zapewnia odtwarzacza, który natywnie obsługuje RTMP lub HTTP-FLV, co wymaga opracowania odtwarzacza obsługującego powiązane protokoły.
3. optymalizacja opóźnienia HLS
Opóźnienie hls składa się głównie z następujących trzech części:
(1) Czas, przez który koder po stronie serwera i rozdzielacz strumienia generują pliki TS
(2) Czas potrzebny na pobranie pliku TS przez klienta i zwykle wymaga pobrania dwóch plików multimedialnych TS
(3) Dekodowanie klienta i czas odtwarzania
|
Wpisz e-mail, aby otrzymać niespodziankę
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Afrikaans
sq.fmuser.org -> albański
ar.fmuser.org -> arabski
hy.fmuser.org -> Armeński
az.fmuser.org -> Azerbejdżański
eu.fmuser.org -> baskijski
be.fmuser.org -> białoruski
bg.fmuser.org -> bułgarski
ca.fmuser.org -> kataloński
zh-CN.fmuser.org -> chiński (uproszczony)
zh-TW.fmuser.org -> chiński (tradycyjny)
hr.fmuser.org -> chorwacki
cs.fmuser.org -> czeski
da.fmuser.org -> duński
nl.fmuser.org -> holenderski
et.fmuser.org -> estoński
tl.fmuser.org -> filipiński
fi.fmuser.org -> fiński
fr.fmuser.org -> francuski
gl.fmuser.org -> galicyjski
ka.fmuser.org -> gruziński
de.fmuser.org -> niemiecki
el.fmuser.org -> grecki
ht.fmuser.org -> kreolski haitański
iw.fmuser.org -> hebrajski
hi.fmuser.org -> hindi
hu.fmuser.org -> węgierski
is.fmuser.org -> islandzki
id.fmuser.org -> indonezyjski
ga.fmuser.org -> irlandzki
it.fmuser.org -> włoski
ja.fmuser.org -> japoński
ko.fmuser.org -> koreański
lv.fmuser.org -> łotewski
lt.fmuser.org -> litewski
mk.fmuser.org -> macedoński
ms.fmuser.org -> malajski
mt.fmuser.org -> maltański
no.fmuser.org -> norweski
fa.fmuser.org -> perski
pl.fmuser.org -> polski
pt.fmuser.org -> portugalski
ro.fmuser.org -> rumuński
ru.fmuser.org -> rosyjski
sr.fmuser.org -> serbski
sk.fmuser.org -> słowacki
sl.fmuser.org -> słoweński
es.fmuser.org -> hiszpański
sw.fmuser.org -> suahili
sv.fmuser.org -> szwedzki
th.fmuser.org -> Tajski
tr.fmuser.org -> turecki
uk.fmuser.org -> ukraiński
ur.fmuser.org -> Urdu
vi.fmuser.org -> wietnamski
cy.fmuser.org -> walijski
yi.fmuser.org -> jidysz
FMUSER Wirless Transmituj wideo i audio łatwiejsze!
Kontakt
Adres:
Nr 305 Pokój HuiLan Budynek nr 273 Huanpu Road Guangzhou Chiny 510620
Kategorie
Newsletter