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
Podczas opracowywania oprogramowania do transmisji na żywo możemy napotkać pewne zamieszanie. Podobnie jak w przypadku wyboru protokołów mediów strumieniowych, takich jak HTTP-FLV, WebRTC, RTMP, HLS i innych zastrzeżonych protokołów, który z nich jest bardziej odpowiedni? Którego protokołu można używać na platformie PC? Który protokół działa lepiej na urządzeniach mobilnych? Następnie zacznę od porównania zalet i wad różnych umów.
1. Zalety i wady kilku popularnych protokołów mediów strumieniowych:
RTMP: zastrzeżony protokół opracowany przez firmę Adobe do przesyłania danych audio i wideo między Flash / AIR a serwerem. Jest to również obecnie najczęściej używany protokół transmisji mediów strumieniowych.
Zalety: Opierając się na długim połączeniu TCP, nie ma potrzeby wielokrotnego ustanawiania połączenia, a opóźnienie jest niskie, zwykle tylko 1 ~ 3 s; technologia jest dojrzała, a zaplecze doskonałe.
Wady: Może być używany tylko przez Flash w przeglądarkach na PC i nie może być używany w przeglądarkach mobilnych; ponieważ Flash zaraz opuści scenę, RTMP nie będzie używany do przesyłania strumieniowego w odtwarzaczu internetowym.
HLS: oparty na protokole HTTP sieciowy protokół transmisji multimediów strumieniowych zaproponowany przez firmę Apple. Jego zasada działania polega na krojeniu transmisji, która tnie strumień na żywo na niezliczone części. Gdy użytkownik ogląda wideo, klient może za każdym razem pobrać tylko część.
Zalety: Oparty na protokole HTTP, łatwiejszy dostęp do CDN, rzadko blokowany przez zapory ogniowe i jest wyposażony w adaptację do wielu szybkości transmisji; jako protokół zaproponowany przez Apple, ma duże zalety pod macOS / iOS, a także jest dostarczany z obsługą Androida; można powiedzieć, że ten protokół jest odpowiedni dla urządzeń mobilnych.
Wady: Opóźnienie jest duże, zwykle nie mniejsze niż 10s. Duża liczba plików TS spowoduje obciążenie pamięci masowej serwera i żądań.
HTTP-FLV: Hermetyzuj dane audio i wideo do pliku FLV, a następnie przesyłaj je przez połączenie HTTP. W porównaniu z RTMP zmienił się tylko protokół transmisji. W przypadku odtwarzacza internetowego Flash jest nadal potrzebny do gry, ale pojawienie się pliku „flv.js” nadrobiło tę wadę.
Zalety: małe opóźnienie, ogólny efekt jest bardzo zbliżony do RTMP; w porównaniu z protokołem RTMP może skutecznie unikać wpływu zapór i agentów.
Wady: Charakterystyka transmisji sprawia, że zasoby mediów strumieniowych są buforowane w lokalnym kliencie, co oznacza, że poufność nie jest zbyt dobra; do tej pory nadal nie jest kompatybilny z przeglądarkami iOS.
WebRTC: Oparty na technologii open source Google, protokole do strumieniowego przesyłania multimediów w Internecie.
Zalety: Zarówno RTMP, jak i HLS są protokołami w rękach dużych firm, podczas gdy WebRTC zostało uwzględnione w standardzie W3C; nie ma potrzeby instalowania wtyczek, a obsługiwanych jest coraz więcej przeglądarek.
Wady: dostosowanie przeglądarki lub systemu przez producenta może powodować problemy z użytecznością oraz brak projektu po stronie serwera i planów wdrożenia; jakość transmisji jest trudna do zagwarantowania, a metody optymalizacji są ograniczone; kompatybilność na urządzeniach z Androidem nie jest dobra; ponadto, umowa ta głównie W obliczu sieci Web nie ma wystarczającego wsparcia dla rozwoju natywnego.
2. W rozwoju oprogramowania do transmisji na żywo korzystanie z RTMP po stronie komputera i HLS po stronie mobilnej jest najbezpieczniejsze.
Dlaczego tak mówisz? Opierając się na powyższych zaletach i wadach, przede wszystkim pod względem ich odpowiedniej adaptowalności platformy, a efekt implementacji jest podobny, RTMP i HLS są lepsze niż HTTP-FLV i WebRTC.
Po drugie, z punktu widzenia otoczenia rynkowego, po wielu latach rozwoju i docierania, wielu dużych producentów CDN doskonale wspierało RTMP i HLS. Ten stabilny proces jest wynikiem pracy wielu pracowników zajmujących się obsługą i konserwacją, a CDN nie będzie stabilny. Rentowny system łatwo wprowadza zmiany. Podobnie coraz więcej firm korzysta z RTMP i HLS, co skutkuje silniejszą optymalizacją i kompatybilnością między CDN i RTMP oraz między CDN i HLS. Jest to proces cykliczny i generalnie firmom CDN niełatwo go przerwać. Ponadto w poprzednim artykule nie wspomniałem o protokole RTSP. Efekt tego protokołu jest podobny do efektu RTMP. Technicznie różni się tylko od liczby kanałów zajmowanych na przesyłanych danych, a strumień formatu transmisji jest inny. RTSP może być faktycznie używany do transmisji na żywo. Jednak nadal ze względu na otoczenie rynkowe, RTSP jest obecnie używany głównie w monitorowaniu bezpieczeństwa. Podobnie jak RTMP, stworzył już własny łańcuch zysków.
Powyższe jest wynikiem dyskusji na temat wyboru protokołu mediów strumieniowych podczas tworzenia oprogramowania do transmisji na żywo. Jeśli chodzi o ten problem, jeśli nadal nie rozumiesz, możesz zostawić wiadomość lub znaleźć profesjonalnego programistę w celu uzyskania szczegółowych konsultacji.
|
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