FMUSER Transmitir vídeo e áudio sem fio mais 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 -> armênio
az.fmuser.org -> Azerbaijão
eu.fmuser.org -> Basco
be.fmuser.org -> bielorrusso
bg.fmuser.org -> búlgaro
ca.fmuser.org -> catalão
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 -> dinamarquês
nl.fmuser.org -> holandês
et.fmuser.org -> estoniano
tl.fmuser.org -> filipino
fi.fmuser.org -> finlandês
fr.fmuser.org -> francês
gl.fmuser.org -> galego
ka.fmuser.org -> georgiano
de.fmuser.org -> alemão
el.fmuser.org -> grego
ht.fmuser.org -> crioulo haitiano
iw.fmuser.org -> hebraico
hi.fmuser.org -> Hindi
hu.fmuser.org -> húngaro
is.fmuser.org -> islandês
id.fmuser.org -> indonésio
ga.fmuser.org -> irlandês
it.fmuser.org -> italiano
ja.fmuser.org -> Japonês
ko.fmuser.org -> coreano
lv.fmuser.org -> letão
lt.fmuser.org -> Lituano
mk.fmuser.org -> macedônio
ms.fmuser.org -> malaio
mt.fmuser.org -> maltês
no.fmuser.org - norueguês
fa.fmuser.org -> persa
pl.fmuser.org -> polonês
pt.fmuser.org -> português
ro.fmuser.org -> romeno
ru.fmuser.org -> russo
sr.fmuser.org -> Sérvio
sk.fmuser.org -> Eslovaco
sl.fmuser.org -> esloveno
es.fmuser.org -> espanhol
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 -> iídiche
1. Introdução ao RTP
RTP é um protocolo de transmissão em tempo real que fornece serviço de transmissão ponta a ponta, que suporta a transmissão de dados em tempo real em serviço de rede de difusão de destino único e multi-objetivo, enquanto a transmissão de dados em tempo real é monitorada e controlada pelo protocolo RTCP.
2. RTP é definido em RFC
A aplicação que utiliza o protocolo RTP é executada em RTP, enquanto o programa que executa RTP é executado na camada superior do UDP, para utilizar o número da porta e verificar e do UDP. O RTP pode ser considerado uma subcamada da camada de transporte. Os blocos de dados de áudio e TV gerados por aplicativos de multimídia são encapsulados em pacotes RTP, cada pacote RTP é encapsulado no segmento de mensagem UDP e, em seguida, empacotado em pacotes IP.
A estrutura do pacote inclui vários domínios amplamente utilizados em multimídia, incluindo áudio sob demanda, vídeo sob demanda, telefone pela Internet e videoconferência. A especificação RTP não define padrões para formatos compactados de som e televisão e pode ser usada para transmitir arquivos em formato normal. Por exemplo, som em wav ou GSM (Sistema Global para comunicações móveis), MPEG-1 e MPEG-2 TV também podem ser usados para transmitir arquivos de som e TV armazenados em formatos proprietários.
Da perspectiva dos desenvolvedores de aplicativos, os executores RTP podem ser considerados como parte do aplicativo porque os desenvolvedores devem integrar o RTP ao aplicativo. Na extremidade de envio, os desenvolvedores devem escrever o programa que executa o protocolo RTP no programa aplicativo que cria o pacote de informações RTP e, em seguida, o programa aplicativo envia o pacote de informações RTP para a interface de soquete do UDP, conforme mostrado na Figura 2; Da mesma forma, os pacotes RTP são inseridos no aplicativo por meio da interface de soquete UDP no receptor. Portanto, os desenvolvedores devem escrever o programa que executa o protocolo RTP no aplicativo que extrai os dados de mídia do pacote RTP.
O artigo toma a RTP como exemplo para ilustrar seu processo de trabalho. Suponha que o som da fonte de som seja um som codificado em PCM de 64 kb / s, e suponha que o aplicativo leve 20 ms de dados codificados como um bloco, ou seja, 160 bytes de dados de som em um bloco de dados. O aplicativo precisa adicionar um título RTP a esses dados de som para gerar pacotes RTP, que incluem o tipo, número de sequência e carimbo de data / hora dos dados de som. Os pacotes RTP são então enviados para a interface do soquete UDP, onde são encapsulados nos pacotes UDP. No receptor, o programa de aplicação recebe o pacote de informações RTP da interface de socket, extrai o bloco de dados de som do pacote de informações RTP e então decodifica e reproduz o som corretamente usando as informações no campo de título do pacote RTP.
Se o aplicativo não usa soluções proprietárias para fornecer tipo de carga útil, número de sequência ou carimbo de data / hora, mas usa o protocolo RTP padrão, o aplicativo será mais fácil de ser executado com outros aplicativos de rede, que é o que todos esperam. Por exemplo, se duas empresas diferentes estão desenvolvendo software de telefone pela Internet, todas incorporam RTP em seus produtos, o que é uma esperança de que os usuários que usam software de telefone de outra empresa possam se comunicar.
É importante enfatizar que a RTP não fornece nenhum mecanismo para garantir que os dados sejam entregues ao receptor a tempo ou com outra qualidade de serviço. Isso não garante que o pacote de informações não seja perdido ou que a ordem dos pacotes não seja perturbada. Na verdade, o encapsulamento RTP só pode ser visto no lado do sistema. O roteador no meio não distingue que o datagrama IP carrega pacotes RTP.
O RTP permite que cada fonte de mídia seja atribuída a um fluxo de pacote RTP separado, como uma câmera ou microfone. Por exemplo, uma conferência de televisão com dois grupos envolvidos poderia abrir quatro fluxos de pacotes: duas câmeras transmitindo fluxos de TV e dois microfones para transmitir fluxos de som. No entanto, muitas tecnologias de codificação populares, incluindo MPEG-1 e MPEG-2, unem som e imagens de TV para formar um único fluxo de dados no processo de codificação e gerar um fluxo de pacote RTP em uma direção.
Os pacotes RTP não estão limitados à transmissão de destino único e também podem ser transmitidos em uma árvore de transmissão de vários destinos ou em uma árvore de transmissão de vários destinos. Por exemplo, transmissão de múltiplos alvos com múltiplos para muitos, nesta aplicação, todos os terminais de transmissão geralmente enviam seu fluxo de pacotes RTP para a árvore de transmissão de múltiplos objetivos com o mesmo endereço de transmissão de múltiplos objetivos.
3. Campo de cabeçalho do pacote RTP
O título RTP consiste em quatro campos de cabeçalho de pacote e outros domínios: domínio do tipo de carga útil, domínio do número de sequência, domínio do carimbo de data / hora e domínio do identificador da fonte de sincronização.
1) tipo de carga útil
O campo do tipo de carga útil no pacote RTP tem 7 bits de comprimento, então o RTP pode suportar 128 tipos diferentes de carga útil. Para fluxo de som, este campo é usado para indicar o tipo de codificação usada pelo som, como PCM, modulação delta adaptativa, codificação preditiva linear e assim por diante. Se o remetente decidir alterar o método de codificação durante a sessão ou transmissão, o remetente pode notificar o receptor por meio deste domínio. A Tabela 1 lista os tipos de cargas úteis de som que o RTP pode suportar no momento.
Para streams de TV, os tipos de carga útil podem ser usados para indicar o tipo de codificação de TV, como motion JPEG, MPEG-1, MPEG-2, h.231, etc. O remetente também pode alterar o método de codificação da TV a qualquer momento durante a sessão ou durante a sessão. A Tabela 16-02 lista alguns tipos de payloads de TV que o RTP pode suportar no momento.
2) número de série
O campo do campo do número de sequência tem 16 bits de comprimento. Adicione 1 a cada número de sequência de pacote RTP. O receptor pode usá-lo para verificar se o pacote está faltando e processar o pacote de acordo com o número de sequência. Por exemplo, o aplicativo receptor recebe um fluxo de pacotes RTP, que tem um intervalo entre os números de sequência 86 e 89, e o receptor sabe que os pacotes 87 e 88 foram perdidos e toma medidas para processar os dados perdidos.
3) carimbo de data / hora
O domínio do carimbo de data / hora tem 32 bytes. Ele reflete o tempo de amostragem (tempo) do primeiro byte no pacote RTP. O receptor pode usar este carimbo de data / hora para remover o jitter dos pacotes causado pela rede e fornecer função de sincronização para reprodução na extremidade receptora.
4) identificador de fonte de sincronização
O comprimento do domínio do identificador da fonte de sincronização (SSRC) é de 32 bits. É usado para identificar a origem do fluxo de pacotes RTP e cada fluxo de pacotes durante a sessão ou período RTP tem um SSRC claro. SSRC não é o endereço IP do remetente, mas um número atribuído aleatoriamente pela origem no início do novo fluxo de pacote.
|
Digite o e-mail para obter uma surpresa
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 -> armênio
az.fmuser.org -> Azerbaijão
eu.fmuser.org -> Basco
be.fmuser.org -> bielorrusso
bg.fmuser.org -> búlgaro
ca.fmuser.org -> catalão
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 -> dinamarquês
nl.fmuser.org -> holandês
et.fmuser.org -> estoniano
tl.fmuser.org -> filipino
fi.fmuser.org -> finlandês
fr.fmuser.org -> francês
gl.fmuser.org -> galego
ka.fmuser.org -> georgiano
de.fmuser.org -> alemão
el.fmuser.org -> grego
ht.fmuser.org -> crioulo haitiano
iw.fmuser.org -> hebraico
hi.fmuser.org -> Hindi
hu.fmuser.org -> húngaro
is.fmuser.org -> islandês
id.fmuser.org -> indonésio
ga.fmuser.org -> irlandês
it.fmuser.org -> italiano
ja.fmuser.org -> Japonês
ko.fmuser.org -> coreano
lv.fmuser.org -> letão
lt.fmuser.org -> Lituano
mk.fmuser.org -> macedônio
ms.fmuser.org -> malaio
mt.fmuser.org -> maltês
no.fmuser.org - norueguês
fa.fmuser.org -> persa
pl.fmuser.org -> polonês
pt.fmuser.org -> português
ro.fmuser.org -> romeno
ru.fmuser.org -> russo
sr.fmuser.org -> Sérvio
sk.fmuser.org -> Eslovaco
sl.fmuser.org -> esloveno
es.fmuser.org -> espanhol
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 -> iídiche
FMUSER Transmitir vídeo e áudio sem fio mais fácil!
Contato
Endereço:
No.305 Sala HuiLan Edifício No.273 Huanpu Road Guangzhou China 510620
Categorias
Newsletter