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. Protokół RTP / RTCP
Protokół RTP
Pełna nazwa RTP to Real-time Transport Protocol (Real-time Transport Protocol).
Jest to standard zaproponowany przez IETF (The Internet Engineering Task Force), a odpowiadający mu dokument RFC to RFC3550 (RFC1889 to wersja nieaktualna). RFC3550 nie tylko definiuje RTP, ale także definiuje powiązany protokół RTCP (Real-time Transport Control Protocol, czyli Real-time Transport Control Protocol). RTP służy do świadczenia kompleksowych usług transmisji w czasie rzeczywistym dla różnych danych multimedialnych, które muszą być przesyłane w czasie rzeczywistym, takich jak głos, obraz i faks w sieci IP. RTP zapewnia informacje o czasie i synchronizację strumienia dla transmisji typu end-to-end w czasie rzeczywistym w Internecie, ale nie gwarantuje jakości usług, którą zapewnia RTCP.
Środowisko aplikacji RTP
(1) Prosta konferencja audio w trybie multiemisji. Komunikacja głosowa jest realizowana za pośrednictwem adresu multiemisji i pary portów. Jeden dla danych audio (RTP), a drugi dla pakietów kontrolnych (RTCP).
(2) Konferencje audio i wideo. Jeśli w konferencji używane są zarówno konferencje audio, jak i wideo, te dwa media będą transmitowane w różnych sesjach RTP, a każda sesja będzie używać innego adresu transmisji (adres IP + port). Jeśli użytkownik korzysta z dwóch sesji w tym samym czasie, pakiet RTCP odpowiadający każdej sesji używa nazwy kanonicznej CNAME (nazwa kanoniczna). Uczestnicy mogą uzyskać skojarzone audio i wideo zgodnie z CNAME w pakiecie RTCP, a następnie zsynchronizować audio i wideo zgodnie z informacją o taktowaniu (protokół czasu sieciowego) w pakiecie RTCP.
(3) Tłumacz i mikser. Translator i mikser są systemami przekaźnikowymi na poziomie RTP. Translatory są używane w obszarach użytkowników, do których nie można dotrzeć bezpośrednio przez multiemisję IP, takich jak zapora ogniowa między nadawcą a odbiorcą. Gdy format kodowania dźwięku, który mogą odbierać uczestnicy, jest inny, na przykład, jeśli uczestnik łączy się z szybką konferencją za pośrednictwem wolnego łącza, używany jest mikser. Przed wejściem do sieci, w której należy zmienić format danych audio, mikser rekonstruuje pakiety audio z jednego źródła lub wielu źródeł, łączy zrekonstruowane wiele plików audio i koduje je z innym kodowaniem audio. Przekaż ten nowy pakiet RTP. Wszystkie pakiety danych z miksera powinny być identyfikowane przez mikser jako ich źródło synchronizacji (SSRC, patrz enkapsulacja RTP), a rozmówca może być potwierdzony przez listę źródeł udziału (tabela CSRC, patrz enkapsulacja RTP).
Protokół RTCP
Protokół kontroli w czasie rzeczywistym (RTCP) i RTP są wspólnie zdefiniowane w RFC 1889 zaproponowanej w 1996 roku. Jest to protokół kontrolny, który współpracuje z RTP. RTCP działa wyłącznie na protokole niskiego poziomu, a protokół niskiego poziomu zapewnia multipleksowanie danych i pakietów kontrolnych. Podczas sesji RTP każdy uczestnik sesji okresowo wysyła pakiety kontrolne RTCP do wszystkich pozostałych uczestników. W przypadku sesji lub emisji RTP zwykle używany jest pojedynczy adres rozgłoszeniowy obejmujący wiele celów. Wszystkie pakiety RTP i RTCP należące do tej sesji używają tego adresu rozgłoszeniowego obejmującego wiele celów. Pakiety RTP i pakiety RTCP można rozróżniać za pomocą różnych numerów portów. .
jest protokołem siostrzanym protokołu RTP (Real Time Transport Protocol). RTCP zapewnia kontrolę poza pasmem dla strumieni mediów RTP. Sam RTCP nie przesyła danych, ale współpracuje z RTP w celu pakowania i wysyłania danych multimedialnych. RTCP okresowo przesyła dane sterujące między uczestnikami sesji strumieniowego przesyłania multimediów. Główną funkcją RTCP jest dostarczanie informacji zwrotnych na temat jakości usług świadczonych przez RTP.
RTCP spełnia następujące cztery funkcje:
(1) Głównie w celu dostarczenia informacji zwrotnej na temat jakości udostępnianych danych. RTCP jest częścią protokołu transmisji RTP i jest powiązany z kontrolą przepływu i przeciążenia innych protokołów transmisji. Informacje zwrotne mają bezpośredni wpływ na adaptacyjną kontrolę kodowania, ale doświadczenie multiemisji IP pokazuje, że otrzymywanie informacji zwrotnych od nadawcy ma kluczowe znaczenie dla diagnozowania błędów transmisji. Wysyłanie i otrzymywanie raportów zwrotnych do wszystkich uczestników umożliwia obserwatorom problemu oszacowanie, czy są to problemy lokalne, czy globalne. Mechanizmy publikowania, takie jak multiemisja IP, umożliwiają grupom, takim jak dostawcy usług sieciowych, otrzymywanie informacji zwrotnych i działanie jako zewnętrzne monitory w celu diagnozowania problemów z siecią. Funkcja sprzężenia zwrotnego jest realizowana przez nadawcę i odbiorcę raportów RTCP.
(2) RTCP przenosi identyfikację trwałej warstwy transportowej źródła RTP zwaną nazwą kanoniczną (CNAME). Jeśli zostanie znaleziony konflikt lub program zostanie uruchomiony ponownie, ponieważ tożsamość SSRC może zostać zmieniona, odbiorca potrzebuje CNAME do śledzenia uczestnika. Odbiornik potrzebuje również CNAME, aby skontaktować się z kilkoma strumieniami danych podanymi w odpowiednim połączeniu RTP.
(3) Pierwsze dwie funkcje wymagają od wszystkich uczestników wysyłania pakietów RTCP. Dlatego, aby RTP rozszerzył się do ilości na dużą skalę, szybkość musi być kontrolowana. Pozwól każdemu uczestnikowi wysłać pakiety kontrolne innym uczestnikom, co zwiększy liczbę niezależnych uczestników obserwacji. Ta liczba jest używana do obliczania szybkości wysyłania pakietów.
(4) Opcjonalną funkcją jest przesyłanie minimalnych informacji o sterowaniu połączeniem, takich jak identyfikacja uczestników. Najprawdopodobniej jest używany w połączeniach „luźnej kontroli”, w których uczestnicy mogą swobodnie wchodzić lub wychodzić bez kontroli elementu członkowskiego lub koordynacji parametrów. RTCP działa jako wygodny kanał dla wszystkich uczestników, ale nie musi obsługiwać wszystkich wymagań dotyczących komunikacji sterującej aplikacji.
Gdy protokół RTP jest używany w multiemisji IP, pierwsze trzy funkcje są niezbędne i zalecane we wszystkich sytuacjach. Projektanci aplikacji RTP muszą unikać stosowania mechanizmów, które działają tylko w trybie unicast, co spowoduje brak możliwości skalowania.
2. Związek między RTP / RTCP i innymi protokołami
Diagram architektury mediów strumieniowych
Związek między protokołem RTP a innymi protokołami
RTP, TCP i UDP to protokoły warstwy transportowej; Można również uznać, że RTP znajduje się między warstwą aplikacji a warstwą transportową
Jak widać na rysunku, RTP jest podzielony na warstwę transportową, która jest zbudowana na UDP. Podobnie jak protokół UDP, w celu realizacji funkcji transmisji w czasie rzeczywistym, RTP ma również ustaloną formę enkapsulacji. RTP jest używany do dostarczania informacji o czasie i synchronizacji strumienia dla transmisji w czasie rzeczywistym od końca do końca, ale nie gwarantuje jakości usług. Jakość usług zapewnia RTCP.
3. Protokół RTMP
Protokół przesyłania wiadomości w czasie rzeczywistym RTMP (Real Time Messaging Protocol) to otwarty protokół opracowany przez firmę Adobe Systems do przesyłania dźwięku, obrazu i danych między odtwarzaczami Flash a serwerami.
Ma trzy warianty:
1) Protokół w postaci zwykłego tekstu działający na TCP, wykorzystujący port 1935;
2) RTMPT jest zawarty w żądaniu HTTP i może przechodzić przez zaporę;
3) RTMPS jest podobny do RTMPT, ale wykorzystuje połączenie HTTPS;
Protokół RTMP jest używany przez Flash do przesyłania obiektów, wideo i audio. Ten protokół jest oparty na protokole TCP lub protokole odpytywania HTTP;
Protokół RTMP jest jak kontener używany do przechowywania pakietów danych. Dane te mogą być danymi w formacie AMF lub danymi wideo / audio w formacie FLV;
Pojedyncze połączenie może przesyłać wiele strumieni sieciowych przez różne kanały. Wszystkie pakiety w tych kanałach są przesyłane w pakietach o stałym rozmiarze;
|
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