FMUSER Wirless Transmet vídeo i àudio més fàcil!
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> afrikaans
sq.fmuser.org -> Albanès
ar.fmuser.org -> Àrab
hy.fmuser.org -> Armeni
az.fmuser.org -> Azerbaidjanès
eu.fmuser.org -> basc
be.fmuser.org -> bielorús
bg.fmuser.org -> Bulgària
ca.fmuser.org -> català
zh-CN.fmuser.org -> Xinès (simplificat)
zh-TW.fmuser.org -> Xinès (tradicional)
hr.fmuser.org -> croata
cs.fmuser.org -> txec
da.fmuser.org -> Danès
nl.fmuser.org -> Holandès
et.fmuser.org -> estonià
tl.fmuser.org -> filipí
fi.fmuser.org -> finès
fr.fmuser.org -> Francès
gl.fmuser.org -> gallec
ka.fmuser.org -> georgià
de.fmuser.org -> alemany
el.fmuser.org -> Grec
ht.fmuser.org -> crioll haitià
iw.fmuser.org -> Hebreu
hi.fmuser.org -> Hindi
hu.fmuser.org -> Hungarian
is.fmuser.org -> islandès
id.fmuser.org -> indonesi
ga.fmuser.org -> irlandès
it.fmuser.org -> Italià
ja.fmuser.org -> japonès
ko.fmuser.org -> coreà
lv.fmuser.org -> Letó
lt.fmuser.org -> Lituània
mk.fmuser.org -> macedoni
ms.fmuser.org -> Malai
mt.fmuser.org -> maltès
no.fmuser.org -> Noruega
fa.fmuser.org -> persa
pl.fmuser.org -> Polonès
pt.fmuser.org -> Portuguès
ro.fmuser.org -> Romanès
ru.fmuser.org -> rus
sr.fmuser.org -> serbi
sk.fmuser.org -> Eslovac
sl.fmuser.org -> Eslovènia
es.fmuser.org -> Castellà
sw.fmuser.org -> Suahili
sv.fmuser.org -> Suec
th.fmuser.org -> Tai
tr.fmuser.org -> turc
uk.fmuser.org -> ucraïnès
ur.fmuser.org -> urdú
vi.fmuser.org -> Vietnamita
cy.fmuser.org -> gal·lès
yi.fmuser.org -> Yiddish
El sistema de transmissió en directe d’àudio i vídeo és un sistema d’enginyeria complex. Per aconseguir retransmissions en directe molt baixes, necessita una complexa optimització de l’enginyeria del sistema i familiaritzat amb els diversos components. Aquests són alguns consells habituals d’ajust:
Optimització de codificació
1. Assegureu-vos que el còdec activa la configuració del retard mínim. El còdec generalment té un commutador d’optimització de baixa latència, especialment per a H.264. És possible que molta gent no sàpiga que el descodificador H.264 emmagatzemarà en memòria cau un nombre determinat de marcs de vídeo abans de mostrar-los. Per al vídeo amb resolució QCIF (176 × 144), emmagatzemarà en memòria cau 16 fotogrames i, per al vídeo 720p, en emmagatzemarà en memòria cau 5 fotogrames. Per al primer fotograma llegit, això suposa un gran retard. Si no utilitzeu H.264 per codificar i comprimir el vostre vídeo, assegureu-vos que no utilitzeu fotogrames B, també tindrà un impacte més gran en el retard, ja que la descodificació dels fotogrames B del vídeo depèn de la fotogrames de vídeo abans i després, cosa que augmentarà el retard.
2. El codificador sol tenir el retard provocat pel control de codi, que també s'anomena retard d'inicialització o la mida de memòria intermèdia de VBV. Es considera la memòria intermèdia entre el codificador i el flux de bits del descodificador, que es pot configurar el més petit possible o reduir el retard sense afectar la qualitat del vídeo.
3. Si el primer retard només s'optimitza, es poden inserir més fotogrames clau entre els fotogrames de vídeo, de manera que el client pugui descodificar el flux de vídeo tan aviat com sigui possible després de rebre'l. Tanmateix, si hem d’optimitzar el retard acumulatiu en el procés de transmissió, hauríem d’utilitzar el menor nombre de fotogrames clau possible, és a dir, fotogrames I (el GOP es fa més gran). En el cas d’assegurar la mateixa qualitat de vídeo, com més fotogrames I, major és la velocitat de bits i més amplada de banda de xarxa necessària per a la transmissió, cosa que significa que el retard acumulat pot ser major. És possible que aquest efecte d'optimització no sigui obvi al sistema amb un segon retard, però serà obvi al sistema amb un retard de 100 ms o fins i tot inferior. Al mateix temps, intenteu utilitzar el còdec acc-lc per codificar àudio. Tot i que he-acc o he-acc 2 té una alta eficiència de codificació, la codificació triga més i el retard de transmissió causat per un volum d’àudio més gran té menys impacte en la transmissió del flux de vídeo.
4. No utilitzeu el format de compressió de vídeo MJPEG, com a mínim utilitzeu el format de compressió de vídeo MPEG4 sense fotograma B (perfil simple), i utilitzeu encara millor el perfil de línia de base H.264 (x264 també té un commutador d’optimització de "ajust de zerolatència"). Una optimització tan senzilla pot reduir la latència, ja que pot codificar vídeos de velocitat de fotograma completa a una velocitat de bits inferior.
5. Si s'utilitza ffmpeg, reduïu els valors de "- probesize" i "- analyseu la durada", que s'utilitzen per a la supervisió de la informació de fotogrames de vídeo i el temps de supervisió. Com més grans siguin els dos valors, més gran serà l’impacte sobre el retard de codificació. A l’escena en directe, ni tan sols cal establir el paràmetre de durada de l’anàlisi per al flux de vídeo.
6. La codificació de taxa fixa CBR pot eliminar la influència de la fluctuació de la xarxa en certa mesura. Si es pot utilitzar una codificació de velocitat variable VBR, es pot estalviar una amplada de banda de xarxa innecessària i reduir cert retard. Per tant, es suggereix que s’utilitzi VBR per codificar tant com sigui possible.
Optimització del protocol de transport
1. Proveu d'utilitzar el protocol RTMP en lloc del protocol HLS basat en HTTP per a la transmissió entre nodes de servidor, cosa que pot reduir el retard general de la transmissió. Està dirigit principalment als usuaris finals que utilitzen HLS per jugar.
2. Si l'usuari final utilitza RTMP per reproduir-se, la transcodificació s'hauria de fer al node receptor proper al final de la transmissió, de manera que la transmissió de vídeo transmesa sigui més petita que la transmissió de vídeo original.
3. Si cal, es pot utilitzar el protocol UDP personalitzat per substituir el protocol TCP i es pot eliminar la retransmissió de pèrdues de paquets sota l'enllaç de xarxa feble, cosa que pot reduir el retard. El seu principal desavantatge és que la transmissió i distribució de flux de vídeo personalitzat basat en el protocol UDP no és prou universal i els fabricants de CDN admeten el protocol de transmissió estàndard. Un altre desavantatge és que pot haver-hi esquitxades o desenfocaments causades per la pèrdua de paquets (manca de referència de descodificació de fotogrames clau), que requereix que la part de personalització del protocol faci una bona feina en el control de la pèrdua de paquets sobre la base d’UDP.
Optimització de la xarxa de transmissió
1. Hem introduït la xarxa de transmissió en temps real, que és un nou tipus de xarxa de transmissió de xarxa amb nodes autoorganitzats. No només és adequat per a l'optimització de la transmissió de la xarxa domèstica de diversos operadors, sinó que també és adequat per a les necessitats de moltes transmissions en directe a l'estranger.
2. Emmagatzemeu el GOP actual al node del servidor i coopereu amb el reproductor per optimitzar el temps d'obertura del vídeo.
3. El servidor registra la velocitat de fotogrames i la velocitat de codi de segon nivell quan cada flux de vídeo flueix a cada enllaç en temps real i controla la fluctuació de la velocitat de codi i la velocitat de fotogrames en temps real.
4. El client (push stream i play) obté el node òptim actual en quasi temps real consultant el servidor (un cop cada 5 segons) i el node de falla i la línia actuals estan fora de línia en temps gairebé real.
Streaming i optimització de la reproducció
1. El sistema pot emmagatzemar dades en memòria cau abans d'enviar dades. L’ajust d’aquest paràmetre també necessita trobar un equilibri.
2. El control de memòria intermèdia del reproductor també té una gran influència en el primer retard del vídeo. Si només s’optimitza el primer retard, les dades es poden descodificar immediatament quan arribin en cas de memòria intermèdia 0. Però en un entorn de xarxa feble, per tal d’eliminar l’impacte de la fluctuació de la xarxa, cal establir una memòria cau determinada, de manera que hem de trobar un equilibri entre l’estabilitat de la transmissió en directe i l’optimització del primer retard d’obertura i ajustar la mida de memòria intermèdia optimitzada.
3. Estratègia de memòria intermèdia dinàmica del jugador, que és una versió millorada del control de memòria cau del jugador anterior. Si només escollim entre memòria cau 0 i memòria cau de mida fixa per trobar un equilibri, finalment escollirem una memòria cau de mida fixa, que no és just per a 100 milions d’usuaris de terminals d’internet mòbil. Les seves diferents condicions de xarxa determinen que la memòria cau de mida fixa no és completament adequada. Per tant, podem considerar una "estratègia de memòria intermèdia dinàmica". Quan el reproductor està encès, fem servir una estratègia de memòria intermèdia molt petita o fins i tot nul·la. La mida de la memòria intermèdia de la pròxima part de temps es determina pel temps consumit per descarregar el primer vídeo. Al mateix temps, la xarxa actual es controla en temps real durant el procés de reproducció i la mida de la memòria intermèdia s’ajusta en temps real durant el procés de reproducció. D'aquesta manera, el primer temps d'obertura pot ser molt baix i la influència de la fluctuació de la xarxa es pot eliminar el màxim possible.
4. Estratègia de joc de velocitat dinàmica. A més de l’estratègia d’ajust dinàmic de la mida de la memòria intermèdia, també podem utilitzar la informació de la xarxa de monitorització en temps real per ajustar dinàmicament la velocitat de bits en el procés de reproducció. En cas que l’amplada de banda de xarxa sigui insuficient, podem reduir la velocitat de bits per reproduir-ne i reduir el retard.
L’anterior forma part de les tècniques d’optimització de baixa latència. De fet, quan optimitzem una latència baixa, no només ens centrem en la "baixa latència", sinó que intentem aconseguir una latència baixa a condició que altres condicions no afectin l'experiència de l'usuari. Per tant, el seu contingut inclou una àmplia gamma de temes.
|
Introduïu el correu electrònic per obtenir una sorpresa
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> afrikaans
sq.fmuser.org -> Albanès
ar.fmuser.org -> Àrab
hy.fmuser.org -> Armeni
az.fmuser.org -> Azerbaidjanès
eu.fmuser.org -> basc
be.fmuser.org -> bielorús
bg.fmuser.org -> Bulgària
ca.fmuser.org -> català
zh-CN.fmuser.org -> Xinès (simplificat)
zh-TW.fmuser.org -> Xinès (tradicional)
hr.fmuser.org -> croata
cs.fmuser.org -> txec
da.fmuser.org -> Danès
nl.fmuser.org -> Holandès
et.fmuser.org -> estonià
tl.fmuser.org -> filipí
fi.fmuser.org -> finès
fr.fmuser.org -> Francès
gl.fmuser.org -> gallec
ka.fmuser.org -> georgià
de.fmuser.org -> alemany
el.fmuser.org -> Grec
ht.fmuser.org -> crioll haitià
iw.fmuser.org -> Hebreu
hi.fmuser.org -> Hindi
hu.fmuser.org -> Hungarian
is.fmuser.org -> islandès
id.fmuser.org -> indonesi
ga.fmuser.org -> irlandès
it.fmuser.org -> Italià
ja.fmuser.org -> japonès
ko.fmuser.org -> coreà
lv.fmuser.org -> Letó
lt.fmuser.org -> Lituània
mk.fmuser.org -> macedoni
ms.fmuser.org -> Malai
mt.fmuser.org -> maltès
no.fmuser.org -> Noruega
fa.fmuser.org -> persa
pl.fmuser.org -> Polonès
pt.fmuser.org -> Portuguès
ro.fmuser.org -> Romanès
ru.fmuser.org -> rus
sr.fmuser.org -> serbi
sk.fmuser.org -> Eslovac
sl.fmuser.org -> Eslovènia
es.fmuser.org -> Castellà
sw.fmuser.org -> Suahili
sv.fmuser.org -> Suec
th.fmuser.org -> Tai
tr.fmuser.org -> turc
uk.fmuser.org -> ucraïnès
ur.fmuser.org -> urdú
vi.fmuser.org -> Vietnamita
cy.fmuser.org -> gal·lès
yi.fmuser.org -> Yiddish
FMUSER Wirless Transmet vídeo i àudio més fàcil!
Contacte
Adreça:
No.305 Room HuiLan Building No.273 Huanpu Road Guangzhou Xina 510620
Categories
Newsletter