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
1. Introducción a RTP
RTP es un protocolo de transmisión en tiempo real que proporciona un servicio de transmisión de extremo a extremo, que admite la transmisión de datos en tiempo real en un servicio de red de transmisión de un solo objetivo y de transmisión de múltiples objetivos, mientras que la transmisión de datos en tiempo real es monitoreada y controlada por el protocolo RTCP.
2. RTP se define en RFC
La aplicación que utiliza el protocolo RTP se ejecuta en RTP, mientras que el programa que ejecuta RTP se ejecuta en la capa superior de UDP, para utilizar el número de puerto y comprobar y de UDP. RTP puede considerarse como una subcapa de la capa de transporte. Los bloques de datos de audio y TV generados por aplicaciones multimedia se encapsulan en paquetes RTP, cada paquete RTP se encapsula en un segmento de mensaje UDP y luego se empaqueta en paquetes IP.
La estructura del paquete incluye varios dominios ampliamente utilizados en multimedia, incluyendo audio a pedido, video a pedido, telefonía por Internet y videoconferencia. La especificación RTP no establece estándares para formatos comprimidos para sonido y televisión, y puede usarse para transmitir archivos en formato normal. Por ejemplo, el sonido en wav o GSM (sistema global para comunicaciones móviles), MPEG-1 y MPEG-2 TV también se pueden utilizar para transmitir archivos de sonido y TV almacenados en formatos propietarios.
Desde la perspectiva de los desarrolladores de aplicaciones, los ejecutores de RTP pueden considerarse parte de la aplicación porque los desarrolladores deben integrar RTP en la aplicación. En el extremo de envío, los desarrolladores deben escribir el programa que ejecuta el protocolo RTP en el programa de aplicación que crea el paquete de información RTP, y luego el programa de aplicación envía el paquete de información RTP a la interfaz de socket de UDP, como se muestra en la Figura 2; De manera similar, los paquetes RTP se ingresan a la aplicación a través de la interfaz de conector UDP en el receptor. Por lo tanto, los desarrolladores deben escribir el programa que ejecuta el protocolo RTP en la aplicación que extrae los datos multimedia del paquete RTP.
El documento toma RTP como ejemplo para ilustrar su proceso de trabajo. Suponga que el sonido de la fuente de sonido es un sonido codificado PCM de 64 kb / s, y suponga que la aplicación toma 20 ms de datos codificados como un fragmento, es decir, 160 bytes de datos de sonido en un bloque de datos. La aplicación necesita agregar un título RTP a estos datos de sonido para generar paquetes RTP, que incluyen el tipo, número de secuencia y marca de tiempo de los datos de sonido. Luego, los paquetes RTP se envían a la interfaz de socket UDP, donde se encapsulan en los paquetes UDP. En el receptor, el programa de aplicación recibe el paquete de información RTP de la interfaz del conector, extrae el bloque de datos de sonido del paquete de información RTP y luego decodifica y reproduce el sonido correctamente usando la información en el campo de título del paquete RTP.
Si la aplicación no usa soluciones propietarias para proporcionar el tipo de carga útil, el número de secuencia o la marca de tiempo, pero usa el protocolo RTP estándar, la aplicación será más fácil de ejecutar con otras aplicaciones de red, que es lo que todos esperan. Por ejemplo, si dos empresas diferentes están desarrollando software de telefonía por Internet, todas incorporan RTP en sus productos, lo que es de esperar que los usuarios que utilizan software de telefonía de empresa diferente puedan comunicarse.
Es importante enfatizar que RTP no proporciona ningún mecanismo para asegurar que los datos se entreguen al receptor a tiempo o con otra calidad de servicio. No garantiza que el paquete de información no se pierda o que no se altere el orden de los paquetes. De hecho, la encapsulación RTP solo se puede ver en el lado del sistema. El enrutador en el medio no distingue que el datagrama IP lleva paquetes RTP.
RTP permite que se asigne a cada fuente de medios un flujo de paquetes RTP independiente, como una cámara o un micrófono. Por ejemplo, una conferencia de televisión con dos grupos involucrados podría abrir cuatro transmisiones de paquetes: dos cámaras que transmiten transmisiones de TV y dos micrófonos para transmitir transmisiones de sonido. Sin embargo, muchas tecnologías de codificación populares, incluidas MPEG-1 y MPEG-2, unen imágenes de TV y sonido para formar un único flujo de datos en el proceso de codificación y generan un flujo de paquetes RTP en una dirección.
Los paquetes RTP no se limitan a la transmisión de un solo objetivo, y también se pueden transmitir en uno a muchos árboles de transmisión de múltiples destinos o en un árbol de transmisión de varios a muchos de múltiples destinos. Por ejemplo, la transmisión de múltiples objetivos con múltiples a muchos, en esta aplicación, todos los terminales de transmisión normalmente envían su flujo de paquetes RTP al árbol de transmisión de múltiples objetivos con la misma dirección de transmisión de múltiples objetivos.
3. Campo de encabezado del paquete RTP
El título de RTP consta de cuatro campos de encabezado de paquete y otros dominios: dominio de tipo de carga útil, dominio de número de secuencia, dominio de marca de tiempo y dominio de identificador de fuente de sincronización.
1) tipo de carga útil
El campo de tipo de carga útil en el paquete RTP tiene una longitud de 7 bits, por lo que RTP puede admitir 128 tipos de carga útil diferentes. Para el flujo de sonido, este campo se utiliza para indicar el tipo de codificación que utiliza el sonido, como PCM, modulación delta adaptativa, codificación predictiva lineal, etc. Si el remitente decide cambiar el método de codificación durante la sesión o difusión, el remitente puede notificar al receptor a través de este dominio. La Tabla 1 enumera los tipos de cargas útiles de sonido que RTP puede admitir en la actualidad.
Para transmisiones de TV, los tipos de carga útil se pueden usar para indicar el tipo de codificación de TV, como Motion JPEG, MPEG-1, MPEG-2, h.231, etc. El remitente también puede cambiar el método de codificación de TV en cualquier momento durante la sesión o durante la sesión. La Tabla 16-02 enumera algunos tipos de cargas útiles de TV que RTP puede admitir en la actualidad.
2) número de serie
El campo del campo de número de secuencia tiene una longitud de 16 bits. Agregue 1 a cada número de secuencia de paquete RTP. El receptor puede usarlo para verificar si falta el paquete y procesar el paquete de acuerdo con el número de secuencia. Por ejemplo, la aplicación receptora recibe un flujo de paquetes RTP, que tiene un intervalo entre los números de secuencia 86 y 89, y el receptor sabe que los paquetes 87 y 88 se han perdido y toma medidas para procesar los datos perdidos.
3) marca de tiempo
El dominio de la marca de tiempo tiene una longitud de 32 bytes. Refleja el tiempo de muestreo (tiempo) del primer byte del paquete RTP. El receptor puede usar esta marca de tiempo para eliminar la fluctuación de los paquetes causada por la red y proporcionar la función de sincronización para la reproducción en el extremo receptor.
4) identificador de fuente de sincronización
La longitud del dominio del identificador de fuente de sincronización (SSRC) es de 32 bits. Se utiliza para identificar el origen del flujo de paquetes RTP, y cada flujo de paquetes durante la sesión o período RTP tiene un SSRC claro. SSRC no es la dirección IP del remitente, sino un número asignado aleatoriamente por la fuente al comienzo del nuevo flujo de paquetes.
|
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