RTP / RTCP, TCP, UDP, RTMP, RTSP (2)

Referansedokument RFC2326
Real Time Streaming Protocol (Real Time Streaming Protocol) er en multimediestreamingsprotokoll som brukes til å kontrollere lyd eller video, og tillater samtidig multippel strømmebehovskontroll. Nettverkskommunikasjonsprotokollen som brukes under overføring, ligger ikke innenfor det definerte området. Serversiden Du kan velge å bruke TCP eller UDP til å overføre streaming-innhold. Syntaksen og driften ligner på HTTP 1.1, men tidssynkronisering blir ikke spesielt vektlagt, så den tåler forsinkelser i nettverket. Den nevnte multi-streaming demand-kontrollen (Multicast) som er nevnt tidligere, kan ikke bare redusere nettverksbruken på serversiden, men støtter også flerparts videokonferanser (Videokonferanse). Fordi den fungerer på samme måte som HTTP1.1, er cache-funksjonen "Cache" til proxy-serveren "Proxy" også anvendelig for RTSP, og fordi RTSP har en viderekoblingsfunksjon, kan serveren som tilbyr tjenesten byttes i henhold til den faktiske belastningen situasjon for å unngå overdreven belastning konsentrert på samme server og forårsake forsinkelse.

　　 ble i fellesskap foreslått av Real Networks og Netscape. Protokollen definerer hvordan en-til-mange applikasjoner effektivt kan overføre multimediedata gjennom et IP-nettverk. RTSP gir et utvidbart rammeverk som gjør det mulig å kontrollere og on-demand sanntidsdata, for eksempel lyd og video. Datakilder inkluderer live data og data lagret i klipp.
Formålet med denne protokollen er å kontrollere flere dataoverføringsforbindelser, å gi en måte å velge overføringskanaler, slik som UDP, multicast UDP og TCP, og å gi metoder for å velge en overføringsmekanisme basert på RTP.

RTP overfører lyd- / videodata. Hvis det er SPILL, sender serveren det til klienten. Hvis det er OPPTAK, kan det sendes til serveren av klienten. Hele RTP-protokollen består av to nært beslektede deler: RTP-dataprotokoll og RTP-kontrollprotokoll (dvs. RTCP) ；

　　 RTCP: RTCP inkluderer avsenderrapport og mottakerrapport, brukt til lyd- / videosynkronisering og andre formål, og er en kontrollprotokoll;

　　RTSP-forespørsler inkluderer hovedsakelig DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, OPTIONS, etc., som navnet tilsier, kan det være kjent som en dialog- og kontrollfunksjon;

　　 I løpet av RTSP-samtalen kan SETUP bestemme porten som brukes av RTP / RTCP, PLAY / PAUSE / TEARDOWN kan starte eller stoppe sending av RTP osv .;

　　 TCP, det fulle navnet er Protokoll for overføringskontroll, og det kinesiske navnet er Transmission Control Protocol. Den fungerer på OSI-transportlaget og gir tilkoblingsorienterte pålitelige overføringstjenester.

　　 TCPs arbeid er hovedsakelig å etablere en forbindelse, og deretter motta data fra applikasjonslagsprogrammet og overføre. TCP bruker virtuell kretsforbindelse for å fungere. Før du sender data, må den opprette en forbindelse mellom avsenderen og mottakeren. Etter at dataene er sendt, vil avsenderen vente på at mottakeren gir et bekreftende svar, ellers vil avsenderen tro at disse dataene er tapt, og sende disse dataene på nytt.

RTP er ikke som http og ftp som kan laste ned hele filmfilen helt. Den sender data på nettverket med en fast datahastighet. Klienten ser også filmfilen i denne hastigheten. Etter at filmskjermen er spilt, kan den ikke spilles av gjentatte ganger. , Med mindre du ber om data fra serveren igjen.

　　 Den største forskjellen mellom RTSP og RTP er at: RTSP er en toveis sanntids dataoverføringsprotokoll, som gjør at klienten kan sende forespørsler til serveren, for eksempel avspilling, spoling fremover og omvendt.

　　 Selvfølgelig kan RTSP overføre data basert på RTP, og kan også velge TCP, UDP, multicast UDP og andre kanaler for å sende data, som har god skalerbarhet.
Det er en protokoll for nettverksapplikasjonslag som ligner på http-protokollen.

Sekvensnummer: angir posisjonen til segmentet i sekvensen av segmenter som skal overføres

Bekreftelsesnummer: spesifiserer sekvensnummeret til det vellykkede mottatte segmentet, bekreftelsessekvensnummeret inneholder neste sekvensnummer som slutten som sender bekreftelsen forventer å motta

TCP offset: spesifiserer lengden på segmenthodet. Lengden på seksjonstittelen avhenger av alternativet som er angitt i seksjonsoverskriften

PSH: Indikerer at dataene vil bli sendt til mottaksprosessen så snart som mulig

Vindu: Spesifiser kommandoen om størrelsen på neste segment som avsenderen kan overføre

Sjekksum: Sjekksummen inneholder TCP-segmentoverskriften og datadelen, som brukes til å verifisere påliteligheten til segmentoverskriften og datadelen

Nødsituasjon: indikerer at segmentet inneholder nødinformasjon, og nødpekeren er bare gyldig når URG-flagget er satt til 1.

Alternativer: Den anerkjente segmentstørrelsen, tidsstempelet, slutten av alternativfeltet er spesifisert, og grensealternativet for alternativfeltet er spesifisert

TCP-tilkoblingsetablering: TCP-tilkoblingsprosessen kalles også TCP treveis håndtrykk. Først initierer avsenderverten en synkroniseringsforespørsel (SYN) om å etablere en forbindelse til mottakerverten; mottakerverten svarer med et synkroniserings- / bekreftelsessvar (SYN / ACK) til avsenderen etter å ha mottatt denne forespørselen; avsendervert mottar dette Etter at pakken er sendt en bekreftelse (ACK) til mottakervert, på dette tidspunktet er TCP-forbindelsen vellykket etablert;

TCP-tilkobling: Etter at avsenderverten og destinasjonsverten har opprettet en TCP-forbindelse og fullført dataoverføringen, vil en datapakke med sluttflagget satt til 1 bli sendt for å lukke TCP-forbindelsen og frigjøre bufferområdet som er opptatt av forbindelsen kl. samme tid; TCP reset Setting: TCP lar forbindelsen avbrytes plutselig under overføring, som kalles TCP reset;

TCP-datasortering og bekreftelse: TCP er en pålitelig overføringsprotokoll. Den bruker sekvensnummer og bekreftelsesnumre for å spore datamottaket under overføring;

TCP-retransmissjon: Hvis mottakerverten ikke mottar et bekreftelsessvar på en datapakke i løpet av tidsavbruddsperioden for TCP-overføring, vurderer avsenderen verten datapakken tapt og sender datapakken til mottakeren igjen Side, dette kalles TCP retransmissjon;

Bekreftelse av TCP-forsinkelse: TCP bekrefter ikke alltid data umiddelbart etter å ha mottatt den. Det lar verten sende sin egen bekreftelsesmelding til den andre parten mens den mottar dataene.

TCP-databeskyttelse (sjekksum): TCP er en pålitelig overføringsprotokoll som gir kontrollsumberegning for å realisere integriteten til data under overføring.

　　 UDP-protokoll er forkortelse av engelsk UserDatagramProtocol, det vil si brukerdatagram-protokoll, som hovedsakelig brukes til å støtte nettverksapplikasjoner som trenger å overføre data mellom datamaskiner. Mange klient- / servernettverksapplikasjoner, inkludert nettverksvideokonferansesystemer, må bruke UDP-protokollen. UDP-protokollen har blitt brukt i mange år siden oppstarten. Selv om den opprinnelige glansen har blitt tildekket av noen lignende protokoller, er UDP fremdeles en veldig praktisk og gjennomførbar protokoll for transport av nettverk.

　　 I likhet med den velkjente TCP (Transmission Control Protocol) -protokollen, ligger UDP-protokollen rett på toppen av IP-protokollen (Internet Protocol). I henhold til OSI (Open System Interconnection) referansemodell er UDP og TCP begge transportlagsprotokoller.

　　 Hovedfunksjonen til UDP-protokollen er å komprimere nettverk datatrafikk til form av datagrammer. Et typisk datagram er en overføringsenhet med binære data. De første 8 byte i hvert datagram brukes til å inneholde topptekstinformasjon, og de gjenværende byte brukes til å inneholde spesifikke overføringsdata.

　　 TCP er en punkt-til-punkt-protokoll, som betyr at hver klient trenger å skille klient / server-koblingen, slik at datasending til flere klienter ikke kan realiseres på nettverksnivå. Hvis en datastrøm må overføres til flere klienter samtidig, må serveren overføre en kopi av datastrømmen til hver klient. TCP kan dynamisk justere overføringshastigheten i henhold til nettverksbåndbredden og graden av overbelastning og sende de tapte datapakkene på nytt. Påliteligheten til dataoverføring er sikret, men serverressurser er dyre, og det er vanskelig å sikre sanntidsytelsen til datastrømoverføring når datastrømmen er stor.

UDP er en upålitelig overføringsprotokoll. Ved sendingens slutt er hastigheten UDP overfører data bare begrenset av hastigheten applikasjonen genererer data, datamaskinens kapasitet og overføringsbåndbredde; i mottakersiden setter UDP hvert meldingssegment i kø. Søknaden leser et meldingssegment fra køen hver gang; UDP-protokollen trenger ikke å opprettholde tilkoblingstilstanden, og tror ikke at hver datapakke må nå mottakersiden, så nettverksbelastningen er mindre enn TCP, og overføringshastigheten er raskere enn TCP; Jo mer overbelastet nettverket, jo flere datapakker går tapt.

　　 Hovedforskjellen mellom UDP og TCP-protokollen er hvordan man oppnår pålitelig overføring av informasjon. TCP-protokollen inneholder en spesiell leveransegarantimekanisme. Når datamottakeren mottar informasjonen fra avsenderen, vil den automatisk sende en bekreftelsesmelding til avsenderen. avsenderen vil fortsette å overføre annen informasjon bare etter å ha mottatt bekreftelsesmeldingen. Ellers vil den vente til bekreftelsesmeldingen er mottatt.

　　 Så TCP har mer tid til å opprette en forbindelse enn UDP. Sammenlignet med UDP har TCP høyere sikkerhet og pålitelighet. Størrelsen på TCP-protokolloverføring er ikke begrenset. Når forbindelsen er opprettet, kan begge parter overføre en stor mengde data i et bestemt format, mens UDP er en upålitelig protokoll med en størrelsesgrense, som ikke kan overstige 64K hver gang.

　　 Sammenlignet med TCP-protokollen, er en annen forskjell i UDP-protokollen hvordan man mottar flere datagrammer som er uventede. I motsetning til TCP garanterer UDP ikke rekkefølgen for sending og mottak av data.

RTP er over UDP. Selv om UDP ikke er like pålitelig som TCP og ikke kan garantere tjenesten kvalav sanntidstjenester, må RTCP overvåke dataoverføring og tjenestekvalitet i sanntid. Men fordi overføringsforsinkelsen til UDP er lavere enn TCP, kan den imidlertid være veldig kompatibel med video og lyd. God kamp. Derfor, i praktiske anvendelser, brukes RTP / RTCP / UDP for lyd / video media, og TCP brukes for overføring av data og styresignalering.

RTMP-protokollen er en protokoll designet spesielt for effektiv overføring av video, lyd og data. Den realiserer video- og lydoverføring i sanntid ved å opprette en binær TCP-forbindelse eller koble til en HTTP-tunnel.

　　RTMP støtter flere medieprotokoller enn tradisjonelle medieservere. Den støtter dynamisk overføring av flere linjer som kan inneholde lyd-, video- og skriptdata fra serveren til klienten og fra klienten til serveren. RTMP behandler lyd-, video- og skriptdata separat.

　　Lyd- og videodata er bufret separat på serveren. Hvis lyddataene når en viss grense i lydbufferen, vil alle dataene i bufferen bli kastet, og de sist ankomne dataene får lov til å begynne å samle i bufferen og sendes til hver klient. Videodata behandles på en lignende måte, forskjellen er at når en ny nøkkelramme ankommer, blir dataene i bufferen ryddet. Når de gamle rammedataene kastes, og hvis det blir funnet at dataene til klienten er feil, er de nye og gamle rammene montert.

　　RTMP gir forskjellige prioritetsnivåer til data. I sanntidssamtale er lyd det viktigste, video blir lavt prioritert, og manusdata blir prioritert mellom lyd og video.

　　 RTMP-protokollen kan opprette flere datastrømmer, men hver datastrøm kan bare ha én retning. Ved hjelp av RTMP kan du bygge et slikt system, klienten kan samhandle med RTMP-serveren og applikasjonsserveren samtidig, slik at belastningen på serveren kan spres, selv om ytelseskravene til RTMP-serveren i denne forbedrede systemstrukturen er relativt høye.

　　 HTTP-protokoll, det fulle navnet er HyperText Transfer Protocol, og det kinesiske navnet er HyperText Transfer Protocol;

　　MMS-protokoll, det fulle navnet er Microsoft Media Server Protocol, og det kinesiske navnet Microsoft Media Server Protocol;

　　 HLS-protokoll, fullt navn HTTP Live Streaming, er en overføringsprotokoll for strømmemedier basert på HTTP implementert av Apple Inc .;

Hvor langt (lang) senderen dekke?

Rekkevidden avhenger av mange faktorer. Den virkelige avstand er basert på antennen installeres høyde, antenneforsterkning, ved hjelp miljø som bygning og andre hindringer, følsomheten til mottakeren, antennen til mottakeren. Installere antennen mer høy og bruke på landsbygda, avstanden vil mye mer langt.

Eksempel 5W FM-sender bruke i byen og hjemby:

Jeg har en USA kundens bruk 5W FM-sender med GP-antenne i hjembyen, og han teste den med en bil, det dekker 10km (6.21mile).

Jeg teste 5W FM-sender med GP-antenne i hjembyen min, det dekker ca 2km (1.24mile).

Jeg teste 5W FM-sender med GP-antenne i byen Guangzhou, det dekker omtrent bare 300meter (984ft).

Nedenfor er det tilnærmede område av forskjellige kraft FM-sendere. (Utvalget er diameter)

0.1W ~ 5W FM-sender: 100M ~ 1KM

5W ~ 15W FM Ttransmitter: 1KM ~ 3KM

15W ~ 80W FM-sender: 3KM ~ 10KM

80W ~ 500W FM-sender: 10KM ~ 30KM

500W ~ 1000W FM-sender: 30KM ~ 50KM

1KW ~ 2KW FM-sender: 50KM ~ 100KM

2KW ~ 5KW FM-sender: 100KM ~ 150KM

5KW ~ 10KW FM-sender: 150KM ~ 200KM

Hvordan kontakte oss for senderen?

Ring meg + 8618078869184 ELLER
Email meg [e-postbeskyttet]
1.How langt du ønsker å dekke i diameter?
2.How høyt av dere Tower?
3.Where er du fra?
Og vi vil gi deg mer faglige råd.

Om Oss

FMUSER.ORG er et systemintegrasjonsfirma som fokuserer på RF trådløs overføring / studio video lydutstyr / streaming og databehandling. Vi leverer alt fra råd og rådgivning gjennom rackintegrasjon til installasjon, igangkjøring og opplæring.

Vi tilbyr FM-sender, Analog TV-sender, Digital-TV-sender, VHF UHF-sender, Antenner, Koaksialkabelkontakter, STL, On Air-behandling, Broadcast-produkter for Studio, RF Signal Monitoring, RDS-kodere, Lydprosessorer og Remote Site Control Units, IPTV-produkter, Video / Audio Encoder / dekoder, designet for å møte behovene til både store internasjonale kringkastingsnettverk og små private stasjoner.

Vår løsning har FM-radiostasjon / Analog TV-stasjon / Digital TV-stasjon / Audio Video Studio-utstyr / Studio Transmitter Link / Transmitter Telemetry System / Hotel TV System / IPTV Live Broadcasting / Streaming Live Broadcast / Video Conference / CATV Broadcasting system.

Vi bruker avanserte teknologiprodukter til alle systemene, fordi vi vet at høy pålitelighet og høy ytelse er så viktige for systemet og løsningen. Samtidig må vi også sørge for at vårt produktsystem har en svært rimelig pris.

Vi har kunder fra offentlige og kommersielle kringkastingstjenester, telekomoperatører og reguleringsmyndigheter, og vi tilbyr også løsninger og produkter til mange hundre mindre, lokale og lokale kringkastere.

FMUSER.ORG har eksportert mer enn 15 år og har kunder over hele verden. Med 13 års erfaring innen dette feltet har vi et profesjonelt team for å løse kundens alle slags problemer. Vi er dedikert til å levere den ekstremt rimelige prisen på profesjonelle produkter og tjenester. Kontakt Epost : [e-postbeskyttet]

vår fabrikk

Vi har modernisering av fabrikken. Du er velkommen til å besøke vår fabrikk når du kommer til Kina.

I dag er det allerede 1095 kunder hele verden besøkt våre Guangzhou Tianhe kontor. Hvis du kommer til Kina, er du velkommen til å besøke oss.

på Fair

Dette er vår deltakelse i 2012 Global Sources Hong Kong Electronics Fair . Kunder fra hele verden endelig har en sjanse til å komme sammen.

Hvor er Fmuser?

Du kan søke i disse tallene " 23.127460034623816,113.33224654197693 "på google map, så finner du vårt fmuser-kontor.

FMUSER Guangzhou Kontoret ligger i Tianhe District, som er den midten av Canton . Veldig nær til Canton Fair , Guangzhou jernbanestasjon, Xiaobei veien og dashatou , Trenger bare 10 minutter hvis ta TAXI . Velkommen venner over hele verden til å besøke og forhandle.

Kontakt: Sky Blå
Mobil: + 8618078869184
WhatsApp: + 8618078869184
Wechat: + 8618078869184
E-post: [e-postbeskyttet]
QQ: 727926717
Skype: sky198710021
Adresse: No.305 Room Huilan Building No.273 Huanpu Road Guangzhou Kina Postnummer: 510620

Engelsk: Vi aksepterer alle betalinger, for eksempel PayPal, kredittkort, Western Union, Alipay, Money Bookers, T / T, LC, DP, DA, OA, Payoneer. Hvis du har spørsmål, kan du kontakte meg [e-postbeskyttet] eller WhatsApp + 8618078869184

PayPal.  www.paypal.com

Vi anbefaler at du bruker Paypal til å kjøpe våre produkter, er The Paypal en sikker måte å kjøpe på internett.

Hver av våre element liste siden bunnen på toppen har en paypal logo for å betale.

Kredittkort.Hvis du ikke har paypal, men du har kredittkort, kan du også klikke Yellow PayPal knappen for å betale med kredittkort.

-------------------------------------------------- -------------------

Men hvis du ikke har et kredittkort og ikke har en PayPal-konto eller vanskelig å fikk en paypal Kontoinnstillinger, kan du bruke følgende:
Western Union.  www.westernunion.com

Betal med Western Union til meg:

Fornavn / Fornavn: Yingfeng
Etternavn / etternavn / etternavn: Zhang
Fullt navn: Yingfeng Zhang
Land: Kina
By: Guangzhou

-------------------------------------------------- -------------------

T / T.  betal med T / T (wire transfer / telegrafisk overføring / Bank Transfer)
Første BANKINFORMASJON (SELSKAPSKONTO):

SWIFT BIC: BKCHHKHHXXX
Bank navn: BANK OF CHINA (HONG KONG) LIMITED, HONG KONG
Bankadresse: BANKEN AV KINA TOREN, 1 GARDEN ROAD, CENTRAL, HONG KONG
BANK KODE: 012
Kontonavn: FMUSER INTERNATIONAL GROUP LIMITED
Kontonr. : 012-676-2-007855-0

-------------------------------------------------- -------------------
Andre BANKINFORMASJON (SELSKAPSKONTO):
Mottaker: Fmuser International Group Inc.
Kontonummer: 44050158090900000337
Mottakerens bank: China Construction Bank Guangdong Branch
SWIFT-kode: PCBCCNBJGDX
Adresse: NO.553 Tianhe Road, Guangzhou, Guangdong, Tianhe District, Kina
** Merk: Når du overfører penger til bankkontoen vår, vennligst IKKE skriv noe i kommentarområdet, ellers vil vi ikke kunne motta betalingen på grunn av myndighetens policy for internasjonal handel.

* Det vil bli sendt i 1-2 arbeidsdager når betaling klart.

* Vi vil sende den til din paypal adresse. Hvis du ønsker å endre adresse, send riktig adresse og telefonnummer til min e-post [e-postbeskyttet]

* Hvis pakkene er under 2kg, vil vi bli sendt via post luftpost, vil det ta ca 15-25days til hånden din.

Hvis pakken er mer enn 2kg, vil vi sende via EMS, DHL, UPS, Fedex rask ekspresslevering, vil det ta ca 7 ~ 15days til hånden din.

Hvis pakken mer enn 100kg, vil vi sende via DHL eller flyfrakt. Det vil ta om 3 ~ 7days til hånden din.

Alle pakkene er skjema Kina Guangzhou.

* Pakken sendes som en "gave" og avvises så lite som mulig, kjøper trenger ikke betale for "TAX".

* Etter skip, vil vi sende deg en e-post og gi deg sporingsnummeret.

For garanti.
Kontakt oss --- >> Returner varen til oss --- >> Motta og send en ny erstatning.

Navn: Liu Xiaoxia
Adresse: 305Fang HuiLanGe HuangPuDaDaoXi 273Hao TianHeQu Guangzhou Kina.
ZIP: 510620
Telefon: + 8618078869184

Vennligst gå tilbake til denne adressen og skriv din paypal adresse, navn, problem på merknad: