Visió general de la transmissió:
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é s’anomenen mitjans de transmissió. Es refereix a les empreses que utilitzen un servidor de lliurament de vídeo per enviar programes com a paquets de dades i lliurar-los a la xarxa.
Després que l'usuari descomprimeixi les dades a través del dispositiu de descompressió, el programa es mostrarà com abans de la transmissió.
La transmissió multimèdia transmet arxius d'àudio, vídeo i multimèdia en forma de transmissió a través de la xarxa.
El format de fitxer multimèdia en temps real és un format multimèdia que admet la reproducció i la transmissió.
El mètode de transmissió és dividir fitxers multimèdia com ara vídeo i àudio en paquets comprimits mitjançant un mètode de compressió especial.
Transmissió contínua i en temps real des del servidor a l'ordinador de l'usuari. En els sistemes que fan servir la transmissió en streaming, els usuaris no han d’esperar a l’arxiu sencer, com la reproducció que no es reprodueix.
El contingut es pot veure després de finalitzar totes les descàrregues, però només es poden utilitzar uns quants segons o desenes de segons de retard d’inici a l’ordinador de l’usuari
El reproductor corresponent reprodueix el vídeo o l'àudio comprimit i altres fitxers multimèdia en streaming i la part restant es continuarà descarregant fins que es completi la reproducció.
1. RTP: (Protocol de transport en temps real)
És un protocol de capa de transport per a la transmissió de dades multimèdia a Internet. El protocol RTP i el protocol de control RTP RTCP s’utilitzen junts,
I es basa en el protocol UDP.
RTP no és com http i ftp, que pot descarregar el fitxer complet de la pel·lícula completament. Envia dades a la xarxa a una velocitat de dades fixa. El client també mira el fitxer de la pel·lícula a aquesta velocitat.
Després de reproduir la pantalla de la pel·lícula, no es pot reproduir repetidament, tret que es tornin a sol·licitar les dades al servidor.
2. RTCP: Protocol de control de transport en temps real o protocol de control RTP o RTCP en resum)
El protocol de control de transmissió en temps real és un protocol germà del protocol de transmissió en temps real (RTP).
Nota: -: El protocol RTP i el protocol de control RTP (RTCP) s'utilitzen junts i es basa en el protocol UDP (normalment s'utilitza per a videoconferències)
3. RTSP: (Protocol de transmissió en temps real)
Protocol de sessió multimèdia en temps real, SDP (protocol de descripció de sessió), RTP (protocol de transport en temps real).
É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 demanar dades en temps real, com ara àudio i vídeo.
Les dades multimèdia utilitzen protocols rtp i rtcp. En general, utilitzeu udp com a capa de transport. Apte per a escenes IPTV. Les fonts de dades inclouen dades en directe i dades emmagatzemades en clips. L’objectiu d’aquest protocol és controlar múltiples connexions de transmissió de dades, proporcionar una manera de seleccionar canals de transmissió, com UDP, UDP multidifusió i TCP, i proporcionar mètodes per seleccionar un mecanisme de transmissió basat en RTP. El protocol de comunicació de xarxa utilitzat durant la transmissió no s’emmarca dins de la seva definició. El servidor pot optar per utilitzar TCP o UDP per transmetre el contingut de transmissió, que és més tolerant als retards 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 operacions de reproducció, avançament ràpid i inversió. Quan
Per descomptat, RTSP pot transmetre dades basades en RTP i també pot triar TCP, UDP, UDP multidifusió i altres canals per enviar dades, que té una bona escalabilitat. És similar al protocol http
Protocol de capa d’aplicacions de xarxa.
4. WebRTC:
El costat web implementa el protocol multimèdia de transmissió. Quan Google va llançar WebRTC per primera vegada, els gegants estaven asseguts al marge o s’hi resistien. Utilitzeu la transmissió del protocol RTP.
5. RTMP (Protocol de missatgeria en temps real)
Ara, Adobe és propietat d’un conjunt de protocols de vídeo en directe desenvolupats per Macromedia. 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 es pot reproduir al navegador iOS basat en flash, però el 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 reproductors Flash i servidors.
// Al codi iOS, RTMP s'utilitza generalment per impulsar el flux. Podeu utilitzar la biblioteca de tercers librtmp-iOS per impulsar el flux. 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 "apretament de mans" i, a continuació, transmetin informació de control a la connexió. El protocol RTMP formatarà les dades durant la transmissió. En la transmissió real, per tal d’aconseguir millor la multiplexació, l’empaquetament i la informació justa, el remitent dividirà el missatge en fragments amb identificador de missatge, cada fragment pot ser un missatge únic,
També pot formar part del missatge. L’extrem de recepció restablirà el fragment a un missatge complet d’acord amb la longitud de les dades contingudes al fragment, la longitud de l’identificador del missatge i la longitud del missatge, de manera que es realitzi l’enviament i recepció d’informació.
6. HLS: transmissió en directe HTTP (HLS)
És un protocol de transmissió de transmissions multimèdia basat en HTTP implementat per Apple Inc., que permet realitzar reproduccions multimèdia en directe i a demanda. S’utilitza principalment al sistema iOS i proporciona 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 d’emissió en directe de mitjans de comunicació habituals, com ara RTMP, RTSP, MMS, etc., la diferència més gran en la transmissió en directe HLS és que el que obté el client de transmissió en directe no és un flux de dades complet.
El protocol HLS emmagatzema el flux de dades en directe com a fitxers multimèdia continus i de curta durada (format MPEG-TS) al costat del servidor i el client baixa i reprodueix contínuament aquests fitxers petits, ja que el costat del servidor sempre actualitzarà l’última transmissió en directe. les dades generen nous fitxers petits, de manera que mentre el client reprodueix contínuament els fitxers obtinguts del servidor en seqüència, es realitza la transmissió en directe. Es pot veure que, bàsicament, es pot considerar que HLS és una forma tècnica de >> a la carta per realitzar retransmissions en directe <<. Com que les dades es transmeten a través del protocol HTTP, no cal tenir en compte els tallafocs ni els proxies.
A més, la durada del fitxer segmentat és molt curta i el client pot seleccionar i canviar ràpidament la velocitat de bits per adaptar-se a la reproducció en diferents condicions d’amplada de banda. Tanmateix, aquesta característica tècnica de HLS determina la seva
El retard sempre serà superior al protocol ordinari de transmissió en directe.
// Tant iOS com Android admeten aquest protocol de manera natural, la configuració és senzilla; només cal que utilitzeu l'etiqueta de vídeo directament
*** VLS: és una mena 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, rtsp.
En principi, RTSP, RTMP i HTTP es poden utilitzar per a la transmissió en directe i la difusió a demanda, però generalment RTSP i RTMP s’utilitzen per a la transmissió en directe i HTTP s’utilitza per a la difusió a demanda. El que vam triar és el protocol RTMP.
Diversos retards en el protocol i les seves raons
rtmp i httpflv: les dades d’aquests dos protocols són aproximadament els mateixos, de manera que els motius del retard són els mateixos. És lògic que la transmissió en directe de tcp hagi de tenir una latència molt baixa. Per què rtmp i httpflv encara tenen latència? La raó és que a h264, rtmp i httpflv són etiquetes flv que es transmeten. Les dades de l'etiqueta de vídeo solen ser dades h264. La descodificació H264 té un IBP. I és un marc clau, que és una imatge completa. Heu de tenir un I abans de descodificar-lo. Els darrers fotogrames BP, BP poden ser tan pocs com vulgueu, però els fotogrames I no poden ser menys, de manera que els fotogrames I s'han de transmetre en segon lloc en la transmissió de l'etiqueta flv (el primer és h264spspps), però els fotogrames I no són presents sovint als fluxos h264, Hi ha un marc I després d'un període de temps. Aquest període de temps es coneix comunament com a GOP. Quan es codifica, el GOP és molt curt. Quan el client es connecti, el servidor trobarà el fotograma I més proper al flux a la velocitat més ràpida i l’enviarà des del fotograma I. Dades en directe, però quan el GOP és molt llarg, l’interval de fotogrames I és molt llarg o espereu que el fotograma I següent comenci a enviar dades a la nova connexió o trobeu el fotograma I més proper al buffer per començar a enviar. la demora del protocol rtmp i hls El punt clau és que a les principals plataformes CDN, es denomina "segona tecnologia d'obertura rtmp". El principi és descodificar les dades push dues vegades i establir un petit gop. En general, gop s’estableix en 1 s. Independentment del retard de l'enllaç de transmissió de xarxa, el retard màxim de dades és d'1 s. Afortunadament, el fotograma I és 0 endarrerit.
|
|
|
|
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: |
|
El nostre altre producte:
