Streaming media oversikt:
De såkalte streamingmediene refererer til medieformatet som spilles på Internett ved hjelp av streamingoverføring.
Streaming media er også kjent som streaming media, det betyr at bedrifter bruker en videoleveringsserver for å sende programmer som datapakker til nettverket.
Etter at brukeren dekomprimerer dataene gjennom dekomprimeringsenheten, vises programmet som før.
Streaming media overfører lyd-, video- og multimediafiler i nettverket ved streaming.
Streaming mediefilformat er et medieformat som støtter overføring og avspilling av streaming.
Streaming overføringsmodus er å dele multimediefiler som video og lyd i komprimeringspakker gjennom spesiell komprimeringsmodus,
Kontinuerlig og sanntidsoverføring fra serveren til brukerens datamaskin. I streaming-systemet trenger ikke brukere å vente på hele filen som ikke-streaming
Først etter at alle nedlastningene er fullført, kan vi se innholdet, men bare etter noen få sekunder eller dusinvis av sekunder med oppstartsforsinkelse, kan vi bruke dem på brukerens datamaskin
Den tilhørende spilleren vil spille av komprimert video eller lyd og andre streaming-mediefiler, og resten vil fortsette å laste ned til slutten av avspillingen.
RTP: (Transportprotokoll i sanntid)
RTP er en transportlagsprotokoll for multimedia datastrøm på Internett. RTP brukes sammen med RTCP, og det er basert på UDP-protokoll
I motsetning til HTTP og FTP kan RTP laste ned hele videofilen helt. Den sender data på nettverket med en fast datahastighet. Klienten ser også på videofilen i denne hastigheten. Når
Etter at film- og TV-bildet er spilt, kan det ikke spilles av igjen, med mindre data blir bedt om fra serveren igjen.
RTCP: Transportkontrollprotokoll i sanntid eller RTP (kontrollprotokoll eller RTCP)
RTCP er en søsterprotokoll for RTP
Merk: -: RTP-protokoll og RTCP brukes sammen, og den er basert på UDP-protokoll (vanligvis brukt til videokonferanse)
RTSP: (Real Time Streaming Protocol)
Sanntids streaming medieøktprotokoll, SDP (Session Description Protocol), RTP (sanntids transportprotokoll).
RTSP er en multimedia streaming-protokoll som brukes til å kontrollere lyd eller video. RTSP gir et utvidbart rammeverk, som gjør det mulig å kontrollere og kreve sanntidsdata, for eksempel lyd og video.
Mediedata bruker RTP, RTCP-protokoll.
Generelt sett brukes UDP som transportlag. Egnet for IPTV-scener.
Datakilder inkluderer feltdata og data lagret i klipp. Formålet med denne protokollen er å kontrollere flere dataoverføringsforbindelser og gi en måte å velge overføringskanaler, som UDP, multicast UDP og TCP
Det gir også en metode for valg av overføringsmekanisme basert på RTP
Nettverksprotokollen som brukes i overføring, er ikke innenfor rammen av definisjonen. Serveren kan velge å bruke TCP eller UDP for å overføre strøminnholdet, noe som er mer tolerant for nettverksforsinkelse
---> Den største forskjellen mellom RTSP og RTP er at RTSP er en toveis sanntids dataoverføringsprotokoll, som gjør det mulig for klienten å sende forespørsler til serveren, for eksempel avspilling, fremover, bakover og så videre. Når
Imidlertid 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 ligner på HTTP-protokollen
Protokoll for nettverksapplikasjonslag
WebRTC:
Protokollen for streaming av media er implementert på nettet. Da Google først lanserte webrtc, så gigantene enten kaldt eller motsto. RTP-protokoll brukes til overføring.
RTMP (sanntids meldingsprotokoll)
Macromedia utviklet et sett med live videoprotokoll, som nå tilhører Adobe. I likhet med HLS kan den brukes på live video, og den vil ikke gå tapt basert på TCP.
// Forskjellen er at RTMP ikke kan spille i IOS-nettleser basert på flash, men ytelsen i sanntid er bedre enn HLS.
Sanntids meldingsprotokoll er en åpen protokoll utviklet av Adobe Systems for lyd-, video- og dataoverføring mellom flash-spiller og server
// I IOS-kode brukes RTMP ofte til å presse streaming. Du kan bruke tredjepartsbiblioteket librtmp IOS til å skyve streaming. Librtmp innkapsler noen kjerne-API-er som brukerne kan ringe
RTMP-protokollen krever også at klient og server oppretter RTMP-forbindelse gjennom "håndtrykk", og deretter overfører kontrollinformasjon på forbindelsen. RTMP-protokollen vil formatere dataene under overføring. For å oppnå bedre multipleksing, underleverandør og informasjonsrettferdighet, vil avsenderen dele meldingen i biter med meldings-ID, og hver del kan være en egen melding,
Det kan også være en del av meldingen. Mottakeren vil gjenopprette klumpen til en fullstendig melding i henhold til lengden på data, meldings-ID og melding som er inneholdt i klumpen, for å sende og motta informasjon.
HLS: HTTP Live Streaming (HLS)
Det er en HTTP-basert streamingmedietransportprotokoll implementert av Apple Inc,
Det kan realisere direktesendende og on-demand streaming media, hovedsakelig brukt i IOS-system
Å tilby lyd og video live og on-demand-løsninger for IOS-enheter (som iPhone og iPad).
HLS on demand er i utgangspunktet en vanlig segmentert HTTP on demand. Forskjellen er at segmentene er veldig små.
Sammenlignet med de vanlige protokollene for live streaming, slik som RTMP-protokollen, RTSP-protokollen, MMS-protokollen og så videre, er den største forskjellen i HLS live streaming at det live streaming-klienten ikke får er en fullstendig melding
Hele datastrømmen.
HLS-protokollen lagrer live datastrøm som kontinuerlige, kortsiktige og lange mediefiler (mpeg-ts-format) på serversiden, mens klientsiden kontinuerlig laster ned og spiller av disse små filene,
Fordi serveren alltid genererer nye små filer fra de nyeste live-dataene, så lenge klienten kontinuerlig spiller av filene som er hentet fra serveren i rekkefølge, blir direktesendingen realisert.
Det kan sees at i utgangspunktet er HLS basert på>> on-demand teknologi for å oppnå live <<. Fordi dataene overføres via HTTP-protokoll, er det ikke nødvendig å vurdere brannmuren eller proxyen
Videre er lengden på den segmenterte filen veldig kort, slik at klienten raskt kan velge og bytte kodehastighet for å tilpasse seg avspillingen under forskjellige båndbreddeforhold. Imidlertid bestemmer denne typen tekniske egenskaper ved HLS dens fremtidige utvikling
Generelt er forsinkelsen alltid høyere enn den vanlige protokollen for live streaming.
// Både IOS og Android støtter naturlig nok denne protokollen, og konfigurasjonen er enkel. Du kan bruke videokoden direkte
*** VLS: er en slags streaming-server, som er spesielt brukt til å løse ulike problemer med streaming. Den har også noen egenskaper ved VLC. Som server kan videolan sende HTTP-, RTP- og RTSP-strømmer.
I prinsippet kan RTSP, RTMP og HTTP brukes til direktesending og on-demand kringkasting, men generelt brukes RTSP og RTMP til direktesending og HTTP brukes til on-demand kringkasting. Vi velger RTMP-protokoll.
Forsinkelse av forskjellige protokoller og årsakene
RTMP og httpflv: dataene til disse to protokollene er omtrent de samme, så årsakene til forsinkelsen er like. Det er rimelig å si at forsinkelsen med TCP-streaming direktesending er veldig lav. Hvorfor er det forsinkelse i RTMP og httpflv? Årsaken er at på h264 overføres RTMP og httpflv begge flv-koder. Dataene til videomerket er vanligvis H264-data. H264-dekoding har en IBP. Jeg er nøkkelrammen, som er et komplett bilde. Du må først ha et jeg for å dekode følgende BP. Antall BP-rammer kan være så få som du vil, men antall I-rammer kan ikke være mindre, så jeg rammer må være i flv. Merkoverføring er den andre overføringen (den første er h264spps). Imidlertid er I-rammer ikke vanlige i H264-strømmer. Det er bare den ene I-rammen etter den andre. Dette intervallet er ofte kjent som GOP. Ved koding er GOP satt veldig kort. Når klienten kobler seg til, vil serveren finne den nyeste I-rammen i strømmen i raskeste hastighet og sende live data fra I-rammen. Imidlertid, når GOP er veldig lang, er I-rammeintervallet veldig langt, eller vent til neste I-ramme begynner å sende data til den nye forbindelsen, eller finn den siste I-rammen i hurtigbufferen for å begynne å sende. Dette er nøkkelen til forsinkelsen av RTMP- og HLS-protokoller. På store CDN-plattformer kalles det "RTMP second on technology". Prinsippet er å dekode streamingdata to ganger og sette en liten GOP. Generelt, når GOP er satt til 1s, uavhengig av nettverksoverføringslinkforsinkelse, er den maksimale dataforsinkelsen 1s. Heldigvis rammer jeg 0 forsinkelser!
|
|
|
|
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: |
|
