FMUSER ¡Transmite video y audio sin cables más fácilmente!
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Afrikáans
sq.fmuser.org -> albanés
ar.fmuser.org -> árabe
hy.fmuser.org -> Armenio
az.fmuser.org -> azerbaiyano
eu.fmuser.org -> Vasco
be.fmuser.org -> bielorruso
bg.fmuser.org -> Bulgaria
ca.fmuser.org -> catalán
zh-CN.fmuser.org -> chino (simplificado)
zh-TW.fmuser.org -> Chino (tradicional)
hr.fmuser.org -> croata
cs.fmuser.org -> checo
da.fmuser.org -> danés
nl.fmuser.org -> Holandés
et.fmuser.org -> estonio
tl.fmuser.org -> filipino
fi.fmuser.org -> finlandés
fr.fmuser.org -> Francés
gl.fmuser.org -> gallego
ka.fmuser.org -> georgiano
de.fmuser.org -> alemán
el.fmuser.org -> Griego
ht.fmuser.org -> criollo 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 -> japonés
ko.fmuser.org -> coreano
lv.fmuser.org -> letón
lt.fmuser.org -> Lituania
mk.fmuser.org -> macedonio
ms.fmuser.org -> malayo
mt.fmuser.org -> maltés
no.fmuser.org -> Noruega
fa.fmuser.org -> persa
pl.fmuser.org -> polaco
pt.fmuser.org -> portugués
ro.fmuser.org -> Rumano
ru.fmuser.org -> ruso
sr.fmuser.org -> serbio
sk.fmuser.org -> eslovaco
sl.fmuser.org -> Eslovenia
es.fmuser.org -> español
sw.fmuser.org -> Swahili
sv.fmuser.org -> sueco
th.fmuser.org -> Tailandés
tr.fmuser.org -> turco
uk.fmuser.org -> ucraniano
ur.fmuser.org -> Urdu
vi.fmuser.org -> Vietnamita
cy.fmuser.org -> galés
yi.fmuser.org -> Yiddish
Descripción general de la transmisión:
Los denominados medios de transmisión en continuo se refieren al formato de medios reproducidos en Internet mediante transmisión en continuo.
La transmisión de medios también se denomina transmisión de medios. Se refiere a empresas que utilizan un servidor de entrega de video para enviar programas como paquetes de datos y entregarlos a la red.
Después de que el usuario descomprime los datos a través del dispositivo de descompresión, el programa se mostrará como antes de la transmisión.
La transmisión de medios transmite archivos de audio, video y multimedia en forma de transmisión a través de la red.
El formato de archivo de transmisión de medios es un formato de medios que admite transmisión y reproducción.
El método de transmisión consiste en dividir archivos multimedia como video y audio en paquetes comprimidos a través de un método de compresión especial.
Transmisión continua y en tiempo real desde el servidor al ordenador del usuario. En los sistemas que utilizan la transmisión por secuencias, los usuarios no tienen que esperar por todo el archivo, como la reproducción sin transmisión.
El contenido se puede ver después de que se hayan completado todas las descargas, pero solo se pueden usar unos pocos segundos o decenas de segundos de demora de inicio en la computadora del usuario
El reproductor correspondiente reproduce el video o audio comprimido y otros archivos multimedia de transmisión, y la parte restante continuará descargándose hasta que se complete la reproducción.
1. RTP: (Protocolo de transporte en tiempo real)
Es un protocolo de capa de transporte para la transmisión de datos multimedia en Internet. El protocolo RTP y el protocolo de control RTP RTCP se utilizan juntos,
Y está construido sobre el protocolo UDP.
RTP no es como http y ftp que pueden descargar el archivo de película completo por completo. Envía datos en la red a una velocidad de datos fija. El cliente también ve el archivo de película a esta velocidad.
Una vez que se ha reproducido la pantalla de película, no se puede reproducir repetidamente, a menos que los datos se soliciten nuevamente al servidor.
2. RTCP: Protocolo de control de transporte en tiempo real o Protocolo de control RTP o RTCP para abreviar)
El protocolo de control de transmisión en tiempo real es un protocolo hermano del protocolo de transmisión en tiempo real (RTP).
Nota: -: el protocolo RTP y el protocolo de control RTP (RTCP) se utilizan juntos y se basa en el protocolo UDP (normalmente utilizado para videoconferencias)
3. RTSP: (Protocolo de transmisión en tiempo real)
Protocolo de sesión de medios de transmisión en tiempo real, SDP (protocolo de descripción de sesión), RTP (protocolo de transporte en tiempo real).
Es un protocolo de transmisión multimedia que se utiliza para controlar el sonido o el video. RTSP proporciona un marco extensible que hace posible el control y los datos en tiempo real bajo demanda, como audio y video.
Los datos de los medios utilizan los protocolos rtp y rtcp. Generalmente use udp como capa de transporte. Adecuado para escenas de IPTV. Las fuentes de datos incluyen datos en vivo y datos almacenados en clips. El propósito de este protocolo es controlar múltiples conexiones de transmisión de datos, proporcionar una forma de seleccionar canales de transmisión, como UDP, multidifusión UDP y TCP, y proporcionar métodos para seleccionar un mecanismo de transmisión basado en RTP. El protocolo de comunicación de red utilizado durante la transmisión no está dentro del alcance de su definición. El servidor puede optar por utilizar TCP o UDP para transmitir el contenido de transmisión, que es más tolerante con los retrasos de la red.
--->: La mayor diferencia entre RTSP y RTP es que: RTSP es un protocolo de transmisión de datos bidireccional en tiempo real, que permite al cliente enviar solicitudes al servidor, como operaciones de reproducción, avance rápido y retroceso. Cuándo
Por supuesto, RTSP puede transmitir datos basados en RTP, y también puede elegir TCP, UDP, multidifusión UDP y otros canales para enviar datos, lo que tiene una buena escalabilidad. Es similar al protocolo http
Protocolo de capa de aplicación de red.
4. WebRTC:
El lado web implementa el protocolo de transmisión de medios. Cuando Google lanzó WebRTC por primera vez, los gigantes estaban sentados al margen o resistiéndose. Utilice la transmisión del protocolo RTP.
5. RTMP (Protocolo de mensajería en tiempo real)
Un conjunto de protocolos de video en vivo desarrollados por Macromedia ahora es propiedad de Adobe. Al igual que HLS, se puede aplicar a video en vivo y no se perderá según TCP.
// La diferencia es que RTMP no se puede reproducir en el navegador iOS basado en flash, pero el rendimiento en tiempo real es mejor que HLS.
El protocolo de mensajería en tiempo real es un protocolo abierto desarrollado por Adobe Systems para la transmisión de audio, video y datos entre reproductores Flash y servidores.
// En el código de iOS, RTMP se usa generalmente para impulsar la transmisión. Puede usar la biblioteca de terceros librtmp-iOS para impulsar la transmisión. librtmp encapsula algunas API principales para que los usuarios llamen
El protocolo RTMP también requiere que el cliente y el servidor establezcan una conexión RTMP a través de un "protocolo de enlace" y luego transmitan información de control sobre la conexión. El protocolo RTMP formateará los datos durante la transmisión. En la transmisión real, para lograr una mejor multiplexación, subenvasado y equidad de la información, el remitente dividirá el mensaje en fragmentos con ID de mensaje, cada fragmento puede ser un solo mensaje,
También puede ser parte del Mensaje. El extremo receptor restaurará el fragmento a un mensaje completo de acuerdo con la longitud de los datos contenidos en el fragmento, la longitud de la identificación del mensaje y la longitud del mensaje, para realizar el envío y la recepción de información.
6. HLS: Transmisión en directo HTTP (HLS)
Es un protocolo de transmisión de medios de transmisión basado en HTTP implementado por Apple Inc., que puede realizar transmisión de medios en vivo y bajo demanda. Se utiliza principalmente en el sistema iOS y proporciona soluciones de audio y video en vivo y bajo demanda para dispositivos iOS (como iPhone y iPad). HLS bajo demanda es básicamente un HTTP segmentado común bajo demanda. La diferencia es que sus segmentos son muy pequeños. En comparación con los protocolos de transmisión en vivo de medios de transmisión comunes, como RTMP, RTSP, MMS, etc., la mayor diferencia en la transmisión en vivo de HLS es que lo que obtiene el cliente de transmisión en vivo no es un flujo de datos completo.
El protocolo HLS almacena el flujo de datos en vivo como archivos multimedia continuos de corta duración (formato MPEG-TS) en el lado del servidor, y el cliente descarga y reproduce continuamente estos pequeños archivos, porque el lado del servidor siempre actualizará la última transmisión en vivo. Los datos generan nuevos archivos pequeños, por lo que siempre que el cliente reproduzca continuamente los archivos obtenidos del servidor en secuencia, se realiza la transmisión en vivo. Puede verse que, básicamente, se puede considerar que HLS es una forma técnica de >> bajo demanda para realizar retransmisiones en directo <<. Dado que los datos se transmiten a través del protocolo HTTP, no es necesario considerar firewalls o proxies en absoluto.
Además, la duración del archivo segmentado es muy corta y el cliente puede seleccionar y cambiar rápidamente la tasa de bits para adaptarse a la reproducción en diferentes condiciones de ancho de banda. Sin embargo, esta característica técnica de HLS determina su
La demora siempre será mayor que la del protocolo de transmisión en vivo ordinario.
// Tanto iOS como Android, naturalmente, admiten este protocolo, la configuración es simple, solo use la etiqueta de video directamente
*** VLS: Es una especie de servidor de transmisión, que se utiliza especialmente para resolver diversos problemas de transmisión. También tiene algunas características de VLC. Como servidor, videolan puede generar flujos http, rtp, rtsp.
En principio, RTSP, RTMP y HTTP pueden usarse para transmisiones en vivo y transmisiones bajo demanda, pero generalmente RTSP y RTMP se usan para transmisiones en vivo y HTTP se usa para transmisiones bajo demanda. Lo que elegimos es el protocolo RTMP.
Varios retrasos en el protocolo y sus razones
rtmp y httpflv: los datos de estos dos protocolos son aproximadamente los mismos, por lo que las razones del retraso son las mismas. Es lógico que las transmisiones en vivo de transmisión de tcp tengan una latencia extremadamente baja. ¿Por qué rtmp y httpflv todavía tienen latencia? La razón es que en h264, rtmp y httpflv son etiquetas flv que se transmiten. Los datos de la etiqueta de vídeo suelen ser datos h264. La decodificación H264 tiene un IBP. Yo es un fotograma clave, que es una imagen completa. Debe tener una I antes de decodificar. Los últimos cuadros BP, BP pueden ser tan pocos como desee, pero los cuadros I no pueden ser menos, por lo que los cuadros I deben transmitirse en segundo lugar en la transmisión de etiquetas flv (el primero es h264spspps), pero los cuadros I no suelen estar presentes en los flujos h264, Hay un marco I después de un período de tiempo. Este período de tiempo se conoce comúnmente como GOP. Al codificar, el GOP se establece muy corto. Cuando el cliente se conecta, el servidor encontrará el fotograma I más cercano en la secuencia a la velocidad más rápida y lo enviará desde el fotograma I. Datos en vivo, pero cuando el GOP es muy largo, el intervalo de fotograma I es muy largo, o espere a que el siguiente fotograma I comience a enviar datos a la nueva conexión, o busque el fotograma I más cercano en el búfer para comenzar a enviar, aquí está el retardo de los protocolos rtmp y hls El punto clave es que en las principales plataformas CDN, se denomina "segunda tecnología de apertura rtmp". El principio es decodificar los datos push dos veces y establecer un pequeño gop. En general, gop se establece en 1s. Independientemente del retraso del enlace de transmisión de la red, el retraso máximo de datos es 1 s. Afortunadamente, el cuadro I tiene un retraso de 0!
|
Ingrese el correo electrónico para recibir una sorpresa
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Afrikáans
sq.fmuser.org -> albanés
ar.fmuser.org -> árabe
hy.fmuser.org -> Armenio
az.fmuser.org -> azerbaiyano
eu.fmuser.org -> Vasco
be.fmuser.org -> bielorruso
bg.fmuser.org -> Bulgaria
ca.fmuser.org -> catalán
zh-CN.fmuser.org -> chino (simplificado)
zh-TW.fmuser.org -> Chino (tradicional)
hr.fmuser.org -> croata
cs.fmuser.org -> checo
da.fmuser.org -> danés
nl.fmuser.org -> Holandés
et.fmuser.org -> estonio
tl.fmuser.org -> filipino
fi.fmuser.org -> finlandés
fr.fmuser.org -> Francés
gl.fmuser.org -> gallego
ka.fmuser.org -> georgiano
de.fmuser.org -> alemán
el.fmuser.org -> Griego
ht.fmuser.org -> criollo 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 -> japonés
ko.fmuser.org -> coreano
lv.fmuser.org -> letón
lt.fmuser.org -> Lituania
mk.fmuser.org -> macedonio
ms.fmuser.org -> malayo
mt.fmuser.org -> maltés
no.fmuser.org -> Noruega
fa.fmuser.org -> persa
pl.fmuser.org -> polaco
pt.fmuser.org -> portugués
ro.fmuser.org -> Rumano
ru.fmuser.org -> ruso
sr.fmuser.org -> serbio
sk.fmuser.org -> eslovaco
sl.fmuser.org -> Eslovenia
es.fmuser.org -> español
sw.fmuser.org -> Swahili
sv.fmuser.org -> sueco
th.fmuser.org -> Tailandés
tr.fmuser.org -> turco
uk.fmuser.org -> ucraniano
ur.fmuser.org -> Urdu
vi.fmuser.org -> Vietnamita
cy.fmuser.org -> galés
yi.fmuser.org -> Yiddish
FMUSER ¡Transmite video y audio sin cables más fácilmente!
Contacto
Dirección:
Habitación No.305 Edificio HuiLan No.273 Huanpu Road Guangzhou China 510620
Categorías
NEWSLETTER