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
Niedawno zacząłem kontaktować się z projektem wideo na żywo, podsumowałem również niektóre koncepcje, technologie i rozwiązania związane z wideo na żywo.
Przede wszystkim zapoznaj się z pojęciem wideo na żywo. Kilka popularnych protokołów wideo to: RTMP, http-flv, HLS, RTP / RTCP.
Następnie wyjaśnimy cały proces transmisji na żywo i powiązanych technologii.
1, protokół wideo na żywo
W dziedzinie transmisji na żywo istnieją dwa rodzaje transmisji na żywo: interaktywne transmisje na żywo i nieinteraktywne transmisje na żywo.
Nieinteraktywne transmisje na żywo (takie jak: parada na żywo, transmisje na żywo NBA, transmisje na żywo z Ligi Mistrzów itp.) Nie są wysoce interaktywne, pozwalając na opóźnienie wynoszące 10 sekund lub więcej. Charakteryzuje się stosunkowo niewielką liczbą źródeł i nadaje się do transkodowania wielokanałowego (użytkownicy mogą go oglądać zgodnie z warunkami sieci).
Typowe sceny interaktywnych transmisji na żywo obejmują transmisje na żywo z pokazów, transmisje na żywo z meczów itp. Ze względu na wysokie wymagania dotyczące interakcji między prezenterem a publicznością, te transmisje na żywo muszą być opóźnione w ciągu 5S. Cechy charakterystyczne interaktywnej transmisji na żywo to: więcej źródeł, nieodpowiednie do transkodowania wielokanałowego, serwer pośredniczący tylko jako tranzytowy.
Media transmisji treści na żywo to sieć, a odpowiednie protokoły są potrzebne do przesyłania obrazu lub dźwięku w sieci. Obecnie wspólne protokoły odpowiednie dla scen na żywo są następujące.
1. Protokół RTMP (nieobsługiwany przez HTML 5, obsługiwany przez Flash)
RTMP to protokół przesyłania strumieniowego multimediów, który jest protokołem patentowym firmy Adobe. Oparty na TCP, jest bardzo popularny w Chinach.
Popularny powód: obsługa oprogramowania open source i biblioteki open source jest stabilna i kompletna, a najczęściej używane rozwiązania do przesyłania strumieniowego i przesyłania strumieniowego mogą w zasadzie działać stabilnie. Na przykład: biblioteka open source librtmp push stream, strona usługi ma wtyczkę nginx RTMP, strumień pull ma bibliotekę odtwarzania ijkplayer.
2. Protokół Http-flv (nieobsługiwany przez HTML 5, obsługiwany przez Flash)
Oznacza to użycie protokołu HTTP do strumieniowego przesyłania treści multimedialnych. Protokół HTTP jest prostszy i lepiej znany niż RTMP. Opóźnienie treści może również wynosić 2-5 sekund, a szybkość otwierania jest szybsza, ponieważ sam HTTP nie ma złożonej interakcji ze stanem. Zatem z punktu widzenia opóźnienia http-flv jest lepsze niż RTMP.
3. Protokół HLS (obsługa HTML, obsługa Flash)
Transmisja strumieniowa HTTP na żywo to protokół przesyłania multimediów strumieniowych oparty na protokole HTTP zaproponowanym przez firmę Apple. HLS ma bardzo dużą zaletę: HTML5 można bezpośrednio otwierać i odtwarzać; Oznacza to, że łącze na żywo można udostępniać za pośrednictwem wechat i innych funkcji przekazywania, bez konieczności instalowania jakiejkolwiek niezależnej aplikacji z przeglądarką, więc jest bardzo popularne. Aplikacja społecznościowa na żywo, HLS jest po prostu potrzebna. Adres URL transmisji na żywo oparty na HLS to plik m3u8, który zawiera kilka niedawnych małych plików wideo TS. Opóźnienie tego trybu odtwarzania jest stosunkowo duże (co jest związane z rozmiarem pliku TS) i może osiągnąć opóźnienie 5-7 sekund w tej samej sieci miejskiej.
4. Protokół RTP / RTCP
Protokół transportowy czasu rzeczywistego to protokół warstwy transportowej służący do strumieniowego przesyłania danych multimedialnych w Internecie. RTCP przesyła sygnalizację interaktywnego sterowania, a RTP transmituje rzeczywiste dane medialne.
RTP jest szeroko stosowany w monitoringu wideo, wideokonferencjach i telefonach IP, ponieważ jednym z ważnych doświadczeń związanych z wideokonferencją i telefonami IP jest rozbudowana zawartość w czasie rzeczywistym.
W porównaniu z powyższymi trzema protokołami, jedną ważną różnicą między RTP a nimi jest to, że protokół UDP jest używany do przesyłania danych domyślnie, podczas gdy RTMP i HTTP są oparte na protokole TCP.
Użyj analizy scenariuszy: scena strumienia audio i wideo w czasie rzeczywistym nie wymaga niezawodnej gwarancji, więc nie ma potrzeby posiadania mechanizmu retransmisji. Nie jest ważne, aby widzieć obraz i dźwięk w czasie rzeczywistym, tracić część treści, gdy sieć drga, rozmazać obraz i ekran powitalny. W celu retransmisji TCP spowoduje opóźnienie i asynchroniczność. Jeśli w wyniku retransmisji po jednej sekundzie nadejdzie określona sekcja treści, cała rozmowa zostanie opóźniona o jedną sekundę. Przy fluktuacji sieci opóźnienie wzrośnie do dwóch lub trzech sekund. Jeśli klient nie obsługuje odtwarzania, może to poważnie wpłynąć na jakość transmisji bezpośredniej. Jak zoptymalizować, zostanie wyjaśnione w następnym artykule.
Wniosek: przy wyborze protokołu transmisji na żywo, jeśli wybrano RTMP lub http-flv, oznacza to, że istnieje opóźnienie treści wynoszące 2-5 sekund, ale jeśli chodzi o opóźnienie otwarcia, http-flv jest lepsze niż RTMP . HLS ma opóźnienie zawartości wynoszące 5-7 sekund. Wybranie RTP do transmisji na żywo może opóźnić transmisję na żywo w ciągu 1 sekundy. Jednak, o ile wiemy, główni producenci CDN nie obsługują transmisji na żywo w oparciu o RTP, więc obecnym głównym nurtem krajowym jest RTMP lub http-flv.
2, proces transmisji wideo na żywo
Proces techniczny związany z wideo na żywo to: pozyskiwanie strumienia wideo w czasie rzeczywistym --- kodowanie strumienia wideo --- transmisja strumienia wideo --- dekodowanie strumienia wideo --- odtwarzanie wideo.
1. Idea przechwytywania wideo w czasie rzeczywistym
a) Ustawiając setpreviewcallback w podglądzie fotografowania z aparatu w systemie Android, realizowany jest interfejs onpreviewframe w celu przechwytywania danych każdego strumienia wideo w czasie rzeczywistym.
b) Za pomocą nagrywarki multimediów w systemie Android połącz localsocket w funkcji setoutputfile.
c) Tryb serwera mediów strumieniowych, używając ffmpeg lub getstreamer, aby uzyskać wideo z kamery.
2. Realizacja kodowania kompresji wideo
a) Bez kodowania, oryginalna ramka wideo yuv420sp jest przesyłana bezpośrednio przez gniazdo.
b) JEPG kompresuje oryginalną ramkę wideo yuv420sp do H.264, a następnie przesyła ją.
c) H.264 / avc. Oryginalna ramka wideo yuv420sp jest kompresowana do formatu H.264, a następnie przesyłana. Typowe kodery open source oparte na H264 obejmują JM, x264, t264, hdot264 itp.
d). mpeg4. Skompresuj oryginalną ramkę wideo yuv420sp do MPEG4, a następnie prześlij
3. Idea transmisji wideo
a). transmisja gniazda
b) . Transport HTTP
c). Transmisja RTP / RTSP
d). tryb serwera mediów strumieniowych, taki jak live555 itp
4. Realizacja dekodowania wideo
a). dekoder odpowiadający kodowaniu
5. Idea odtwarzania wideo
a). poprzez podgląd wideo na Androida
b) . przez odtwarzacz multimedialny systemu Android
c). wklej obraz ramki bezpośrednio przez płótno
|
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