5, RTSP protokoll
RFC2326 hivatkozási dokumentum
A Real Time Streaming Protocol (Real Time Streaming Protocol) egy multimédiás streaming protokoll, amelyet hang vagy videó vezérléséhez használnak, és lehetővé teszi a többszörös streaming igény vezérlését. Az átvitel során használt hálózati kommunikációs protokoll nem esik a megadott tartományba. Szerveroldal Választhat, hogy a streaming tartalom továbbításához TCP vagy UDP szolgáltatást használ. Szintaxisa és működése hasonló a HTTP 1.1-hez, de az időszinkronizálás nincs különösebben hangsúlyozva, így elviseli a hálózati késéseket. A fent említett többszörös streaming igény-vezérlés (Multicast) nem csak a szerver oldalon képes csökkenteni a hálózat használatát, hanem támogatja a több fél videokonferenciáit (Video Conference) is. Mivel a HTTP1.1-hez hasonlóan működik, a "Proxy" proxykiszolgáló "Cache" gyorsítótár-funkciója szintén alkalmazható az RTSP-re, és mivel az RTSP rendelkezik átirányítási funkcióval, a szolgáltatást nyújtó kiszolgáló a tényleges terhelés szerint kapcsolható elkerülni az ugyanazon szerverre koncentrált túlzott terhelést és késleltetést okozni.
a Real Networks és a Netscape közösen javasolta. A protokoll meghatározza, hogy a sok-sok alkalmazás miként tudja hatékonyan továbbítani a multimédiás adatokat egy IP-hálózaton keresztül. Az RTSP kibővíthető keretrendszert biztosít, amely lehetővé teszi valós idejű adatok, például audio és video vezérlését és igény szerinti lekérését. Az adatforrások tartalmazzák az élő adatokat és a klipekben tárolt adatokat.
Ennek a protokollnak a célja több adatátviteli kapcsolat vezérlése, az átviteli csatornák, például az UDP, a multicast UDP és a TCP kiválasztásának módja, valamint az RTP-n alapuló átviteli mechanizmus kiválasztásának módszerei.
Az RTSP és az RTP kapcsolata
RTP: Valós idejű szállítási protokoll
Az RTP / RTCP a tényleges adatátviteli protokoll;
Az RTP audio / video adatokat továbbít. Ha PLAY, akkor a szerver elküldi az ügyfélnek. Ha RECORD, akkor az ügyfél elküldheti a szervernek. A teljes RTP protokoll két szorosan kapcsolódó részből áll: az RTP adatprotokollból és az RTP vezérlő protokollból (azaz RTCP) ；
RTCP: Az RTCP tartalmazza a küldő jelentést és a vevő jelentést, amelyeket audio / video szinkronizáláshoz és más célokra használnak, és ez egy vezérlő protokoll;
RTSP: Valós idejű streaming protokoll (RTSP)
Az RTSP kérelmek főleg a DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, OPTIONS stb. Részeket tartalmazzák, amint a neve is mutatja, párbeszéd- és vezérlési funkcióként ismerhetjük;
Az RTSP beszélgetés során a SETUP meghatározhatja az RTP / RTCP által használt portot, a PLAY / PAUSE / TEARDOWN elindíthatja vagy leállíthatja az RTP küldését stb .;
6. TCP és UDP protokoll
TCP protokoll
TCP, a teljes név Transfer Control Protocol, a kínai neve pedig Transmission Control Protocol. Az OSI szállítási rétegen működik, és kapcsolatorientált, megbízható átviteli szolgáltatásokat nyújt.
A TCP feladata elsősorban a kapcsolat létrehozása, majd adatok fogadása az alkalmazásréteg programtól és továbbítás. A TCP a virtuális áramkör kapcsolatát használja a munkához. Az adatok elküldése előtt kapcsolatot kell létesítenie a feladó és a vevő között. Az adatok elküldése után a feladó megvárja, amíg a vevő megerősítő választ ad, különben a feladó úgy gondolja, hogy ezek az adatok elvesznek, és újra elküldi ezeket az adatokat.
Az RTP nem olyan, mint a http és az ftp, amelyek képesek a teljes filmfájl teljes letöltésére. Rögzített adatsebességgel küld adatokat a hálózaton. Az ügyfél is ekkora sebességgel nézi a filmfájlt. A film képernyőjének lejátszása után nem lehet újra lejátszani. , Kivéve, ha újra kér adatokat a szervertől.
A legnagyobb különbség az RTSP és az RTP között az, hogy: Az RTSP egy kétirányú, valós idejű adatátviteli protokoll, amely lehetővé teszi az ügyfél számára, hogy kéréseket küldjön a szervernek, például lejátszást, gyors előre és hátramenetet.
Természetesen az RTSP képes az RTP alapján továbbítani az adatokat, és választhat TCP, UDP, multicast UDP és más csatornákat is az adatok küldéséhez, aminek jó skálázhatósága van.
Ez egy hálózati alkalmazásréteg-protokoll, amely hasonló a http-protokollhoz.
Forrás port: a feladó portja meg van adva
Célport: megadja a fogadó vég portszámát
Szekvenciaszám: jelzi a szegmens helyzetét az átvitelre kerülő szegmensek sorozatában
Megerősítés száma: meghatározza a sikeresen vett szegmens sorszámát, a megerősítési sorszám tartalmazza a következő sorszámot, amelyet a megerősítést küldő vég várhatóan megkap
TCP eltolás: meghatározza a szegmens fejlécének hosszát. A szakaszfejléc hossza a szakaszfejléc opciómezőben beállított opciótól függ
Fenntartva: Fenntartott mezőt jelölnek ki későbbi használatra
Jelek: SYN, ACK, PSH, RST, URG, FIN
SYN: szinkronizálást jelent
ACK: megerősítést jelent
PSH: Azt jelzi, hogy az adatokat a lehető leghamarabb elküldik a fogadó folyamatnak
RST: A kapcsolat visszaállítását jelzi
URG: Vészhelyzeti mutatót jelöl
FIN: Azt jelzi, hogy a feladó befejezte az adatátvitelt
Ablak: Adja meg a következő szegmens méretére vonatkozó parancsot, amelyet a küldő továbbíthat
Ellenőrző összeg: Az ellenőrző összeg tartalmazza a TCP szegmens fejlécét és adatrészét, amelyek a szegmens fejlécének és adatrészének megbízhatóságának ellenőrzésére szolgálnak
Vészhelyzet: azt jelzi, hogy a szegmens vészhelyzeti információkat tartalmaz, és a vészmutató csak akkor érvényes, ha az URG jelző értéke 1.
Opciók: A felismert szegmensméret, időbélyeg, az opció mező vége és az opció mező határopciója meg van adva
Hogyan működik a TCP
TCP kapcsolat létrehozása: A TCP kapcsolat létrehozásának folyamatát TCP háromirányú kézfogásnak is nevezik. Először a küldő állomás kezdeményez egy szinkronizálási (SYN) kérést, hogy kapcsolatot létesítsen a vevő gazdagéppel; a vevő gazdagép szinkronizáló / nyugtázó (SYN / ACK) válaszsal válaszol a feladó hosztra, miután megkapta ezt a kérést; ezt a feladó hoszt kapja meg. Miután a csomag nyugtázást (ACK) küldött a vevő hosztnak, ekkor a TCP kapcsolat sikeresen létrejött;
TCP-kapcsolat bezárása: Miután a küldő és a célállomás létrehozta a TCP-kapcsolatot és befejezte az adatátvitelt, egy adatcsomagot küldünk 1-re beállított végzászlóval a TCP-kapcsolat bezárása és a kapcsolat által elfoglalt puffertér felszabadítása céljából. ugyanakkor; TCP reset beállítás: A TCP lehetővé teszi a kapcsolat hirtelen megszakítását az átvitel során, amelyet TCP resetnek hívnak;
TCP adatok rendezése és megerősítése: A TCP megbízható átviteli protokoll. Sorozatszámokat és megerősítő számokat használ az adatátvitel nyomon követésére az átvitel során;
TCP újraküldés: A TCP átvitel során, ha a vevő gazdagép nem kap nyugtázó választ egy adatcsomagra az újraküldési időkorláton belül, a feladó hoszt az elveszett adatcsomagot tekinti, és újra elküldi az adatcsomagot a vevőnek. TCP újraküldésnek hívják;
TCP késleltetés megerősítése: A TCP nem mindig erősíti meg data azonnal, miután megkapta. Lehetővé teszi, hogy az állomás az adatok fogadása közben saját megerősítő üzenetét küldje a másik félnek.
TCP adatvédelem (ellenőrző összeg): A TCP egy megbízható átviteli protokoll, amely ellenőrző összeg kiszámítását biztosítja az adatok integritásának megvalósítása érdekében az átvitel során.
UDP protokoll
Az UDP protokoll az angol UserDatagramProtocol, vagyis felhasználói datagram protokoll rövidítése, amelyet főleg olyan hálózati alkalmazások támogatására használnak, amelyeknek adatokat kell továbbítaniuk a számítógépek között. Számos kliens / szerver hálózati alkalmazásnak, beleértve a hálózati videokonferencia-rendszereket is, használnia kell az UDP protokollt. Az UDP protokollt már évek óta használják a megalakulása óta. Bár kezdeti fényességét néhány hasonló protokoll elhomályosította, az UDP még ma is nagyon praktikus és megvalósítható hálózati szállítási réteg protokoll.
A jól ismert TCP (Transmission Control Protocol) protokollhoz hasonlóan az UDP protokoll is közvetlenül az IP (Internet Protocol) protokoll tetején található. Az OSI (Open System Interconnection) referenciamodell szerint az UDP és a TCP egyaránt szállítási réteg protokoll.
Az UDP protokoll fő funkciója a hálózati adatforgalom tömörítése datagrammákká. Egy tipikus datagram a bináris adatok átviteli egysége. Az egyes datagramok első 8 bájtja tartalmazza a fejléc információkat, a többi bájt pedig specifikus átviteli adatokat tartalmaz.
7. RTP / RTCP, RTMP, TCP, UDP protokoll összehasonlítás
A TCP egy pont-pont protokoll, ami azt jelenti, hogy minden egyes ügyfélnek el kell különítenie a kliens / szerver kapcsolatot, így a több kliens számára történő adatszórás nem valósítható meg hálózati szinten. Ha egy adatfolyamot egyszerre több ügyfélnek kell továbbítani, akkor a kiszolgálónak továbbítania kell az adatfolyam egy példányát minden egyes ügyfélnek. A TCP dinamikusan beállíthatja az átviteli sebességet a hálózati sávszélesség és a torlódás mértéke szerint, és újraküldheti az elveszett adatcsomagokat. Az adatátvitel megbízhatósága biztosított, de a szerver erőforrásai drágák, és nehéz biztosítani az adatfolyam valós idejű teljesítményét, ha az adatfolyam nagy.
Az UDP nem megbízható átviteli protokoll. A küldési végén az UDP adatátvitelének sebességét csak az alkalmazás által generált adatok sebessége, a számítógép kapacitása és az átviteli sávszélesség korlátozza; a fogadó végén az UDP minden üzenetszegmenst sorba állít. Az alkalmazás minden alkalommal kiolvas egy üzenetszegmenst a sorból; az UDP protokollnak nem kell fenntartania a kapcsolati állapotot, és nem gondolja, hogy minden adatcsomagnak el kell érnie a fogadó véget, ezért a hálózati terhelés kisebb, mint a TCP, és az átviteli sebesség nagyobb, mint a TCP; Minél nagyobb a hálózat, annál több adatcsomag veszik el.
Az UDP és a TCP protokoll közötti fő különbség az, hogy miként lehet elérni a megbízható információátvitelt. A TCP protokoll speciális szállítási garancia mechanizmust tartalmaz. Amikor az adatátvevő megkapja az információt a feladótól, automatikusan megerősítő üzenetet küld a feladónak; a feladó csak a megerősítő üzenet kézhezvétele után továbbítja az egyéb információkat. Ellenkező esetben megvárja, amíg meg nem érkezik a megerősítő üzenet.
Tehát a TCP-nek több ideje van a kapcsolat létrehozására, mint az UDP-re. Az UDP-vel összehasonlítva a TCP nagyobb biztonsággal és megbízhatósággal rendelkezik. A TCP protokoll átviteli mérete nincs korlátozva. A kapcsolat létrejötte után mindkét fél nagy mennyiségű adatot továbbíthat egy bizonyos formátumban, míg az UDP megbízhatatlan protokoll, méretkorlátozással, amely nem haladhatja meg a 64K-ot minden alkalommal.
A TCP protokollhoz képest az UDP protokoll másik különbsége az, hogy hogyan lehet több váratlan datagrammot fogadni. A TCP-vel ellentétben az UDP nem garantálja az adatok küldésének és fogadásának sorrendjét.
Az RTP meghaladja az UDP-t. Bár az UDP nem annyira megbízható, mint a TCP, és nem tudja garantálni a szolgáltatás minőségétAz RTCP-nek a valós idejű szolgáltatások jellegének valós idejű figyelemmel kell kísérnie az adatátvitelt és a szolgáltatás minőségét. Mivel azonban az UDP átviteli késleltetése alacsonyabb, mint a TCP, ezért nagyon kompatibilis lehet a videóval és a hanggal. Jó meccs. Ezért a gyakorlati alkalmazásokban az RTP / RTCP / UDP-t használják audio / video adathordozókhoz, a TCP-t pedig az adatok továbbításához és a vezérlő jelzéshez.
Az RTMP protokoll kifejezetten a video, hang és adatok hatékony továbbítására tervezett protokoll. Valós idejű video- és hangátvitelt valósít meg bináris TCP-kapcsolat létrehozásával vagy HTTP-alagút összekapcsolásával.
Az RTMP több médiaprotokollot támogat, mint a hagyományos médiaszerverek. Támogatja több olyan vonal dinamikus továbbítását, amelyek audio-, video- és szkriptadatokat tartalmazhatnak a szerverről az ügyfélre és az ügyfélről a szerverre. Az RTMP külön kezeli az audio, video és szkript adatokat.
A hang- és videóadatokat külön-külön pufferelik a szerveren. Ha a hangadatok eljutnak egy bizonyos határig a hangpufferben, akkor a pufferben lévő összes adatot elvetjük, és a legutóbb érkezett adatoknak megkezdődhet a gyűjtése a pufferben, és minden kliensnek elküldjük őket. A videoadatokat hasonló módon dolgozzák fel, a különbség az, hogy amikor új kulcskeret érkezik, a pufferben lévő adatok törlődnek. A régi keretadatok elvetésekor, ha kiderül, hogy az ügyfél adatai hibásak, az új és a régi kereteket illesztik be.
Az RTMP különböző prioritási szinteket ad az adatoknak. A valós idejű beszélgetések során a hang a legfontosabb, a videónak alacsony a prioritása, a szkriptadatoknak pedig a hang és a videó prioritása.
Az RTMP protokoll több adatfolyamot is létrehozhat, de mindegyik adatfolyamnak csak egy iránya lehet. Az RTMP használatával létre lehet hozni egy ilyen rendszert, az ügyfél egyszerre léphet kapcsolatba az RTMP szerverrel és az alkalmazás szerverrel, így a szerver terhelése szétszórható, bár ebben a továbbfejlesztett rendszerstruktúrában az RTMP szerver teljesítménykövetelményei viszonylag magasak.
8. Egyéb megállapodások
HTTP protokoll, a teljes név HyperText Transfer Protocol, a kínai neve pedig HyperText Transfer Protocol;
MMS protokoll, a teljes név Microsoft Media Server Protocol, a kínai neve pedig Microsoft Media Server Protocol;
A HLS protokoll, teljes név HTTP Live Streaming, egy streaming médiaátviteli protokoll, amely az Apple Inc. által megvalósított HTTP-n alapul;
|
|
|
|
Milyen messze (hosszú) a távadó fedelét?
A hatótávolság számos tényezőtől függ. Az igazi távolságot alapul az antenna telepítéséhez magasság, antennanyereség használva környezetben, mint épület és egyéb akadály, érzékenysége a vevő, antenna a vevő. Telepítése antenna több magas és használata vidéken, a távolság sokkal messzebb.
Példa 5W FM Transmitter használja a városban és a szülővárosa:
Van egy magyar ügyfél használja 5W fm transmitter GP antenna szülővárosában, s kipróbálni egy autót, akkor terjed 10km (6.21mile).
Tesztelem a 5W fm transmitter GP antenna szülővárosomban, ez fedezésére mintegy 2km (1.24mile).
Tesztelem a 5W fm transmitter GP antenna Guangzhou város, akkor terjed csak körülbelül 300meter (984ft).
Az alábbiakban a hozzávetőleges sor különböző teljesítmény FM adó. (A tartomány átmérő)
0.1W ~ 5W FM adó: 100M ~ 1KM
5W ~ 15W FM Ttransmitter: 1KM ~ 3KM
15W ~ 80W FM adó: 3KM ~ 10KM
80W ~ 500W FM adó: 10KM ~ 30KM
500W ~ 1000W FM adó: 30KM ~ 50KM
1KW ~ 2KW FM adó: 50KM ~ 100KM
2KW ~ 5KW FM adó: 100KM ~ 150KM
5KW ~ 10KW FM adó: 150KM ~ 200KM
Hogyan léphet kapcsolatba velünk az adó?
Hívjon + 8618078869184 OR
Küldj e-mailt [e-mail védett]
1.How messze szeretné fedezni átmérőjű?
2.How magas közületek torony?
3.Where vagy?
És akkor kapsz több szakmai tanácsot.
Rólunk
Az FMUSER.ORG egy olyan rendszerintegrációs cég, amely az RF vezeték nélküli átvitelre / stúdió-videó hangberendezésre / streamingre és adatfeldolgozásra összpontosít.
FM adó, analóg TV adó, digitális TV adó, VHF UHF adó, antennák, koaxiális kábelcsatlakozók, STL, levegő feldolgozás, műsorszórási termékek a stúdióhoz, RF jel felügyelet, RDS kódolók, audio processzorok és távoli webhelyvezérlő egységek, IPTV termékek, Video / Audio Encoder / Decoder, úgy tervezték, hogy megfeleljenek mind a nagy nemzetközi műsorszóró hálózatok, mind a kis magánállomások igényeinek.
Megoldásunk FM rádióállomás / analóg tévéállomás / digitális tévéállomás / audio-video stúdió berendezés / stúdió adó-összeköttetés / adó-telemetria rendszer / szálloda TV-rendszer / IPTV élő közvetítés / élő közvetítés / videokonferencia / CATV műsorszóró rendszer.
Az összes rendszerhez fejlett technológiai termékeket használunk, mert tudjuk, hogy a nagy megbízhatóság és a nagy teljesítmény olyan fontos a rendszer és a megoldás szempontjából. Ugyanakkor meg kell győződnünk arról, hogy termékrendszerünk nagyon kedvező áron van.
A közszolgálati és kereskedelmi műsorszolgáltatók, a távközlési szolgáltatók és a szabályozó hatóságok ügyfelei vannak, és megoldásokat és termékeket is kínálunk több száz kisebb, helyi és közösségi műsorszolgáltatónak.
Az FMUSER.ORG több mint 15 éve exportál, és ügyfelei vannak a világ minden tájáról. 13 éves tapasztalattal rendelkezik ezen a területen, van egy profi csapatunk, hogy megoldjuk az ügyfelek mindenféle problémáját. Elkötelezettek vagyunk a professzionális termékek és szolgáltatások rendkívül elfogadható árainak biztosításában. Kapcsolattartó e-mail : [e-mail védett]
a Factory
Nekünk van korszerűsítés a gyár. Szeretettel várjuk, hogy látogassa meg a gyár, ha jön Kínába.
Jelenleg már vannak 1095 ügyfelek világszerte látogatott el Guangzhou Tianhe irodában. Ha jön Kína, szívesen látogasson el hozzánk.
Fair
Ez a mi részvétel 2012 Global Sources Hong Kong Electronics Fair . Az ügyfelek a világ minden tájáról végre van egy esélyt, hogy együtt legyünk.
Hol van Fmuser?
Kereshet ezekben a számokban " 23.127460034623816,113.33224654197693 "a google térképen, akkor megtalálhatja fmuser irodánkat.
FMUSER Guangzhou irodája Tianhe District, amely a központja a Canton . Nagyon közel hoz Canton Fair , Guangzhou vasútállomás, Xiaobei közúti és dashatou , Csak be kell 10 perc ha figyelembe TAXI . Üdvözöljük barátok a világ minden tájáról, hogy látogassa meg, és tárgyaljon.
Kapcsolat: Sky Blue
Mobil: + 8618078869184
WhatsApp: + 8618078869184
Wechat: + 8618078869184
Email: [e-mail védett]
QQ: 727926717
Skype: sky198710021
Cím: No.305 szoba Huilan Building No.273 Huanpu Road Guangzhou Kína Zip: 510620
|
|
|
|
Angol: Minden fizetést elfogadunk, például PayPal, Hitelkártya, Western Union, Alipay, Money Bookers, T / T, LC, DP, DA, OA, Payoneer. Ha bármilyen kérdése van, kérjük, vegye fel velem a kapcsolatot [e-mail védett] vagy a WhatsApp + 8618078869184
-
PayPal.  www.paypal.com
Azt javasoljuk, hogy a Paypal vásárolni a terméket, a Paypal biztonságos módon vásárolni az interneten.
Minden a mi elem lista oldal alján tetején van egy paypal logóra fizetni.
Hitelkártya.Ha nincs paypal, de van, hitelkártya, akkor is kattints a sárga gombra PayPal fizetni a hitelkártya.
-------------------------------------------------- -------------------
De ha nem egy hitelkártya, és nem egy paypal számla, vagy nehezen kapott egy paypal fiókot állíthat, használhatja a következő:
Western Union.  www.westernunion.com
Fizessen Western Union nekem:
Keresztnév / Keresztnév: Yingfeng
Vezetéknév / Vezetéknév / Családnév: Zhang
Teljes név: Yingfeng Zhang
Ország: Kína
Város: Guangzhou
|
-------------------------------------------------- -------------------
T / T. Fizessen T / T (átutalás / banki átutalás / banki átutalás)
Első BANKINFORMÁCIÓ (VÁLLALATI SZÁMLA):
SWIFT BIC: BKCHHKHHXXX
Bank neve: BANK OF CHINA (HONG KONG) LIMITED, HONGKONG
Bank címe: BANK OF CHINA TOWER, 1 GARDEN ÚT, CENTRAL, HONG KONG
BANKKÓD: 012
Számla neve: FMUSER INTERNATIONAL GROUP LIMITED
Számlaszám. : 012-676-2-007855-0
-------------------------------------------------- -------------------
Második BANK-INFORMÁCIÓ (VÁLLALATI SZÁMLA):
Kedvezményezett: Fmuser International Group Inc.
Fiókszám: 44050158090900000337
Kedvezményezett bankja: China Construction Bank Guangdong Branch
SWIFT kód: PCBCCNBJGDX
Cím: NO.553 Tianhe Road, Guangzhou, Guangdong, Tianhe District, Kína
** Megjegyzés: Ha pénzt utal át bankszámlánkra, kérjük, NE írjon semmit a megjegyzés területére, különben a nemzetközi kereskedelemre vonatkozó kormányzati politika miatt nem tudjuk megkapni a befizetést.
|
|
|
|
* Ez lesz elküldve 1-2 munkanap, amikor a fizetési világos.
* Mi elküldjük azt a paypal címét. Ha meg akarjuk változtatni a címet, kérjük, küldje el a megfelelő címet és telefonszámot az email [e-mail védett]
* Ha a csomagok alatt 2kg fogjuk szállítani postai légiposta, akkor körülbelül 15-25days a kezedbe.
Ha ez a csomag több, mint 2kg, akkor a hajó keresztül EMS, DHL, UPS, Fedex gyors expressz szállítás, akkor körülbelül 7 ~ 15days a kezedbe.
Ha a csomag több, mint 100kg küldünk keresztül DHL vagy a légi áruszállítás. Ez körülbelül 3 ~ 7days a kezedbe.
Minden csomag formájában Kína Guangzhou.
* A csomagot "ajándékként" küldjük el, és a lehető legkevesebbet nyilatkozunk, a vevőnek nem kell fizetnie az "adóért".
* Miután a hajó, küldünk Önnek egy e-mailt, és adja meg a nyomon követési számot.
|
|
|
A jótállásért.
Lépjen kapcsolatba velünk --- >> Tegye vissza nekünk a terméket --- >> Fogadás és újabb csere küldése.
Név: Liu Xiaoxia
Cím: 305Fang HuiLanGe HuangPuDaDaoXi 273Hao TianHeQu Guangzhou Kína.
Postai irányítószám: 510620
Telefon: + 8618078869184
Kérjük, térjen vissza erre a címre, és írja meg a paypal címét, nevét, probléma megjegyzés: |
|
