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
1. Introdución a RTP
RTP é un protocolo de transmisión en tempo real que ofrece servizo de transmisión de extremo a extremo, que admite a transmisión de datos en tempo real no servizo de rede de transmisión de destino único e de obxectivos múltiples, mentres que a transmisión de datos en tempo real está supervisada e controlada polo protocolo RTCP.
2. RTP defínese en RFC
A aplicación que usa protocolo RTP execútase en RTP, mentres que o programa que executa RTP execútase na capa superior de UDP, co fin de usar o número de porto e comprobar e de UDP. RTP pode considerarse como unha sub capa da capa de transporte. Os bloques de datos de audio e TV xerados por aplicacións multimedia encapsúlanse en paquetes RTP, cada paquete RTP encapsúlase no segmento de mensaxes UDP e despois empaquétanse en paquetes IP.
A estrutura do paquete inclúe varios dominios moi empregados en multimedia, incluíndo audio baixo demanda, vídeo baixo demanda, teléfono por Internet e videoconferencia. A especificación RTP non establece estándares para formatos comprimidos para son e televisión e pode usarse para transmitir ficheiros en formato normal. Por exemplo, o son en wav ou GSM (sistema global para comunicacións móbiles), MPEG-1 e MPEG-2 TV tamén se poden usar para transmitir ficheiros de son e TV almacenados en formatos propietarios.
Desde a perspectiva dos desenvolvedores de aplicacións, os executores de RTP poden considerarse como parte da aplicación porque os desenvolvedores deben integrar RTP na aplicación. Ao final do envío, os desenvolvedores deben escribir o programa que executa o protocolo RTP no programa de aplicación que crea o paquete de información RTP e, a continuación, o programa envía o paquete de información RTP á interface de socket de UDP, como se mostra na Figura 2; Do mesmo xeito, os paquetes RTP introdúcense na aplicación a través da interface de socket UDP no receptor. Polo tanto, os desenvolvedores deben escribir o programa que executa o protocolo RTP na aplicación que extrae datos multimedia do paquete RTP.
O artigo toma RTP como exemplo para ilustrar o seu proceso de traballo. Supoñamos que o son da fonte de son é un son codificado por PCM de 64 kb / s e supoñamos que a aplicación leva 20 ms de datos codificados como un fragmento, é dicir, 160 bytes de datos de son nun bloque de datos. A aplicación precisa engadir título RTP a estes datos de son para xerar paquetes RTP, que inclúen o tipo, o número de secuencia e a marca de tempo dos datos de son. Os paquetes RTP envíanse entón á interface de socket UDP, onde están encapsulados nos paquetes UDP. No receptor, o programa de aplicación recibe o paquete de información RTP da interface de socket, extrae o bloque de datos de son do paquete de información RTP e, a continuación, descodifica e reproduce o son correctamente usando a información no campo de título do paquete RTP.
Se a aplicación non usa solucións privadas para proporcionar tipo de carga útil, número de secuencia ou marca de tempo, pero usa o protocolo RTP estándar, a aplicación será máis fácil de executar con outras aplicacións de rede, o que todos esperan. Por exemplo, se dúas empresas diferentes están a desenvolver software de telefonía por Internet, todas incorporan RTP aos seus produtos, o que espera que os usuarios que utilicen software de teléfono de empresa diferente poidan comunicarse.
É importante resaltar que RTP non ofrece ningún mecanismo para garantir que os datos se envíen ao receptor a tempo ou noutra calidade de servizo. Non garante que non se perda o paquete de información nin se perturbe a orde dos paquetes. De feito, a encapsulación RTP só se pode ver no lado do sistema. O enrutador do medio non distingue que o datagrama IP leva paquetes RTP.
RTP permite asignar a cada fonte multimedia un fluxo de paquetes RTP separado, como unha cámara ou un micrófono. Por exemplo, unha conferencia de televisión con dous grupos implicados podería abrir catro fluxos de paquetes: dúas cámaras que transmiten fluxos de TV e dous micrófonos para transmitir fluxos de son. Non obstante, moitas tecnoloxías de codificación populares, incluíndo MPEG-1 e MPEG-2, unen imaxes de son e TV xuntas para formar un único fluxo de datos no proceso de codificación e xeran un fluxo de paquetes RTP nunha dirección.
Os paquetes RTP non están limitados á transmisión de destino único e tamén se poden transmitir nunha árbore de transmisión de varios destinos ou árbore de difusión de varios destinos. Por exemplo, a emisión de múltiples destinos con varios a moitos, nesta aplicación, todos os terminais transmisores normalmente envían o seu fluxo de paquetes RTP á árbore de emisión de múltiples obxectivos co mesmo enderezo de emisión de múltiples obxectivos.
3. Campo de cabeceira de paquetes RTP
O título RTP consta de catro campos de cabeceira de paquetes e outros dominios: dominio de tipo de carga útil, dominio de número de secuencia, dominio de marca de tempo e dominio identificador de orixe de sincronización.
1) tipo de carga útil
O campo tipo de carga útil do paquete RTP ten 7 bits de lonxitude, polo que RTP pode soportar 128 tipos de carga útil diferentes. Para o fluxo de son, este campo úsase para indicar o tipo de codificación empregada polo son, como PCM, modulación delta adaptativa, codificación predictiva lineal, etc. Se o remitente decide cambiar o método de codificación durante a sesión ou emisión, o remitente pode notificarlle ao receptor a través deste dominio. A táboa 1 lista os tipos de cargas útiles de son que RTP pode soportar actualmente.
Para as transmisións de TV, pódense usar tipos de carga útil para indicar o tipo de codificación de TV, como JPEG en movemento, MPEG-1, MPEG-2, h.231, etc. O remitente tamén pode cambiar o método de codificación da TV en calquera momento durante a sesión ou durante a sesión. A táboa 16-02 lista algúns tipos de carga útil de TV que RTP pode soportar actualmente.
2) número de serie
O campo do número de secuencia ten 16 bits de longo. Engade 1 a cada número de secuencia de paquetes RTP. O receptor pode usalo para comprobar se falta o paquete e procesalo segundo o número de secuencia. Por exemplo, a aplicación receptora recibe un fluxo de paquetes RTP, que ten un intervalo entre os números de secuencia 86 e 89 e o receptor sabe que se perderon os paquetes 87 e 88 e toma medidas para procesar os datos perdidos.
3) marca de tempo
O dominio de marca de tempo ten unha lonxitude de 32 bytes. Reflicte o tempo de mostraxe (tempo) do primeiro byte no paquete RTP. O receptor pode usar esta marca de tempo para eliminar a fluctuación dos paquetes causada pola rede e proporcionar a función de sincronización para a reprodución no extremo receptor.
4) identificador de orixe de sincronización
A lonxitude do dominio do identificador de orixe de sincronización (SSRC) é de 32 bits. Úsase para identificar a orixe do fluxo de paquetes RTP e cada fluxo de paquetes durante a sesión ou período RTP ten un SSRC claro. SSRC non é a dirección IP do remitente, senón un número asignado aleatoriamente pola fonte ao comezo do novo fluxo de paquetes.
|
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