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
Przegląd mediów strumieniowych:
Tak zwane media strumieniowe odnoszą się do formatu mediów odtwarzanych w Internecie za pomocą transmisji strumieniowej.
Media strumieniowe są również znane jako media strumieniowe, co oznacza, że firmy używają serwera dostarczania wideo do wysyłania programów jako pakietów danych do sieci.
Gdy użytkownik zdekompresuje dane za pomocą urządzenia dekompresyjnego, program zostanie wyświetlony jak poprzednio.
Media strumieniowe przesyłają pliki audio, wideo i multimedialne w sieci za pośrednictwem transmisji strumieniowej.
Format pliku multimediów strumieniowych to format multimediów obsługujący transmisję i odtwarzanie strumieniowe.
Tryb transmisji strumieniowej polega na dzieleniu plików multimedialnych, takich jak wideo i audio na pakiety kompresji poprzez specjalny tryb kompresji,
Ciągła transmisja w czasie rzeczywistym z serwera do komputera użytkownika. W systemie przesyłania strumieniowego użytkownicy nie muszą czekać na cały plik, jak w przypadku braku przesyłania strumieniowego
Dopiero po zakończeniu pobierania wszystkich plików możemy zobaczyć zawartość, ale dopiero po kilku sekundach lub kilkudziesięciu sekundach opóźnienia uruchamiania możemy z nich korzystać na komputerze użytkownika
Odpowiedni odtwarzacz odtworzy skompresowane pliki wideo lub audio i inne pliki multimediów strumieniowych, a reszta będzie pobierana do końca odtwarzania.
RTP: (protokół transportu w czasie rzeczywistym)
RTP to protokół warstwy transportowej dla strumieni danych multimedialnych w Internecie. RTP jest używany razem z RTCP i jest oparty na protokole UDP
W przeciwieństwie do HTTP i FTP, RTP może pobrać cały plik wideo. Wysyła dane w sieci ze stałą szybkością transmisji danych. Klient również ogląda plik wideo z tą prędkością. Gdy
Po odtworzeniu filmu i obrazu telewizyjnego nie można go ponownie odtworzyć, chyba że ponownie zażąda danych od serwera.
RTCP: protokół kontroli transportu w czasie rzeczywistym lub RTP (protokół kontrolny lub RTCP)
RTCP jest siostrzanym protokołem RTP
Uwaga: -: Protokół RTP i RTCP są używane razem i jest oparty na protokole UDP (zwykle używany do wideokonferencji)
RTSP: (protokół przesyłania strumieniowego w czasie rzeczywistym)
Protokół sesji mediów strumieniowych w czasie rzeczywistym, SDP (protokół opisu sesji), RTP (protokół transportu w czasie rzeczywistym).
RTSP to protokół strumieniowego przesyłania multimediów używany do sterowania dźwiękiem lub wideo. RTSP zapewnia rozszerzalną strukturę, która umożliwia kontrolę i żądanie danych w czasie rzeczywistym, takich jak audio i wideo.
Dane multimedialne używają protokołu RTP, RTCP.
Ogólnie UDP jest używany jako warstwa transportowa. Nadaje się do scen IPTV.
Źródła danych obejmują dane terenowe i dane przechowywane w plikach. Celem tego protokołu jest sterowanie wieloma połączeniami transmisji danych i zapewnienie sposobu na wybór kanałów transmisji, takich jak UDP, multicast UDP i TCP
Zapewnia również metodę wyboru mechanizmu transmisji opartego na protokole RTP
Protokół sieciowy używany w transmisji nie jest objęty zakresem jego definicji. Serwer może zdecydować się na użycie protokołu TCP lub UDP do przesyłania zawartości strumienia, który jest bardziej odporny na opóźnienia sieciowe
---> Największą różnicą między RTSP i RTP jest to, że RTSP jest dwukierunkowym protokołem transmisji danych w czasie rzeczywistym, który umożliwia klientowi wysyłanie żądań do serwera, takich jak odtwarzanie, przewijanie do przodu, do tyłu i tak dalej. Gdy
Jednak RTSP może przesyłać dane w oparciu o RTP, a także może wybierać TCP, UDP, UDP multiemisji i inne kanały do wysyłania danych, które mają dobrą skalowalność. Jest podobny do protokołu HTTP
Protokół warstwy aplikacji sieciowej
WebRTC:
Protokół mediów strumieniowych jest zaimplementowany w sieci. Kiedy Google po raz pierwszy uruchomił webrtc, giganci albo patrzyli zimno, albo stawiali opór. Do transmisji używany jest protokół RTP.
RTMP (Real Time Messaging Protocol)
Macromedia opracowała zestaw protokołów wideo na żywo, który obecnie należy do Adobe. Podobnie jak HLS, można go zastosować do wideo na żywo i nie zostanie utracony w oparciu o TCP.
// Różnica polega na tym, że RTMP nie może grać w przeglądarce IOS opartej na Flashu, ale jego wydajność w czasie rzeczywistym jest lepsza niż HLS.
Protokół przesyłania wiadomości w czasie rzeczywistym to otwarty protokół opracowany przez firmę Adobe Systems do przesyłania dźwięku, obrazu i danych między odtwarzaczem flash a serwerem
// W kodzie IOS protokół RTMP jest powszechnie używany do przesyłania strumieniowego w trybie push. Do przesyłania strumieniowego można użyć biblioteki librtmp IOS innej firmy. Librtmp hermetyzuje niektóre podstawowe interfejsy API, które użytkownicy mogą wywoływać
Protokół RTMP wymaga również, aby klient i serwer nawiązywały połączenie RTMP za pomocą „uzgadniania”, a następnie przesyłały informacje sterujące o połączeniu. Protokół RTMP sformatuje dane podczas transmisji. Aby osiągnąć lepsze multipleksowanie, podzlecanie i rzetelność informacji, nadawca podzieli wiadomość na fragmenty z identyfikatorem wiadomości, a każdy fragment może być oddzielną wiadomością,
Może być również częścią wiadomości. Odbiorca przywróci fragment do pełnej wiadomości zgodnie z długością danych, identyfikatorem wiadomości i wiadomością zawartą w porcji, tak aby wysyłać i odbierać informacje.
HLS: HTTP Live Streaming (HLS)
Jest to protokół przesyłania multimediów strumieniowych oparty na protokole HTTP zaimplementowany przez firmę Apple Inc,
Może realizować media strumieniowe na żywo i na żądanie, używane głównie w systemie IOS
Aby zapewnić rozwiązania audio i wideo na żywo i na żądanie dla urządzeń z systemem IOS (takich jak iPhone i iPad).
HLS na żądanie jest w zasadzie popularnym segmentowanym HTTP na żądanie. Różnica polega na tym, że jego segmenty są bardzo małe.
W porównaniu z typowymi protokołami przesyłania strumieniowego na żywo, takimi jak protokół RTMP, protokół RTSP, protokół MMS itd., Największą różnicą w transmisji strumieniowej na żywo HLS jest to, że klient transmisji na żywo nie jest pełną wiadomością
Cały strumień danych.
Protokół HLS przechowuje strumień danych na żywo jako ciągłe, krótkoterminowe i długie pliki multimedialne (format mpeg-ts) po stronie serwera, podczas gdy strona klienta w sposób ciągły pobiera i odtwarza te małe pliki,
Ponieważ serwer zawsze generuje nowe małe pliki z najnowszych danych na żywo, tak długo, jak klient nieprzerwanie odtwarza w kolejności pliki otrzymane z serwera, realizowana jest transmisja na żywo.
Można zauważyć, że zasadniczo HLS opiera się na technologii>> na żądanie, aby osiągnąć efekt na żywo <<. Ponieważ dane są przesyłane przez protokół HTTP, nie ma potrzeby rozważania zapory lub serwera proxy
Ponadto długość pliku podzielonego na segmenty jest bardzo krótka, więc klient może szybko wybrać i zmienić współczynnik kodowania, aby dostosować się do odtwarzania w różnych warunkach przepustowości. Jednak tego rodzaju charakterystyka techniczna HLS determinuje jej przyszły rozwój
Ogólnie rzecz biorąc, opóźnienie jest zawsze większe niż w przypadku normalnego protokołu przesyłania strumieniowego na żywo.
// IOS i Android naturalnie obsługują ten protokół, a konfiguracja jest prosta. Możesz użyć tagu wideo bezpośrednio
*** VLS: to rodzaj serwera strumieniowego, który jest specjalnie używany do rozwiązywania różnych problemów związanych ze strumieniowaniem. Ma również pewne cechy VLC. Jako serwer, videolan może wysyłać strumienie HTTP, RTP i RTSP.
Zasadniczo RTSP, RTMP i HTTP mogą być używane do nadawania na żywo i na żądanie, ale generalnie RTSP i RTMP są używane do nadawania na żywo, a protokół HTTP jest używany do nadawania na żądanie. Wybieramy protokół RTMP.
Opóźnienia różnych protokołów i ich przyczyny
RTMP i httpflv: dane tych dwóch protokołów są z grubsza takie same, więc przyczyny opóźnień są podobne. Można powiedzieć, że opóźnienie transmisji strumieniowej TCP na żywo jest bardzo niskie. Dlaczego występuje opóźnienie w RTMP i httpflv? Powodem jest to, że na h264, RTMP i httpflv są przesyłanymi tagami flv. Dane tagu wideo to zwykle dane H264. Dekodowanie H264 ma IBP. Ja to klatka kluczowa, która jest kompletnym obrazem. Najpierw musisz mieć I, aby zdekodować następny BP. Liczba ramek BP może być dowolna, ale liczba ramek I nie może być mniejsza, więc ramki I muszą być w trybie flv. Transmisja Tag jest drugą transmisją (pierwsza to h264spps). Jednak ramki I nie są powszechne w strumieniach H264. Jest tylko jedna ramka I po drugiej. Ten przedział jest powszechnie znany jako GOP. Podczas kodowania GOP jest bardzo krótki. Gdy klient się połączy, serwer znajdzie najnowszą ramkę I w strumieniu z największą szybkością i wyśle dane na żywo z ramki I. Jednak gdy GOP jest bardzo długi, interwał ramek I jest bardzo długi lub zaczekaj, aż następna ramka I zacznie wysyłać dane do nowego połączenia, lub znajdź ostatnią ramkę I w pamięci podręcznej, aby rozpocząć wysyłanie. To jest klucz do opóźnienia protokołów RTMP i HLS. Na głównych platformach CDN nazywa się to „RTMP second on technology”. Zasada polega na dwukrotnym dekodowaniu danych przesyłanych strumieniowo i ustawieniu małego GOP. Ogólnie rzecz biorąc, gdy GOP jest ustawiony na 1 s, niezależnie od opóźnienia łącza transmisji sieci, maksymalne opóźnienie danych wynosi 1 s. Na szczęście ramka I ma opóźnienie 0!
|
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