Streamingoversikt:
De såkalte streamingmediene refererer til medieformatet som spilles på Internett ved hjelp av streamingoverføring.
Streaming media kalles også streaming media. Det refererer til virksomheter som bruker en videoserveringsserver til å sende ut programmer som datapakker og levere dem til nettverket.
Etter at brukeren dekomprimerer dataene gjennom dekomprimeringsenheten, vises programmet som før overføring.
Streaming media overfører lyd-, video- og multimediafiler i form av streaming over nettverket.
Streaming mediefilformat er et medieformat som støtter streaming og avspilling.
Strømmingsmetoden er å dele multimediafiler som video og lyd i komprimerte pakker gjennom en spesiell komprimeringsmetode.
Kontinuerlig og sanntidsoverføring fra serveren til brukerens datamaskin. I systemer som bruker streamingoverføring, trenger ikke brukerne å vente på hele filen som avspilling uten streaming.
Innholdet kan sees etter at alle nedlastinger er fullført, men bare noen få sekunder eller titalls sekunder med oppstartsforsinkelse kan brukes på brukerens datamaskin
Den tilhørende spilleren spiller av komprimert video eller lyd og andre streaming-mediefiler, og den gjenværende delen vil fortsette å lastes ned til avspillingen er fullført.
1. RTP: (Transportprotokoll i sanntid)
Det er en transportlagsprotokoll for multimedia datastreaming på Internett. RTP-protokollen og RTP-kontrollprotokollen RTCP brukes sammen,
Og den er bygget på UDP-protokollen.
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 data blir bedt om fra serveren igjen.
2. RTCP: Transportkontrollprotokoll i sanntid eller RTP Control Protocol eller RTCP for kort)
Sanntids overføringskontrollprotokoll er en søsterprotokoll for sanntidsoverføringsprotokoll (RTP).
Merk: -: RTP-protokoll og RTP-kontrollprotokoll (RTCP) brukes sammen, og den er basert på UDP-protokoll (vanligvis brukt til videokonferanser)
3. RTSP: (Sanntids streamingprotokoll)
Sanntids streaming medieøktprotokoll, SDP (øktbeskrivelsesprotokoll), RTP (sanntids transportprotokoll).
Det er en multimedia streaming-protokoll som brukes til å kontrollere lyd eller video. RTSP gir et utvidbart rammeverk som gjør det mulig å kontrollere og on-demand sanntidsdata, for eksempel lyd og video.
Mediedataene bruker rtp- og rtcp-protokoller. Bruk vanligvis udp som transportlag. Egnet for IPTV-scener. 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, som UDP, multicast UDP og TCP, og å gi metoder for å velge en overføringsmekanisme basert på RTP. Nettverkskommunikasjonsprotokollen som brukes under overføring, er ikke innenfor rammen av definisjonen. Serveren kan velge å bruke TCP eller UDP for å overføre streaming-innholdet, noe som er mer tolerant for forsinkelser i nettverket.
--->: 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, spoling fremover og omvendt. når
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 ligner på http-protokollen
Protokoll for nettverksapplikasjonslag.
4. WebRTC:
Websiden implementerer streamingmedieprotokollen. Da Google først lanserte WebRTC, satt gigantene enten på sidelinjen eller motsto det. Bruk RTP-protokolloverføring.
5. RTMP (Sanntids meldingsprotokoll)
Et sett med live videoprotokoller utviklet av Macromedia eies nå av 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 spilles i iOS-nettleseren basert på flash, men sanntidsytelsen er bedre enn HLS.
Meldingsprotokollen i sanntid er en åpen protokoll utviklet av Adobe Systems for lyd-, video- og dataoverføring mellom Flash-spillere og servere.
// I iOS-koden brukes RTMP vanligvis til å skyve strømmen. Du kan bruke tredjepartsbiblioteket librtmp-iOS til å skyve strømmen. librtmp innkapsler noen kjerne-API-er som brukerne kan ringe
RTMP-protokollen krever også at klienten og serveren oppretter en RTMP-tilkobling gjennom et "håndtrykk", og deretter overfører kontrollinformasjon på tilkoblingen. RTMP-protokollen vil formatere dataene under overføring. I den faktiske overføringen, for bedre å oppnå multiplexing, underpakking og rettferdighet av informasjon, vil avsenderen dele meldingen i biter med meldings-ID, hver del kan være en enkelt melding,
Det kan også være en del av meldingen. Mottaksenden vil gjenopprette klumpen til en fullstendig melding i henhold til lengden på dataene som er inneholdt i klumpen, lengden på meldings-ID-en og lengden på meldingen, for å realisere sending og mottak av informasjon.
6. HLS: HTTP Live Streaming (HLS)
Det er en HTTP-basert overføringsprotokoll for strømmemedier implementert av Apple Inc., som kan realisere live og on-demand strømmemedier. Den brukes hovedsakelig i iOS-systemet og gir 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 vanlige direktesendingsprotokoller for direktesending av media, for eksempel RTMP, RTSP, MMS, etc., er den største forskjellen i HLS direktesending at det som direktesendingsklienten får ikke er en komplett datastrøm.
HLS-protokollen lagrer live datastrøm som kontinuerlige, kortvarige mediefiler (MPEG-TS-format) på serversiden, og klienten laster kontinuerlig ned og spiller av disse små filene, fordi serversiden alltid vil oppdatere den siste direktesendingen. data genererer nye små filer, så så lenge klienten kontinuerlig spiller filene som er hentet fra serveren i rekkefølge, blir live sendingen realisert. Det kan sees at det i utgangspunktet kan betraktes som HLS er en teknisk måte for >> on-demand å realisere direktesending <<. Siden dataene overføres gjennom HTTP-protokollen, er det ikke nødvendig å vurdere brannmurer eller fullmakter i det hele tatt.
I tillegg er varigheten til den segmenterte filen veldig kort, og klienten kan raskt velge og bytte bithastighet for å tilpasse seg avspillingen under forskjellige båndbreddeforhold. Imidlertid bestemmer denne tekniske egenskapen til HLS dens
Forsinkelsen vil alltid være høyere enn den vanlige live streaming-protokollen.
// Både iOS og Android støtter naturlig nok denne protokollen, konfigurasjonen er enkel, bare bruk videomerket direkte
*** VLS: Det 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, rtsp streams.
I prinsippet kan RTSP, RTMP og HTTP alle brukes til direktesending og on-demand kringkasting, men generelt brukes RTSP og RTMP for direktesending, og HTTP brukes til on-demand kringkasting. Det vi valgte er RTMP-protokollen.
Diverse protokollforsinkelser og deres grunner
rtmp og httpflv: Dataene til disse to protokollene er omtrent de samme, så årsakene til forsinkelsen er de samme. Det står til grunn at tcp-direktesendinger skal ha ekstremt lav ventetid. Hvorfor har rtmp og httpflv fortsatt latens? Årsaken er at på h264 er rtmp og httpflv flv-koder som overføres. Dataene til videomerket er vanligvis h264-data. H264-dekoding har en IBP. Jeg er en nøkkelramme, som er et komplett bilde. Du må ha et jeg før du dekoder. Sistnevnte BP, BP rammer kan være så få som du vil, men jeg rammer kan ikke være mindre, så jeg rammer må overføres andre i flv tag overføring (den første er h264spspps), men jeg rammer er ikke ofte til stede i h264 streams, Det er en I-ramme etter en periode. Denne perioden er ofte kjent som GOP. Ved koding er GOP veldig kort. Når klienten kobler seg til, vil serveren finne nærmeste I-ramme i strømmen med raskest hastighet, og sende den fra I-rammen. Live data, men 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 nærmeste I-ramme i bufferen for å begynne å sende, her er protokollforsinkelsen rtmp og hls Nøkkelpunktet er at det på store CDN-plattformer kalles "rtmp second opening technology". Prinsippet er å dekode push-data to ganger og angi en liten gop. Generelt sett er gop satt til 1s. Uansett forsinkelsen til nettverksoverføringskoblingen, er den maksimale dataforsinkelsen 1s. Heldigvis er jeg-rammen 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: |
|
