FMUSER Wirless Transmit Video and Audio Máis 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 -> árabe
hy.fmuser.org -> Armenian
az.fmuser.org -> azerí
eu.fmuser.org -> éuscaro
be.fmuser.org -> bielorruso
bg.fmuser.org -> Búlgaro
ca.fmuser.org -> catalán
zh-CN.fmuser.org -> chinés (simplificado)
zh-TW.fmuser.org -> Chinés (tradicional)
hr.fmuser.org -> croata
cs.fmuser.org -> Checo
da.fmuser.org -> danés
nl.fmuser.org -> Holandés
et.fmuser.org -> estoniano
tl.fmuser.org -> filipino
fi.fmuser.org -> finés
fr.fmuser.org -> Francés
gl.fmuser.org -> galego
ka.fmuser.org -> xeorxiano
de.fmuser.org -> alemán
el.fmuser.org -> Grego
ht.fmuser.org -> crioulo haitiano
iw.fmuser.org -> Hebreo
hi.fmuser.org -> hindi
hu.fmuser.org -> Hungarian
is.fmuser.org -> islandés
id.fmuser.org -> indonesio
ga.fmuser.org -> irlandés
it.fmuser.org -> Italiano
ja.fmuser.org -> xaponés
ko.fmuser.org -> coreano
lv.fmuser.org -> letón
lt.fmuser.org -> Lituano
mk.fmuser.org -> macedonio
ms.fmuser.org -> malaio
mt.fmuser.org -> maltés
no.fmuser.org -> Norwegian
fa.fmuser.org -> persa
pl.fmuser.org -> polaco
pt.fmuser.org -> Portugués
ro.fmuser.org -> Romanés
ru.fmuser.org -> ruso
sr.fmuser.org -> serbio
sk.fmuser.org -> Eslovaco
sl.fmuser.org -> Esloveno
es.fmuser.org -> castelán
sw.fmuser.org -> Suahili
sv.fmuser.org -> Sueco
th.fmuser.org -> Thai
tr.fmuser.org -> turco
uk.fmuser.org -> ucraíno
ur.fmuser.org -> urdú
vi.fmuser.org -> Vietnamita
cy.fmuser.org -> galés
yi.fmuser.org -> Yiddish
O sistema de transmisión en directo de audio e vídeo é un complexo sistema de enxeñaría. Para lograr unha transmisión en directo con demora moi baixa, precisa unha complexa optimización de enxeñaría de sistemas e está familiarizado cos distintos compoñentes. Aquí tes algúns consellos comúns de axuste:
Optimización de codificación
1. Asegúrese de que o codec activa a configuración do atraso mínimo. O codec normalmente ten un conmutador de optimización de baixa latencia, especialmente para H.264. É posible que moita xente non saiba que o descodificador H.264 gardará na memoria caché un certo número de fotogramas de vídeo antes de amosalos. Para o vídeo con resolución QCIF (176 × 144), almacenará na memoria caché 16 fotogramas e, para o vídeo 720p, almacenará na memoria caché 5 fotogramas. Para o primeiro fotograma lido, este é un gran atraso. Se non usa H.264 para codificar e comprimir o seu vídeo, asegúrese de non usar fotogramas B, tamén terá un maior impacto no atraso, porque a descodificación de fotogramas B no vídeo depende da fotogramas de vídeo antes e despois, o que aumentará o atraso.
2. O codificador normalmente ten o atraso causado polo control de código, que tamén se denomina atraso de inicialización ou o tamaño do búfer de VBV. Considérase como o buffer entre o codificador e o decodificador de fluxo de bits, que se pode configurar o máis pequeno posible ou reducir o atraso sen afectar a calidade do vídeo.
3. Se o primeiro atraso só se optimiza, pódense inserir máis fotogramas clave entre os fotogramas de vídeo para que o cliente poida decodificar o fluxo de vídeo o antes posible despois de recibilo. Non obstante, se precisamos optimizar o atraso acumulado no proceso de transmisión, deberiamos empregar o menor número posible de fotogramas clave, é dicir, fotogramas I (o GOP faise máis grande). No caso de garantir a mesma calidade de vídeo, cantos máis fotogramas I, maior taxa de bits e maior ancho de banda de rede requirido para a transmisión, o que significa que o atraso acumulado pode ser maior. É posible que este efecto de optimización non sexa evidente no sistema con segundo atraso, pero será evidente no sistema con 100 ms ou incluso un atraso inferior. Ao mesmo tempo, intente usar o códec acc-lc para codificar audio. Aínda que he-acc ou he-acc 2 ten unha alta eficiencia de codificación, a codificación leva máis tempo e o atraso na transmisión causado por un maior volume de audio ten menos impacto na transmisión do fluxo de vídeo.
4. Non empregue o formato de compresión de vídeo MJPEG, polo menos use o formato de compresión de vídeo MPEG4 sen fotograma B (perfil simple) e use aínda mellor o perfil de liña H.264 (x264 tamén ten un interruptor de optimización de "axustar a zerolatencia"). Unha optimización tan sinxela pode reducir a latencia porque pode codificar o vídeo con taxa de fotogramas completa a unha taxa de bits inferior.
5. Se se usa ffmpeg, reduza os valores de "- probe" e "- analiza a duración", que se usan para a monitorización da información de cadros de vídeo e o tempo de supervisión. Canto maiores sexan os dous valores, maior será o impacto sobre o atraso de codificación. Na escena en directo, nin sequera é necesario establecer o parámetro de duración de análise para o fluxo de vídeo.
6. A codificación de taxa fixa CBR pode eliminar a influencia da fluctuación de rede ata certo punto. Se se pode usar a codificación de taxa variable VBR, pode aforrar un ancho de banda de rede innecesario e reducir certo atraso. Polo tanto, suxírese que se use VBR para codificar o máximo posible.
Optimización do protocolo de transporte
1. Probe a usar RTMP en lugar do protocolo HLS baseado en HTTP para a transmisión entre nodos do servidor, o que pode reducir o atraso global da transmisión. Isto está dirixido principalmente aos usuarios finais que usan HLS para xogar.
2. Se o usuario final usa RTMP para reproducir, a transcodificación debe realizarse no nodo receptor próximo ao extremo de transmisión, de xeito que a transmisión de vídeo transmitida sexa menor que a transmisión de vídeo orixinal.
3. Se é necesario, pódese utilizar o protocolo UDP personalizado para substituír o protocolo TCP e pódese eliminar a retransmisión de perda de paquetes baixo o enlace de rede débil, o que pode reducir o atraso. A súa principal desvantaxe é que a transmisión e distribución de fluxo de vídeo personalizado baseado no protocolo UDP non é suficientemente universal e os fabricantes de CDN admiten o protocolo de transmisión estándar. Outra desvantaxe é que pode haber salpicaduras ou desenfoques causados pola perda de paquetes (falta de referencia de decodificación de fotogramas clave), o que require que a parte de personalización do protocolo faga un bo traballo no control da perda de paquetes en base a UDP.
Optimización da rede de transmisión
1. Introducimos a rede de transmisión en tempo real, que é un novo tipo de rede de transmisión de rede con nodos autoorganizados. Non só é adecuado para a optimización da transmisión da rede doméstica de múltiples operadores, senón tamén para as necesidades de moitas emisións en directo no exterior.
2. Cache o GOP actual no nodo do servidor e colabore co reprodutor para optimizar o tempo de apertura do vídeo.
3. O servidor rexistra a taxa de fotogramas e o código de segundo nivel cando cada fluxo de vídeo flúe a cada ligazón en tempo real e controla a flutuación da taxa de código e a taxa de fotogramas en tempo real.
4. O cliente (push stream e play) obtén o nodo óptimo actual en tempo case real consultando o servidor (unha vez cada 5 segundos) e o nodo e liña de fallo actuais están sen conexión en tempo case real.
Streaming e optimización da reprodución
1. O sistema pode almacenar en caché datos antes de enviar datos. A afinación deste parámetro tamén precisa atopar un equilibrio.
2. O control do búfer do reprodutor tamén ten unha gran influencia no primeiro atraso do vídeo. Se só se optimiza o primeiro atraso, os datos pódense decodificar inmediatamente cando cheguen no caso de 0 buffer. Pero nun entorno de rede débil, para eliminar o impacto da fluctuación de rede, é necesario establecer unha determinada caché, polo que necesitamos atopar un equilibrio entre a estabilidade da transmisión en directo e a optimización do primeiro atraso aberto e axustar o tamaño do búfer optimizado.
3. Estratexia do búfer dinámico do xogador, que é unha versión mellorada do control de caché do xogador anterior. Se escollemos entre caché 0 e caché de tamaño fixo para atopar un equilibrio, eventualmente elixiremos unha caché de tamaño fixo, que non é xusto para 100 millóns de usuarios de terminais de internet móbiles. As súas diferentes condicións de rede determinan que a caché de tamaño fixo non é completamente adecuada. Polo tanto, podemos considerar unha "estratexia de buffer dinámico". Cando o xogador está acendido, usamos unha estratexia de buffer moi pequena ou incluso cero. O tamaño do búfer da seguinte parte do tempo está determinado polo tempo consumido para descargar o primeiro vídeo. Ao mesmo tempo, a rede actual contrólase en tempo real durante o proceso de reprodución e o tamaño do búfer axústase en tempo real durante o proceso de reprodución. Deste xeito, a primeira hora de apertura pode ser moi baixa e a influencia da fluctuación da rede pode eliminarse na medida do posible.
4. Estratexia de xogo de velocidade dinámica. Ademais da estratexia de axustar dinámicamente o tamaño do búfer, tamén podemos usar a información da rede de control en tempo real para axustar dinámicamente a taxa de bits no proceso de reprodución. No caso de un ancho de banda de rede insuficiente, podemos reducir a taxa de bits para reproducir e reducir o atraso.
O anterior forma parte das técnicas de optimización de baixa latencia. De feito, cando optimizamos unha latencia baixa, non só nos centramos na "baixa latencia", senón que intentamos acadar unha baixa latencia a condición de que outras condicións non afecten a experiencia do usuario. Polo tanto, o seu contido implica unha ampla gama de temas.
|
Introduce o correo electrónico para obter unha 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 -> árabe
hy.fmuser.org -> Armenian
az.fmuser.org -> azerí
eu.fmuser.org -> éuscaro
be.fmuser.org -> bielorruso
bg.fmuser.org -> Búlgaro
ca.fmuser.org -> catalán
zh-CN.fmuser.org -> chinés (simplificado)
zh-TW.fmuser.org -> Chinés (tradicional)
hr.fmuser.org -> croata
cs.fmuser.org -> Checo
da.fmuser.org -> danés
nl.fmuser.org -> Holandés
et.fmuser.org -> estoniano
tl.fmuser.org -> filipino
fi.fmuser.org -> finés
fr.fmuser.org -> Francés
gl.fmuser.org -> galego
ka.fmuser.org -> xeorxiano
de.fmuser.org -> alemán
el.fmuser.org -> Grego
ht.fmuser.org -> crioulo haitiano
iw.fmuser.org -> Hebreo
hi.fmuser.org -> hindi
hu.fmuser.org -> Hungarian
is.fmuser.org -> islandés
id.fmuser.org -> indonesio
ga.fmuser.org -> irlandés
it.fmuser.org -> Italiano
ja.fmuser.org -> xaponés
ko.fmuser.org -> coreano
lv.fmuser.org -> letón
lt.fmuser.org -> Lituano
mk.fmuser.org -> macedonio
ms.fmuser.org -> malaio
mt.fmuser.org -> maltés
no.fmuser.org -> Norwegian
fa.fmuser.org -> persa
pl.fmuser.org -> polaco
pt.fmuser.org -> Portugués
ro.fmuser.org -> Romanés
ru.fmuser.org -> ruso
sr.fmuser.org -> serbio
sk.fmuser.org -> Eslovaco
sl.fmuser.org -> Esloveno
es.fmuser.org -> castelán
sw.fmuser.org -> Suahili
sv.fmuser.org -> Sueco
th.fmuser.org -> Thai
tr.fmuser.org -> turco
uk.fmuser.org -> ucraíno
ur.fmuser.org -> urdú
vi.fmuser.org -> Vietnamita
cy.fmuser.org -> galés
yi.fmuser.org -> Yiddish
FMUSER Wirless Transmit Video and Audio Máis fácil!
contacto
dirección:
No.305 Sala HuiLan Building No.273 Huanpu Road Guangzhou China 510620
categorías
boletín informativo