Utfordringen med mobil direktesendingsteknologi er langt fra tradisjonelt utstyr eller datamaskinsending. Dens komplette prosessorkoblinger inkluderer, men ikke begrenset til: lyd- og videoinnhenting, skjønnhet / filter / spesialeffektbehandling, koding, pakke, streaming, transkoding, distribusjon, dekoding / gjengivelse / avspilling, etc.
De vanligste problemene med direktesending inkluderer:
Hvordan kan vertsstrømmen være stabil i det ustabile nettverksmiljøet?
Hvordan kan publikum i avsidesliggende områder se live-sendingen jevnt i HD?
Hvordan bytte linjen intelligent i øyeblikket av live-kortet?
Hvordan måler du nøyaktigheten til direktesendings kvalitetsindeks og justerer den i sanntid?
Hvordan kan forskjellige chipplattformer på mobile enheter kode og gjengi video med høy ytelse?
Hvordan håndtere spesialeffekter av filtre som skjønnhet?
Hvordan realisere andre på avspilling?
Hvordan sikre kontinuerlig kringkasting av direktesending jevnt uten karding?
Denne delingen vil avdekke mysteriet til kjerneteknologien til mobil kringkasting.
1. Grunnleggende kunnskap om video, direktesending og så videre
Hva er video?
Først må vi forstå et av de mest grunnleggende begrepene: video. Fra det perseptuelle synspunktet er video en film full av moro, kan være en film, kan være en kortfilm, er en sammenhengende visuell innvirkning ytelse rikt bilde og lyd. Men fra et rasjonelt synspunkt er video strukturerte data. Det kan tolkes på ingeniørspråk. Vi kan analysere video i følgende struktur:
1) Erfaring med andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
2) Innholdselement
3) Bilde
4) Lyd
5) Metainformasjon
6) Codec
Video: H.264, H.265,…
Lyd: AAC ， HE-AAC, ...
7) Beholder
MP4, MOV, FLV, RM, RMVB, AVI,…
Enhver videofil, strukturelt, er en slik måte å lage komposisjon på:
1) De mest grunnleggende innholdselementene består av bilde og lyd;
2) Bildet behandles av videokoding og komprimeringsformat (vanligvis H.264);
3) Lyd behandles av lydkodende komprimeringsformat (for eksempel AAC);
4) Angi tilsvarende metainformasjon (metadata);
Til slutt fullføres containerpakken (for eksempel MP4) for å danne en komplett videofil.
Hvis du føler at det er vanskelig å forstå, kan du forestille deg en flaske ketchup. Det ytre lagflasken er som beholderen, informasjon om råvarer og prosessanlegg angitt på flasken er som metadata. Etter at flaskelokket er åpnet (pakket ut), er selve ketchupen som det kodede innholdet etter kompresjonsbehandling. Prosessen med prosessering av tomat og krydder til ketchup er som koding, mens råvaren tomat og krydder ligner mest på det originale innholdet.
2. Sanntidsoverføring av video
Kort sagt, rasjonell kognitiv videostruktur hjelper oss med å forstå videosending. Hvis video er en slags strukturerte data, så er videosending utvilsomt måten å overføre denne "strukturerte data" (video) i sanntid.
Så det åpenbare spørsmålet er: hvordan kan sanntid overføre disse strukturerte dataene?
Her er et paradoks: en containerpakket video må være uforanderlig videofil, uforanderlig videofil er allerede et produksjonsresultat, ifølge "relativitet", og dette produksjonsresultatet kan ikke være nøyaktig til sanntidsnivået, det har vært et minne av tid og rom.
Derfor må videosending være en prosess med "produksjon, overføring og forbruk". Dette betyr at vi må se nærmere på midtprosessen (koding) av videoen før de originale innholdselementene (bilder og lyd) til det ferdige produktet (videofiler).
3. Videokoding komprimering
La oss ta en titt på videokoding og komprimeringsteknologi.
For å lette lagring og overføring av videoinnhold er det vanligvis nødvendig å redusere volumet på videoinnhold, det vil si at de originale innholdselementene (bilde og lyd) må komprimeres, og kompresjonsalgoritmen blir også referert til som kodingsformatet. For eksempel vil de originale bildedataene i videoen komprimeres i H.264-kodingsformat, og lydsamplingsdataene komprimeres i AAC-kodingsformat.
Etter koding og komprimering bidrar videoinnhold virkelig til lagring og overføring; når du ser og spiller, er det imidlertid også nødvendig med avkodingsprosess. Derfor er det åpenbart at en slags konvensjon kan forstås av både koderen og dekoderen er nødvendig mellom koding og dekoding. Når det gjelder videokodekoding og dekoding, er denne konvensjonen enkel:
Koderen koder for flere bilder og produserer en GOP (gruppe bilder) i et segment. Når du spiller, leser dekoderen en del av GOP for dekoding, leser deretter bildet og gjengir deretter skjermen.
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
GOP (gruppe bilder) er en serie sammenhengende bilder, som består av en I-ramme og flere B / P-rammer. Det er den grunnleggende enheten for videobildekoder og dekodertilgang. Arrangementsekvensen gjentas til slutten av bildet.
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
I-rammen er en intern kodingsramme (også kjent som nøkkelramme), P-rammen er forutsigelsesramme (fremover referanseramme), og ramme B er toveis interpolasjonsramme (toveis referanseramme). Kort fortalt er ramme I et komplett bilde, mens P- og B-post endres i forhold til I-ramme.
Uten I-rammer kan ikke P- og B-rammer dekodes.
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
Oppsummert, en video hvis bildedeldata er et sett med GOP-er, mens en enkelt GOP er et sett med I / P / B-rammebilder.
I et slikt geometrisk forhold er video som et "objekt", GOP er som "molekyl", og bildet av I / P / B-rammen er som "atom".
Tenk deg hva ville være en opplevelse hvis vi endret overføringen av et objekt til et atom, og den minste partikkelen med lysets hastighet, og oppfattes med det blotte øye til mennesker?
4. Hva er video live?
Det er ikke vanskelig å åpne hjernehullet, direktesending er en slik opplevelse. Video live-teknologi er den minste partikkelen (I / P / B-ramme）, en teknologi for overføring med lyshastighet basert på tidsserier.
Kort sagt er direktesending prosessen med å streame data (video / lyd / dataramme) og tidsstempel. Senderen samler kontinuerlig lyd- og videodata, og spres deretter gjennom koding, pakke, trykkstrøm, og spres deretter gjennom relédistribusjonsnettverk. Avspillingsslutt laster ned data kontinuerlig og dekodes og spilles av i henhold til tidssekvensen. På denne måten realiseres direktesendingsprosessen med "produksjon, overføring og forbruk".
Etter å ha forstått de to grunnleggende konseptene ovenfor om video og direktesending, kan vi se forretningslogikken til direktesending.
Forretningslogikk for direktesending
Her er en strømlinjeformet en til mange live servicemodell, samt protokoller mellom forskjellige nivåer.
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
Forskjellene mellom avtalene er som følger
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
Ovenfor er noen grunnleggende konsepter om direktesendt teknologi. Deretter forstår vi videre de live ytelsesindikatorene som påvirker folks visuelle opplevelse.
Ytelsesindeks for direktesending som påvirker visuell opplevelse
Den første ytelsesindikatoren for direktesending er forsinkelse, som er tiden det tar å sende data fra informasjonskilden til destinasjonen.
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
I følge Einsteins smale relativitet er lysets hastighet den høyeste hastigheten som all energi, materie og informasjon kan oppnå. Denne konklusjonen setter en grense for overføringshastigheten. Så selv om vi føler oss i sanntid med det blotte øye, er det faktisk en viss forsinkelse.
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
Fordi rtmp / hls er basert på applikasjonslagsprotokollen over TCP, vil TCP-håndtrykk tre ganger, fire bølger, og hver rundtur i prosessen med langsom start legges til med en tur-retur-tid (RTT), noe som vil øke forsinkelsen.
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
For det andre, i henhold til egenskapene til TCP videresending av pakketap, kan nettverksjitter forårsake videresending av pakketap, og også indirekte føre til økning av forsinkelse.
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
En komplett direktesendingsprosess inkluderer, men er ikke begrenset til, følgende lenker: samling, prosessering, koding, pakke, streaming, overføring, transkoding, distribusjon, streaming, dekoding og avspilling. Fra streaming til å spille, og deretter gjennom den mellomliggende videresendingskoblingen, jo lavere forsinkelse, jo bedre brukeropplevelse.
Den andre ytelsesindikatoren for direktesending er skjermbildeforsinkelsen i videoavspillingsprosessen, noe som får folk til å føle seg "kort". Statistikken over antall treff som spilles i tidsenhet kalles handlekurven.
Faktorene som forårsaker Caton kan være dataavbrudd i streaming-enden, overbelastning av offentlig nettverksoverføring eller unormal nettverksjitter, eller dårlig dekodingsytelse for terminalenheter. Jo mindre eller ingen Caton-frekvens, jo bedre brukeropplevelse.
Den første skjermen til den tredje live-ytelsesindikatoren er tidkrevende, som refererer til tiden skjermen venter på det blotte øye å se etter første klikk og spill. Teknisk sett refererer det til den tidkrevende for spilleren å dekode den første rammen for gjengivelsesdisplayet. Generelt sett refererer "second on" til at skjermen kan sees innen ett sekund etter at du har klikket på avspillingen. Jo raskere det første skjermbildet åpnes, jo bedre brukeropplevelse.
Ovennevnte tre live-kringkastingsindikatorer tilsvarer et lavt ventetid, high-definition jevnt, raskt sekund på brukeropplevelseskravene. Å forstå disse tre ytelsesindikatorene er veldig viktig for å optimalisere brukeropplevelsen av mobil live app.
Så hva er de vanlige gropene i live direktesending?
I følge erfaringen som er oppsummert i praksis, kan gropen for video-direktesending på mobilplattform oppsummeres i to aspekter: utstyrsforskjell og teknisk test brakt av disse scenene i nettverksmiljø.
Grop- og unngåelsestiltakene fra den mobile live-sendescenen
Koding av forskjeller på forskjellige brikkeplattformer
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
Uansett hard eller myk koding på IOS-plattformen, fordi det er en fabrikk med eple, er det nesten ingen kodingsforskjell på grunn av forskjellige chipplattformer.
Imidlertid har mediacodec-koderen som tilbys av Android framework SDK store forskjeller på Android-plattformer. Ulike produsenter bruker forskjellige sjetonger, mens Android mediacodec-ytelsen er litt forskjellig på forskjellige brikkeplattformer, og kostnadene ved å innse kompatibiliteten til hele plattformen er ikke lave.
I tillegg er H.264-kodingskvalitetsparametrene til Android mediacodec-hardkodelaget faste basert, slik at malingskvaliteten vanligvis også er generell. Derfor, under Android-plattformen, er anbefalingen å bruke myk redigering, fordelen er at malingskvaliteten kan reguleres og kompatibiliteten er bedre.
Hvordan samle inn og kode low-end utstyr med høy ytelse?
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
For eksempel kan kameraet være bildet. Volumet på et bilde er ikke lite. Hvis anskaffelsesfrekvensen er veldig høy og rammehastigheten for koding er veldig høy, passerer hvert bilde gjennom koderen, kan koderen overbelaste igjen.
På dette tidspunktet kan vi vurdere at før koding, uten å påvirke kvaliteten på bildet (vi har snakket om mikrofilmens av bildefrekvens), kan vi selektivt miste bilder for å redusere strømforbruket til kodelinken.
Hvordan garanterer du jevn strømming i høydefinisjon under svakt nettverk
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
I mobilnett er det lett å støte på ustabilitet i nettverket, tilbakestilling av tilkobling, brutt linje-tilkobling, på den ene siden, hyppig omkobling, og etablering av forbindelse krever overhead. På den annen side kan båndbreddeflaskehals forekomme, spesielt når GPRS / 2G / 3G / 4G-bryter oppstår. Når båndbredden ikke er nok, er det vanskelig å sende innholdet med høy bildefrekvens / høy bithastighet, så det er nødvendig med støtte for variabel bithastighet.
Det vil si at ved push-enden kan nettverkstilstand og enkel hastighetsmåling oppdages, og kodehastigheten kan byttes dynamisk for å sikre jevn flyt av push under nettverksbytte.
For det andre kan logikken med koding, pakke og push stream også finjusteres. Du kan prøve å miste bilder selektivt, for eksempel å miste videoreferanserammen først (I-ramme og lydramme), som også kan redusere datainnholdet som skal overføres, men samtidig kan det oppnå formålet med ikke å påvirke kvalitet på maling og jevn audiovisuell versjon.
Status og forretningsstatus for live stream må skilles ut
Direktesending er samspillet mellom mediestrøm og app er API-signalstrøm, og statusen til begge kan ikke forveksles. Spesielt kan ikke statusen for live stream vurderes ut fra API-tilstanden til APP-interaksjon.
Erfaring fra andre om optimalisering av mobil direktesendingsteknologi (inkludert ppt)
Ovennevnte er flere vanlige groper og unngåelsestiltak i live mobilscenen.
Andre optimaliseringstiltak for mobil live-sendescene
1, Hvordan optimalisere åpningshastigheten for å nå den legendariske "second on"?
Du kan se at noen mobiltelefon-live-apper på markedet er veldig raske på, litt på. Og noen mobiltelefoner live app, klikk for å spille etter flere sekunder før du spiller. Hva forårsaker en slik forskjell?
De fleste spillere kan dekode og spille etter at de får fullført GOP. Ffmpeg-baserte spillere kan bare spille etter at tidsstempelsynkronisering av lyd og maling er nødvendig (hvis det ikke er lyd i en direktesending, kan bare video spille ansiktet etter å ha ventet på lydavbruddet).
Den andre på kan vurderes i følgende aspekter:
1. skriv om spillerlogikken for å vise spilleren etter at den får den første nøkkelrammen.
Den første rammen av GOP er vanligvis nøkkelramme, og den kan nå "første ramme andre gang" på grunn av mindre innlastede data.
Hvis live-serveren støtter GOP-cache, betyr det at spilleren kan få dataene umiddelbart etter å ha opprettet en forbindelse med serveren, og dermed sparer tiden for overføring av bakkilde på tvers av regioner og på tvers av operatører.
GOP gjenspeiler perioden med nøkkelbilder, det vil si avstanden mellom to nøkkelbilder, nemlig maksimalt antall bilder i en rammegruppe. Forutsatt at den konstante bildefrekvensen til en video er 24 bilder per sekund (dvs. 1 sekund 24 bilder) og nøkkelbildeperioden er 2S, er en GOP 48 bilder. Generelt kreves det minst en nøkkelramme for hvert sekund av videoen.
Å øke antall nøkkelbilder forbedrer kvaliteten på bildet (GOP er vanligvis et multiplum av FPS), men øker båndbredden og nettverksbelastningen samtidig. Dette betyr at klientspilleren laster ned en GOP.
|
|
|
|
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: |
|
