Protocol de transmissió en directe

L’anomenat mitjà de transmissió fa referència al format multimèdia reproduït a Internet mitjançant la transmissió de transmissió.
Els mitjans de transmissió també es coneixen com a mitjans de transmissió, és a dir, que les empreses utilitzen un servidor de lliurament de vídeo per enviar programes a la xarxa com a paquets de dades.
Després que l'usuari descomprimeixi les dades a través del dispositiu de descompressió, el programa es mostrarà com abans.
La transmissió multimèdia transmet arxius d'àudio, vídeo i multimèdia a la xarxa mitjançant streaming.
El format de fitxer multimèdia en temps real és un format multimèdia que admet la transmissió i la reproducció en streaming.
El mode de transmissió en directe consisteix a dividir fitxers multimèdia com ara vídeo i àudio en paquets de compressió mitjançant un mode de compressió especial,
Transmissió contínua i en temps real des del servidor a l'ordinador de l'usuari. Al sistema de reproducció en temps real, els usuaris no han d’esperar a l’arxiu sencer com si no fossin
Només després de completar totes les descàrregues podem veure el contingut, però només després d’uns segons o dotzenes de segons de retard d’inici els podem utilitzar a l’ordinador de l’usuari

El reproductor corresponent reproduirà el vídeo o l'àudio comprimit i altres fitxers multimèdia en streaming, i la resta continuarà baixant fins al final de la reproducció.
RTP: (Protocol de transport en temps real)
RTP és un protocol de capa de transport per al flux de dades multimèdia a Internet. RTP s’utilitza juntament amb RTCP i es basa en el protocol UDP

A diferència de HTTP i FTP, RTP pot descarregar tot el fitxer de vídeo completament. Envia dades a la xarxa a una velocitat de dades fixa. El client també mira el fitxer de vídeo a aquesta velocitat. Quan
Després de reproduir la imatge de la pel·lícula i la televisió, no es podrà reproduir de nou, tret que es tornin a sol·licitar les dades al servidor.
RTCP: protocol de control de transport en temps real o RTP (protocol de control o RTCP)
RTCP és un protocol germà de RTP
Nota: -: el protocol RTP i RTCP s'utilitzen junts i es basa en el protocol UDP (generalment s'utilitza per a videoconferències)
RTSP: (Protocol de transmissió en temps real)
Protocol de sessió multimèdia en temps real, SDP (Session Description Protocol), RTP (Protocol de transport en temps real).
RTSP és un protocol de transmissió multimèdia que s’utilitza per controlar el so o el vídeo. RTSP proporciona un marc extensible, que permet controlar i exigir dades en temps real, com ara àudio i vídeo.
Les dades multimèdia utilitzen protocol RTP, RTCP.
En general, UDP s'utilitza com a capa de transport. Apte per a escenes IPTV.
Les fonts de dades inclouen dades de camp i dades emmagatzemades en clips. L’objectiu d’aquest protocol és controlar diverses connexions de transmissió de dades i proporcionar una manera de seleccionar canals de transmissió, com ara UDP, UDP multidifusió i TCP.

També proporciona un mètode per seleccionar el mecanisme de transmissió basat en RTP
El protocol de xarxa utilitzat en la transmissió no s’emmarca en la seva definició. El servidor pot optar per utilitzar TCP o UDP per transmetre el contingut del flux, que és més tolerant al retard de la xarxa
---> La diferència més gran entre RTSP i RTP és que RTSP és un protocol bidireccional de transmissió de dades en temps real, que permet al client enviar sol·licituds al servidor, com ara la reproducció, l'avanç ràpid, el retrocés, etc. Quan
Tanmateix, RTSP pot transmetre dades basades en RTP i també pot seleccionar TCP, UDP, UDP multidifusió i altres canals per enviar dades, que té una bona escalabilitat. És similar al protocol HTTP

WebRTC:
El protocol de transmissió multimèdia s’implementa a la web. Quan Google va llançar webrtc per primera vegada, els gegants s’ho miraven amb fredor o s’hi resistien. El protocol RTP s’utilitza per a la transmissió.
RTMP (Protocol de missatgeria en temps real)
Macromedia va desenvolupar un conjunt de protocols de vídeo en directe, que ara pertany a Adobe. Igual que HLS, es pot aplicar a vídeo en directe i no es perdrà en funció de TCP.

// La diferència és que RTMP no pot reproduir-se al navegador iOS basat en flash, però el seu rendiment en temps real és millor que HLS.
El protocol de missatgeria en temps real és un protocol obert desenvolupat per Adobe Systems per a la transmissió d’àudio, vídeo i dades entre el reproductor flash i el servidor

// Al codi IOS, RTMP s'utilitza habitualment per transmetre transmissions. Podeu utilitzar la biblioteca de tercers librtmp IOS per impulsar la transmissió. Librtmp encapsula algunes API bàsiques per trucar als usuaris
El protocol RTMP també requereix que el client i el servidor estableixin una connexió RTMP mitjançant un "handshake" i, a continuació, transmeti informació de control sobre la connexió. El protocol RTMP formatarà les dades durant la transmissió. Per tal d’aconseguir una millor equitat de multiplexació, subcontractació i informació, l’emissor dividirà el missatge en trossos amb identificador de missatge, i cada tros pot ser un missatge separat,

També pot formar part del missatge. El receptor restaurarà el fragment a un missatge complet segons la longitud de les dades, l’identificador del missatge i el missatge contingut al fragment, per tal d’enviar i rebre informació.

HLS: transmissió en directe HTTP (HLS)
És un protocol de transport de mitjans de transmissió basat en HTTP implementat per Apple Inc,
Pot realitzar transmissions en directe i a la carta, utilitzades principalment en el sistema IOS
Proporcionar solucions d’àudio i vídeo en directe i sota demanda per a dispositius iOS (com ara iPhone i iPad).
HLS sota demanda és bàsicament un HTTP segmentat comú sota demanda. La diferència és que els seus segments són molt petits.
En comparació amb els protocols de transmissió en directe comuns, com ara el protocol RTMP, el protocol RTSP, el protocol MMS, etc., la diferència més gran de la transmissió en directe HLS és que el que obté el client de transmissió en directe no és un missatge complet

Tot el flux de dades.
El protocol HLS emmagatzema el flux de dades en directe com a fitxers multimèdia continus, a curt termini i llargs (format mpeg-ts) al costat del servidor, mentre que el costat del client baixa i reprodueix contínuament aquests petits fitxers,
Com que el servidor sempre genera fitxers petits nous a partir de les últimes dades en directe, de manera que sempre que el client reprodueixi contínuament els fitxers obtinguts del servidor en ordre, es realitzarà l’emissió en directe.
Es pot comprovar que, bàsicament, HLS es basa en>> tecnologia a la carta per aconseguir <<live. Com que les dades es transmeten a través del protocol HTTP, no cal tenir en compte el tallafoc ni el servidor intermediari
A més, la longitud del fitxer segmentat és molt curta, de manera que el client pot seleccionar i canviar ràpidament la velocitat del codi per adaptar-se a la reproducció en diferents condicions d’amplada de banda. No obstant això, aquest tipus de característiques tècniques de HLS en determinen el desenvolupament futur

En general, el retard sempre és superior al protocol de transmissió en directe normal.
// Tant IOS com Android admeten aquest protocol de manera natural, i la configuració és senzilla. Podeu utilitzar l'etiqueta de vídeo directament
*** VLS: és un tipus de servidor de transmissió, que s'utilitza especialment per resoldre diversos problemes de transmissió. També té algunes característiques de VLC. Com a servidor, videolan pot generar fluxos HTTP, RTP i RTSP.
En principi, RTSP, RTMP i HTTP es poden utilitzar per a transmissions en directe i per demanda, però generalment RTSP i RTMP s’utilitzen per a transmissions en directe i HTTP s’utilitza per a transmissions a demanda. Triem el protocol RTMP.

RTMP i httpflv: les dades d’aquests dos protocols són aproximadament els mateixos, de manera que els motius del retard són similars. És raonable dir que el retard de la transmissió en directe de TCP és molt baix. Per què hi ha retards a RTMP i httpflv? La raó és que a h264, RTMP i httpflv són etiquetes flv transmeses. Les dades de l'etiqueta de vídeo solen ser dades H264. La descodificació H264 té un IBP. I és el marc clau, que és una imatge completa. Primer heu de tenir un I per descodificar el següent BP. El nombre de fotogrames BP pot ser tan baix com vulgueu, però el nombre de fotogrames I no pot ser inferior, de manera que els fotogrames I han de ser en flv La transmissió de l'etiqueta és la segona transmissió (la primera és h264spps). Tanmateix, els fotogrames I no són habituals als fluxos H264. Només hi ha un fotograma I rere l’altre. Aquest interval es coneix comunament com GOP. Quan es codifica, GOP és molt curt. Quan el client es connecti, el servidor trobarà l'últim fotograma I del flux a la velocitat més ràpida i enviarà dades en directe des del fotograma I. Tanmateix, quan el GOP és molt llarg, l’interval de fotogrames I és molt llarg o espereu que el següent fotograma fotogràfic comenci a enviar dades a la nova connexió o trobeu l’últim fotograma fotogràfic I a la memòria cau per començar a enviar. Aquesta és la clau del retard dels protocols RTMP i HLS. A les principals plataformes CDN, es diu "RTMP segon en tecnologia". El principi és descodificar les dades de transmissió dues vegades i establir un petit GOP. En general, quan GOP s'estableix a 1 s, independentment del retard de l'enllaç de transmissió de xarxa, el retard màxim de dades és d'1 s. Afortunadament, em fot un retard de 0!

A quina distància (llarg) de la coberta del transmissor?

L'abast de transmissió depèn de molts factors. La distància real es basa en la instal·lació de l'antena d'altura, guany d'antena, utilitzant com a mitjà de construcció i altres obstruccions, la sensibilitat del receptor, l'antena del receptor. La instal·lació de l'antena més alta i l'ús en el camp, la distància serà molt més lluny.

Transmissor FM 5W exemple, l'ús a la ciutat i la ciutat natal:

Tinc un client d'ús del transmissor FM amb antena 5W EUA GP a la seva ciutat natal, i ho prova amb un cotxe, és cobrir 10km (6.21mile).

Puc provar el transmissor de FM amb antena GP 5W a la meva ciutat natal, que cobreixen al voltant 2km (1.24mile).

Puc provar el transmissor de FM amb antena 5W metge de capçalera a la ciutat de Guangzhou, que només cobreixen al voltant 300meter (984ft).

A continuació es presenten l'interval aproximat de diferents transmissors de FM de potència. (El rang és de diàmetre)

Transmissor FM 0.1W ~ 5W: 100M ~ 1KM

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

Transmissor FM 15W ~ 80W: 3KM ~ 10KM

Transmissor FM 80W ~ 500W: 10KM ~ 30KM

Transmissor FM 500W ~ 1000W: 30KM ~ 50KM

Transmissor FM 1KW ~ 2KW: 50KM ~ 100KM

Transmissor FM 2KW ~ 5KW: 100KM ~ 150KM

Transmissor FM 5KW ~ 10KW: 150KM ~ 200KM

Com posar-se en contacte amb nosaltres per al transmissor?

Llámame + O 8618078869184
vam enviar un correu electrònic [protegit per correu electrònic]
1.How fins on vol cobrir de diàmetre?
2.How alta que la torre?
3.Where ets?
I li donarem un assessorament més professional.

Sobre Nosaltres

FMUSER.ORG és una empresa d’integració de sistemes centrada en equips de transmissió i transmissió de vídeo sense fil de radiofreqüència / estudi i processament de dades. Oferim tot, des de l'assessorament i la consultoria a través de la integració de bastidors fins a la instal·lació, la posada en servei i la formació.

Oferim transmissor FM, transmissor de televisió analògica, transmissor de televisió digital, transmissor UHF VHF, antenes, connectors de cable coaxial, STL, processament aeri, productes de difusió per a estudi, monitorització de senyals RF, codificadors RDS, processadors d’àudio i unitats de control de llocs remots, Productes IPTV, codificador / decodificador d’àudio / vídeo, dissenyats per satisfer les necessitats de grans xarxes de difusió internacionals i de petites estacions privades.

La nostra solució compta amb estació de ràdio FM / estació de televisió analògica / estació de televisió digital / equip d’estudi d’àudio i vídeo / enllaç de transmissor d’estudi / sistema de telemetría de transmissor / sistema de televisió d’hotel / transmissió en directe IPTV / transmissió en directe de transmissió / conferència de vídeo / sistema de difusió CATV.

Utilitzem productes de tecnologia avançada per a tots els sistemes, ja que sabem que l’alta fiabilitat i l’alt rendiment són tan importants per al sistema i la solució. Al mateix temps, hem d'assegurar-nos que el nostre sistema de productes té un preu molt raonable.

Tenim clients de radiodifusors públics i comercials, operadors de telecomunicacions i autoritats reguladores, i també oferim solucions i productes a molts centenars d’emissores locals, petites i comunitàries.

FMUSER.ORG porta exportant més de 15 anys i té clients a tot el món. Amb 13 anys d’experiència en aquest camp, comptem amb un equip professional per resoldre tot tipus de problemes del client. Ens dediquem a subministrar els preus extremadament raonables de productes i serveis professionals. Correu electrònic de contacte : [protegit per correu electrònic]

la nostra fàbrica

Tenim modernització de la fàbrica. Que són benvinguts a visitar la nostra fàbrica quan s'arriba a la Xina.

En l'actualitat, ja hi ha clients 1095 a tot el món van visitar la nostra oficina Guangzhou Tianhe. Si vostè ve a la Xina, que són benvinguts a visitar-nos.

a la Fira

Aquesta és la nostra participació en 2012 Global Sources Hong Kong Electronics Fair . Els clients de tot el món finalment tenir l'oportunitat de reunir-se.

On és Fmuser?

Podeu cercar aquests números " 23.127460034623816,113.33224654197693 "a google map, podreu trobar la nostra oficina fmuser.

FMUSER oficina de Guangzhou es troba al districte de Tianhe, que és el centre del Cantó . molt a prop fins al Fira de Canton , Estació de tren de Guangzhou, Xiaobei carretera i Dashatou , Només cal 10 minuts si pren TAXI . Benvinguts amics de tot el món a visitar i negociar.

Contacte: Blue Sky
Cel·lular: + 8618078869184
WhatsApp: + 8618078869184
Wechat: + 8618078869184
Adreça electrònica: [protegit per correu electrònic]
QQ: 727926717
Skype: sky198710021
Adreça: Sala de No.305 Huilan Edifici No.273 Huanpu carretera Guangzhou, Xina Codi postal: 510620

Anglès: Acceptem tots els pagaments, com PayPal, targeta de crèdit, Western Union, Alipay, Money Bookers, T / T, LC, DP, DA, OA, Payoneer, si teniu cap pregunta, poseu-vos en contacte amb mi [protegit per correu electrònic] o WhatsApp + 8618078869184

PayPal.  www.paypal.com

Recomanem que utilitzi PayPal per comprar els nostres articles, el PayPal és una forma segura per comprar a Internet.

Cada pàgina de la nostra llista d'elements de fons a la part superior tenen un logotip de PayPal per pagar.

Targeta de crèdit.Si no té PayPal, però vostè ha targeta de crèdit, també pot fer clic al botó groc de PayPal per pagar amb la targeta de crèdit.

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

Però si vostè no té una targeta de crèdit i no tenir un compte de PayPal o difícil va aconseguir un accout PayPal, pot utilitzar el següent:
Unió Occidental.  www.westernunion.com

Pagar per Western Union a mi:

Nom i cognoms: Yingfeng
Cognom / Cognom / Nom de família: Zhang
Nom complet: Yingfeng Zhang
País: Xina
Ciutat: Guangzhou

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

T / T.  pagar amb T / T (transferència bancària / transferència telegràfica / transferència bancària)
Primera informació bancària (COMPTE DE L'EMPRESA):

SWIFT BIC: BKCHHKHHXXX
Nom del banc: BANK OF CHINA (HONG KONG) LIMITED, HONG KONG
Adreça bancària: BANC DE LA TORRE DE XINA, 1 GARDEN ROAD, CENTRAL, HONG KONG
CÓDIG BANC: 012
Nom del compte: FMUSER INTERNATIONAL GROUP LIMITED
Núm de compte. : 012-676-2-007855-0

-------------------------------------------------- -------------------
Segona informació bancària (COMPTE DE L'EMPRESA):
Beneficiari: Fmuser International Group Inc.
Número de compte: 44050158090900000337
Banc del beneficiari: sucursal del Guangdong de China Construction Bank
Codi SWIFT: PCBCCNBJGDX
Adreça: carretera NO.553 Tianhe, Guangzhou, Guangdong, districte de Tianhe, Xina
** Nota: quan transferiu diners al nostre compte bancari, NO escriviu res a l'àrea de comentaris, en cas contrari no podrem rebre el pagament a causa de la política governamental sobre comerç internacional.

* Aquest document s'enviarà a 1 2-dies de treball quan el pagament és clar.

* Enviarem a la seva adreça de PayPal. Si vostè vol canviar la direcció, si us plau, envieu la vostra direcció correcta i número de telèfon a la vostra adreça [protegit per correu electrònic]

* Si els paquets es troba per sota 2kg, ens enviaran a través de correu aeri, trigarà aproximadament 15-25days a la mà.

Si el paquet és més que 2kg, enviarem a través d'EMS, DHL, UPS, Fedex lliurament ràpid expressa, prendrà al voltant de 7 ~ 15days al seu costat.

Si el paquet de més de 100kg, anem a enviar per DHL o el noli aeri. Es durà a prop 3 ~ 7days al seu costat.

Tots els paquets són la forma xinesa de Guangzhou.

* El paquet s'enviarà com a "regal" i es descomptarà el mínim possible, perquè el comprador no hagi de pagar l'impost.

* Després de la nau, li enviarem un correu electrònic i li donarà el nombre de seguiment.

Per a la garantia.
Poseu-vos en contacte amb nosaltres --- >> Envieu-nos l'article --- >> Rebeu i envieu un altre substitut.

Nom: Liu xiaoxia
Direcció: 305Fang HuiLanGe HuangPuDaDaoXi 273Hao TianHeQu Guangzhou, Xina.
Postal: 510620
Telèfon: + 8618078869184

Si us plau, torni a aquesta adreça i escriure el seu PayPal, nom, adreça problema a la nota: