Live555 proxy server binário opções

Estou usando o Live555 streaming media para um aplicativo que grava e transmite fluxos RTSP provenientes da câmera IP. Por isso, estou usando o OpenRTSP para gravação e servidor proxy live555 para re-streaming da transmissão da câmera. Para algumas das câmeras, estamos enfrentando um problema estranho onde a gravação da câmera acontece com sucesso, no entanto, o servidor proxy live555 não consegue gerar um novo fluxo para a mesma transmissão da câmera (não há indicação de falha no despejo da saída detalhada, No entanto, o URL rtsp gerado pelo servidor proxy não pode ser decodificado por um cliente rtsp). Como não tenho nenhuma ideia sobre os detalhes do servidor proxy live555, não consegui entrar neste problema. Eu tentei transmitir o mesmo fluxo de câmera usando o VLC e isso funciona bem. O que poderia ser possivelmente errado com isso. Estou aqui anexando a saída detalhada para referência. E :. LiveproxyServergtlive555ProxyServer. exe - V rtsp: 10.17.10.67ch0unicastfirststream LIVE555 Proxy Server (LIVE555 Streaming Media library version 2017.05.17) Abertura de conexão para 10.17.10.67, porta 554. RTSP stream, proxying the stream rtsp: 10.17.10.67ch0unicastfirststream Jogue este fluxo usando A URL rtsp: 10.17.1.150proxyStream (Nós usamos a porta 8000 para tunelamento opcional RTSP-over-HTTP). Conexão remota aberta Pedido de envio: DESCRIBE rtsp: 10.17.10.67ch0unicastfirststream RTSP1.0 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2017. 05.17) Recebeu 716 novos bytes de dados de resposta. Recebi uma resposta DESCRIBE completa: I e Saurabh estão trabalhando no mesmo projeto. Nós tentamos analisar o que está acontecendo usando o testRTSPClient conforme sugerido por você e aqui está o despejo detalhado do testRTSPClient: abertura de conexão para 10.17.1.111, porta 8554. conexão remota aberta Pedido de envio: DESCRIBE rtsp: 10.17.1.111: 8554proxyStream RTSP1 .0 msWin32DebugTestPrograms. exe (LIVE555 Streaming Media v2017.06.26) Recebeu 101 novos bytes de dados de resposta. Recebeu uma resposta DESCRIBE completa: RTSP1.0 404 Arquivo não encontrado ou em formato incorreto Data: Thu, Jul 05 2017 09:23:54 GMT URL: rtsp: 10.17.1.111: 8554proxyStream: Falha ao obter uma descrição SDP: 40 4 Arquivo não encontrado ou em URL de formato incorreto: rtsp: 10.17.1.111: 8554proxyStream: fechando o fluxo. Pressione qualquer tecla para continuar Parece que o servidor proxy do live555 não consegue fornecer uma resposta ao pedido DESCRIBE enviado do cliente (testRTSPClient). Qual poderia ser o motivo disso. Eu também adjunto o servidor de proxy live555 correspondente do despejo detalhado também para referência. LIVE555 Proxy Server (LIVE555 Streaming Media library versão 2017.06.26) Abertura de conexão para 10.17.10.67, porta 554. RTSP stream, proxying the stream rtsp: 10.17.10.67ch0unicastfirststream Jogue este fluxo usando o URL rtsp: 10.17.1.111: 8554proxyStream (Nós Use a porta 80 para o tunelamento opcional RTSP-over-HTTP.) Conexão remota aberta Pedido de envio: DESCRIBE rtsp: 10.17.10.67ch0unicastfirststream RTSP1.0 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2017.06.26) Recebeu 718 novos bytes de dados de resposta. Recebi uma resposta DESCRIBE completa: Data: Qui, Jul 05 2017 09:19:08 GMT 2017-07-06 05:58:23 UTC Obrigado pela sua resposta. Eu despejo informações de depuração que você sugeriu. Por favor, procure registrar abaixo. LOG INFO-START LIVE555 Servidor Proxy (LIVE555 Streaming Media library version 2017.06.26) Abertura de conexão para 10.17.10.56, porta 554. RTSP stream, proxying the rtsp rtsp: 10.17.10.56ch0unicastfirststream Jogue este fluxo usando o URL rtsp: 10.17.1.111 : 8554proxyStream (usamos a porta 80 para o tunelamento opcional RTSP-over-HTTP). Conexão remota aberta Pedido de envio: DESCRIBE rtsp: 10.17.10.56ch0unicastfirststreamRTSP1.0 CSeq: 2 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2017.06.26) Aceitar: applicationsdp Recebeu 716 novos bytes de dados de resposta. Recebeu uma resposta DESCRIBE completa: RTSP1.0 200 OK CSeq: 2 Data: Sex, Jul 06 2017 11:05:59 GMT Conteúdo Base: rtsp: 10.17.10.56ch0unicastfirststream Content-Type: applicationsdp Conteúdo-comprimento: 540 v0 o - 1341318888742256 1 IN IP4 10.17.10.56 sSessão do primeiro fluxo iFirst Codec Stream t0 0 atool: LIVE555 Streaming Media v2007.08.03 atype: broadcast acontrol: arange: npt0- ax-qt-text-nam: Sessão do primeiro fluxo ax-qt-text - inf: Primeiro Codec Stream mvideo 0 RTPAVP 96 cIN IP4 0.0.0.0 artpmap: 96 MP4V-ES90000 afmtp: 96 profile-level-id5config000001B005000001B509000001000000012000847A98 28A02240A31F acontrol: track1 mmetadata 0 RTPAVP 97 cIN IP4 0.0.0.0 artpmap: 97 METADATA64000 acontrol: track2 ProxyServerMediaSessionrtsp : 10.17.10.56ch0unicastfirststream adicionou novo ProxyServerMediaSubsession para RTPvideoMP4V-ES track ProxyServerMediaSessionrtsp: 10.17.10.56ch0unicastfirststream adicionou novo ProxyServerMediaSubsession para rTPmetadataMETADATA track Solicitação de envio: OPTIONS rtsp: 10.17.10.56ch0unicast FirststreamRTSP1.0 CSeq: 3 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2017.06.26) Recebeu 122 novos bytes de dados de resposta. Recebeu uma resposta completa às OPÇÕES: RTSP1.0 200 OK CSeq: 3 Data: Sex, Jul 06 2017 11:06:33 GMT Público: OPÇÕES, DESCRIÇÃO, CONFIGURAÇÃO, TECIDO, JOGO, PAUSA aceita () ed conexão de 10.17.1.111 Liveness Indicação do cliente em 10.17.1.111 Indicação de Liveness do cliente em 10.17.1.111 RTSPClientSession02060068 :: handleRequestBytes () lê 161 novos bytes: DESCRIBE rt sp: 10.17.1.111: 8554proxyStream RTSP1.0 CSeq: 2 User-Agent: testRTSPClient. exe (LIVE555 Streaming Media v2017.05.11) Aceite: applicationsdp parseRTSPRequestString () foi bem sucedido, retornando cmdName DESCRIBE, urlPreSuffix, urlSuffix proxyStream, CSeq 2, Content-Length 0, com 0 bytes após a mensagem. ProxyServerMediaSubsessionMP4V-ES :: createNewStreamSource (ID da sessão 0) Iniciado: ProxyServerMediaSubsessionMP4V-ES ProxyServerMediaSubsessionMP4V-ES :: createNewRTPSink () ProxyServerMediaSubsessionMP4V-ES :: closeStreamSource () ProxyServerMediaSubsessionMETADATA :: createNewStreamSource (ID da sessão 0) Iniciado: ProxyServerMediaSubsessionMETADATA enviando resposta: RTSP1.0 404 Arquivo não encontrado ou em formato incorreto CSeq: 2 Data: sex, 06 de julho de 2017 05:38:16 GMT Indicação de vida do cliente em 10.17.1.111 RTSPClientSession02060068 :: handleRequestBytes () ler 0 novos bytes (de 10000) t erminating connection Solicitação de envio: OPTIONS rtsp: 10.17.10.56ch0unicastfirststreamRTSP1.0 CSeq: 4 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2017.06.26) Recebeu 122 novos bytes de dados de resposta. Recebeu uma resposta OPÇÕES completa: RTSP1.0 200 OK CSeq: 4 Data: Fri, Jul 06 2017 11:07:10 GMT Público: OPÇÕES, DESCRIÇÃO, CONFIGURAÇÃO, TECIDO, JOGO, PAUSA Abertura de conexão ao 10.17.10.56, porta 554. . Conexão remota aberta Solicitação de envio: OPÇÕES rtsp: 10.17.10.56ch0unicastfirststreamRTSP1.0 CSeq: 5 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2017.06.26) Recebeu 122 novos bytes de dados de resposta. Recebeu uma resposta OPÇÕES completa: RTSP1.0 200 OK CSeq: 5 Data: sex, 06 de julho de 2017 11:08:09 GMT Público: OPÇÕES, DESCRIÇÃO, CONFIGURAÇÃO, TREINAMENTO, JOGO, PAUSA Eu verifiquei informações de depuração de RTSPServer. cpp é Efetuado É continuar a imprimir para outra câmera de trabalho (imprime a indicação Liveness do cliente em 10.17.1.111 ..) No registro atual também uma vez que imprime a indicação Liveness do cliente em 10.17.1.111. E no testRTSPClient está dando o seguinte log que é semelhante à conexão de abertura do LOG anterior ao 10.17.1.111, porta 8554.. Conexão remota aberta Pedido de envio: DESCRIBE rtsp: 10.17.1.111: 8554proxyStream RTSP1.0 CSeq: 2 User-Agent: testRTSPClient. exe (LIVE555 Streaming Media v2017.05.11) Aceitar: applicationsdp Recebido 101 novos bytes de dados de resposta. Recebeu uma resposta DESCRIBE completa: RTSP1.0 404 Arquivo Não Encontrado, Ou Em Formato Incorreto CSeq: 2 Data: Sex, Jul 06 2017 05:53:08 GMT Postagem por Ross Finlayson Isso é muito estranho. Não entendo por que o servidor proxy está respondendo 404 File Not Found. Aos pedidos do cliente. 1 Edite liveMediaRTSPServer. cpp e adicione a linha define DEBUG 1 para o início do arquivo. 2 Recompile a biblioteca liveMedia. 3 Na biblioteca proxyServer, re-make o live555ProxyServer binário. 4 Execute live555ProxyServer - V ltback-end-rtsp-URLgt mais uma vez e tente conectar-se ao cliente. Envie-nos a saída de depuração do servidor proxy. Ross Finlayson Live Networks, Inc. Live555 Live-devel mailing list lists. live555mailmanlistinfolive-devel Obrigado pelo seu apoio rápido. Está funcionando agora. Também nos informa que o mesmo tipo, a mesma configuração que a câmera diferente possui metadados diferentes. Postado por Ross Finlayson OK, descobri o problema - foi causado pela faixa de metadados não padrão no fluxo de back-end. Como esta faixa não é padrão, não podemos representar isso, mas isso não deveria ter confirmado o outro, a faixa de vídeo padrão não era proxied. Ive agora instalou uma nova versão 2017.07.06 do software LIVE555 Streaming Media que deve solucionar esse problema. Agora, seu cliente frontal deve poder receber a faixa de vídeo OK. Obrigado por levar essa questão à nossa atenção. Ross Finlayson Live Networks, Inc. Live555 Live-devel mailing list lists. live555mailmanlistinfolive-devel 2017-07-14 05:22:32 UTC Nós agradeceríamos se você pudesse elaborar o que você quer dizer com metadados não padrão desde que estamos tentando Para relatar o mesmo problema ao nosso fornecedor de câmeras. Aguardando sua resposta. Obrigado. No sábado, 7 de julho de 2017 às 10:32, Kiran P. Thakkar Post de Kiran P. Thakkar Caro Ross, Obrigado pelo seu apoio rápido. Está funcionando agora. Também nos informa que o mesmo tipo, a mesma configuração que a câmera diferente possui metadados diferentes. Atenciosamente Kiran Post por Ross Finlayson OK, descobri o problema - foi causado pela faixa de metadados não padrão no fluxo de back-end. Como esta faixa não é padrão, não podemos representar isso, mas isso não deveria ter confirmado o outro, a faixa de vídeo padrão não era proxied. Ive agora instalou uma nova versão 2017.07.06 do software LIVE555 Streaming Media que deve solucionar esse problema. Agora, seu cliente frontal deve poder receber a faixa de vídeo OK. Obrigado por levar essa questão à nossa atenção. Ross Finlayson Live Networks, Inc. Live555 Live-devel mailing list lists. live555mailmanlistinfolive-devel live-devel mailing list lists. live555mailmanlistinfolive-devel 2017-07-17 00:05:31 UTCIm tentando transmitir vídeo rtsp via tcp usando o mplayer no Windows MinGW shell e depende da biblioteca de mídia de transmissão ao vivo555. As etapas que fiz foram: baixe o live555 streaming media src crie cada arquivo. mak no srclive (uso nmake f. mak via linha de comando, porque o meu VS2018 não reconhece os arquivos. mak). O processo de construção foi sucesso e o resultado é. Arquivos obj. O problema é a necessidade do mplayer. a arquivos para criar e a compilação não o criou. Eu realmente preciso dos arquivos. a Se assim for, como posso obtê-lo, existe algum outro método de construção que eu possa usar para resolver este. O Servidor Proxy LIVE555 TM O Servidor Proxy LIVE555 é um servidor RTSP unicast - criado a partir do software LIVE555 Streaming Media - Que atua como um proxy para um ou mais fluxos back-end unicast ou multicast RTSPRTP (ou seja, servidos por outro servidor (es)). O recurso principal de um servidor proxy é que ele lê cada fluxo de back-end apenas uma vez, independentemente de quantos clientes separados estão transmitindo a partir do servidor proxy. Isso torna o servidor proxy ideal, por exemplo, para transmitir a partir de uma câmera de vídeo habilitada para RTSP (que pode não ser capaz de lidar com mais de uma conexão por vez). Operação básica O LIVE555 Proxy Server é um aplicativo de linha de comando (ou seja, console). A maneira mais simples de executá-lo é digitar: onde lturlgt é um URL RTSP (ou seja, começando com rtsp :) de um fluxo de back-end (por exemplo, de uma câmera de vídeo). Após a inicialização, o servidor exibirá seu próprio rtsp: URL para o fluxo de proxy. Os clientes RTSP podem então usar este URL para jogar (ou seja, receber) o fluxo de proxy. O servidor pode atuar como um proxy para muitos fluxos de back-end - não apenas um. Se você inserir mais de um rtsp: URL na linha de comando, ou seja, o servidor - depois de iniciar - exibirá rtsp: URLs para proxying cada um. (Claro, você deve transmitir vários fluxos somente se tiver uma largura de banda de rede suficiente para receber todos eles). Saída Verbose (depuração) Para exibir a saída adicional, mostrando a operação básica do servidor, adicione a opção - v antes do rtsp : URLs. Para exibir ainda mais saída - incluindo a troca de protocolo RTSP entre o servidor proxy e cada um dos servidores back-end - use a opção - V (ou seja, em maiúsculas e minúsculas) em vez disso. (Se você estiver tendo problemas com o servidor proxy, então recomendamos usar a opção - V para tentar descobrir o que está errado.) Transmissão de back-end sobre TCP Por padrão, o servidor proxy solicitará receber cada fluxo de back-end através de UDP (ou seja, recebendo pacotes RTP e RTCP como datagramas UDP). Às vezes, no entanto, o servidor back-end pode estar por trás de um firewall que bloqueia pacotes UDP. Para superar isso, você pode usar a opção - t para solicitar que cada servidor RTSP back-end transmita pacotes de dados RTP e RTCP em sua conexão TCP, ao invés de usar pacotes UDP. (Note que nem todos os servidores RTSP suportam transmissão TCP e que o TCP não pode ser usado para receber fluxos multicast.) Você deve usar essa opção somente se você não conseguir receber pacotes UDP, pois transmitir através de TCP pode causar atrasos excessivos nos dados recebidos . Alternativamente, você pode usar a opção - T lthttp-port-numbergt para solicitar que cada fluxo de back-end seja enviado (usando TCP) em um túnel RTSP-over-HTTP, usando o número de porta HTTP especificado. O tunelamento RTSP-over-HTTP pode ser útil se você estiver atrás de um firewall apenas para HTTP. (Note, no entanto, que nem todos os servidores RTSP back-end suportarão isso.) Nota: As opções - t e - T lthttp-port-numbergt aplicam-se apenas ao (s) fluxo (s) de back-end. Eles não afetam os fluxos front-end do servidor proxy para (potencialmente múltiplos) clientes RTSP. Esses fluxos podem ser sobre UDP ou TCP, dependendo do que cada cliente solicita. Proxy de fluxos controlados por acesso Alguns servidores RTSP back-end exigem autenticação de usuário (por meio de um nome de usuário e senha) antes de poder acessar seu fluxo. Se você adicionar a opção - u ltusernamegt ltpasswordgt ao servidor proxy, então ele usará esse par de ltusernamegt ltpasswordgt - se necessário - para acessar cada fluxo de back-end. (Para especificar uma senha vazia, use para ltpasswordgt.) Como alternativa, você poderia tentar incluir o nome do usuário e a senha dentro do rtsp: URL, como: rtsp: ltusernamegt: ltpasswordgt lthostnamegt: ltetc. gt. (Isso não é recomendado, no entanto, porque - neste caso - a senha será enviada no clear over the Internet. Além disso, nem todos os servidores back-end aceitarão esse tipo de URL.) Observe que também é possível fornecer Controle de acesso ao próprio servidor proxy - ou seja, de clientes RTSP front-end. (Isso, no entanto, não é feito a partir da linha de comando, é feito modificando o código-fonte do servidor proxy. Observe o código incluído em live555ProxyServer. cpp. Especificando uma porta do servidor RTSP Por padrão, este aplicativo do servidor tenta Use um dos números de porta do servidor RTSP padrão (554 e 8554). Alternativamente, você pode usar a opção - p ltrtsp-port-numbergt para especificar que o servidor tente usar o número de porta especificado para RTSP. (Se esta porta não pode ser Usado, tentará um dos números de porta padrão, como de costume.) Proxying um ou mais fluxos de back-end anunciados Esta aplicação de servidor também pode configurar proxying para um fluxo de back-end que é anunciado usando um comando REGISTER RTSP. O anúncio - que especifica o rtsp: URL do fluxo de back-end - pode ser enviado pelo próprio servidor de back-end ou por algum aplicativo de terceiros.) Para dar ao aplicativo do servidor essa funcionalidade, comece-o com o - R Opção de linha de comando. (Se você usar essa opção, então Você pode omitir entrar em qualquer rtsp: URLs na linha de comando.) O fluxo de proxy será acessível - a partir do servidor proxy - usando um rtsp: URL que será anunciado no console. Como uma característica especial - se o parâmetro de reutilização foi configurado nos comandos REGISTER Transporte: cabeçalho - o servidor proxy consegue reutilizar a conexão TCP na qual recebeu o comando REGISTER. Isso pode ser útil se o servidor back-end streams estiver por trás de um firewall ou NAT, mas o servidor proxy é executado na Internet pública. (Neste caso, você também pode usar a opção - t, para solicitar que o servidor back-end também envie seus pacotes RTPRTCP nesta mesma conexão TCP.) REGISTER é um comando RTSP personalizado, desenvolvido pela Live Networks, Inc. Atualmente não é padrão, mas é descrito em um IETF Internet-Draft. Se você usa a opção - R, então você também deve usar a opção - U ltusernamegt ltpasswordgt, que especifica um nome de usuário e uma senha que devem ser usados ​​para autenticar o comando REGISTER entrante. (Observe a diferença entre o comando - u, que especifica um nome de usuário e senha para ser usado para acessar fluxos de back-end e o comando - U, que especifica um nome de usuário e senha para ser usado para autenticar comandos de REGISTER entrantes.) O aplicativo RegisterRTSPStream - incluído no diretório testProgs - pode ser usado para registrar um fluxo de back-end com um servidor proxy. Código fonte e suporte Como este aplicativo é destinado a profissionais de rede de computadores em vez de usuários finais casuais, não o disponibilizamos como um binário pré-construído. Em vez disso, você deve construir você mesmo, a partir do código-fonte. Para fazer isso, você deve baixar e criar o software LIVE555 Streaming Media. Observe que o aplicativo LIVE555 Proxy Server está incluído no subdiretório proxyServer. O suporte para o LIVE555 Proxy Server (e o resto do código LIVE555 Streaming Media) é fornecido através da lista de discussão dos nossos desenvolvedores: live-devellists. live555. Observe que você deve primeiro se inscrever na lista de endereços antes de poder publicar, por favor, leia as Perguntas frequentes antes de postar na lista de discussão. LIVE555 e o logotipo do Live Networks são marcas registradas da Live Networks, Inc. LIVE555 Streaming Media Este código forma um conjunto de bibliotecas C para transmissão multimídia, usando protocolos padrão abertos (RTPRTCP, RTSP, SIP). Essas bibliotecas - que podem ser compiladas para Unix (incluindo Linux e Mac OS X), Windows e QNX (e outros sistemas compatíveis com POSIX) - podem ser usadas para criar aplicativos de transmissão. As bibliotecas já estão sendo usadas para implementar aplicativos como o LIVE555 Media Server e LIVE555 Proxy Server (aplicações de servidor RTSP) e vobStreamer (para transmissão de conteúdo de DVD usando RTPRTCPRTSP). As bibliotecas também podem ser usadas para transmitir, receber e processar vídeo MPEG, H.265, H.264, H.263, DV ou JPEG e vários codecs de áudio. Eles podem ser facilmente estendidos para suportar codecs adicionais (áudio e vídeo) e também podem ser usados ​​para criar clientes e servidores RTSP ou SIP básicos, e foram usados ​​para adicionar suporte de transmissão para aplicativos de media player existentes, como VLC e MPlayer. (Para alguns exemplos específicos de como essas bibliotecas podem ser usadas, consulte os programas de teste abaixo.) Código fonte O código-fonte do projeto está disponível - como um arquivo. tar. gz - aqui. Veja abaixo instruções sobre como construí-lo. (Nota: Para usar este software, você deve estar ciente de como é licenciado e suas obrigações sob esta licença.) Lista de correspondência Existe uma lista de endereços de desenvolvedores. Live-devellists. live555. Os usuários (ou potenciais usuários) das bibliotecas são encorajados a se juntar a essa lista de endereços (de baixo volume), ou a revisar os arquivos das listas de discussão. (Você também pode pesquisar esses arquivos usando o Google, adicionando site: lists. live555 à sua consulta de pesquisa.) Antes de publicar na lista de discussão pela primeira vez, leia as Perguntas frequentes, para verificar se sua pergunta já foi respondida. O principal meio de suporte para essas bibliotecas é a lista de discussão live-devellists. live555 descrita acima. (Note que você deve primeiro se inscrever na lista de endereços antes de poder publicar para isso.) Você está planejando implementar o RTP (ou RTSP) Em vez de escrever sua própria implementação a partir do zero, considere usar essas bibliotecas. Eles já foram usados ​​em muitos aplicativos baseados em RTP do mundo real e são adequados para uso em sistemas incorporados. O código inclui uma implementação do RTCP e pode ser facilmente estendido (por subclasse) para suportar novos tipos de carga útil RTP. Ajude a suportar melhorias e extensões para o software LIVE555 Streaming Media: LIVE555 Projetos financiados. Descrição O código inclui as seguintes bibliotecas, cada uma com seu próprio subdiretório: UsageEnvironment As classes UsageEnvironment e TaskScheduler são usadas para agendar eventos diferidos, para atribuir manipuladores para eventos de leitura assíncronos e para a saída de mensagens de erro. Além disso, a classe HashTable define a interface para uma tabela de hash genérica, usada pelo resto do código. Estas são todas classes de base abstratas, elas devem ser subclassificadas para uso em uma implementação. Essas subclasses podem explorar as propriedades particulares do ambiente em que o programa será executado - p. Seu GUI e ou ambiente de script. As classes nesta biblioteca encapsulam interfaces e soquetes de rede. Em particular, a classe Groupsock encapsula um socket para enviar datagramas de difusão seletiva (ou para receber). Esta biblioteca define uma hierarquia de classes - rooteada na classe Medium - para uma variedade de tipos e codecs de mídia de transmissão. BasicUsageEnvironment Esta biblioteca define uma implementação concreta (ou seja, subclasses) das classes UsageEnvironment, para uso em aplicativos de console simples. Os eventos de leitura e as operações atrasadas são gerenciados usando um loop select (). Este diretório implementa alguns programas simples que usam o BasicUsageEnvironment para demonstrar como desenvolver aplicativos usando essas bibliotecas. RTSP client testRTSPClient é um programa de linha de comando que mostra como abrir e receber fluxos de mídia que são especificados por um URL RTSP - ou seja, um URL que começa com rtsp: neste aplicativo de demonstração, nada é feito com os dados de áudio recebidos. No entanto, você poderia usar e adaptar esse código em seu próprio aplicativo para (por exemplo) decodificar e reproduzir os dados recebidos. OpenRTSP é semelhante ao testRTSPClient, mas tem muitos outros recursos. É um programa de linha de comando que - ao contrário de testRTSPClient - destina-se a ser usado como uma aplicação completa e completa (em vez de ter seu código usado em outras aplicações). Para mais informações sobre openRTSP - incluindo suas muitas opções de linha de comando - veja a documentação online. RTSP server testOnDemandRTSPServer cria um servidor RTSP que pode transmitir, via RTP unicast, de vários tipos de arquivos de mídia, sob demanda. (Os tipos de mídia suportados incluem: MPEG-1 ou 2 de áudio ou vídeo (fluxo primário), incluindo áudio MP3 áudio MPEG-4 (transmissão elementar) Vídeo H.264 (fluxo primário) Vídeo H.265 (fluxo primário) Programa MPEG ou Transporte Fluxos, incluindo VOB arquivos de vídeo DV AMR áudio WAV (PCM) de áudio.) O servidor também pode transmitir a partir de um arquivo Matroska ou WebM (por demultiplexação e transmissão das faixas dentro do arquivo). Os fluxos de transporte MPEG também podem ser transmitidos através de UDP bruto, se solicitado - e. Por um set-top box. Este aplicativo de servidor também demonstra como entregar - via RTSP - um fluxo de transporte MPEG que chegou ao servidor como um fluxo de transmissão múltipla ou UDP (UDP (Raw-UDP ou RTPUDP)). Em particular, é configurado, por padrão, para aceitar a entrada do aplicativo de demonstração testMPEG2TransportStreamer. SIP client playSIP é um programa de linha de comando (semelhante a openRTSP) que faz uma chamada para uma sessão SIP (usando um sip: URL) e, em seguida, (opcionalmente) grava o fluxo de mídia recebido em um arquivo. Os programas de teste de áudio MP3 testMP3Streamer repetidamente lê de um arquivo de áudio MP3 (chamado test. mp3) e transmite-o, usando RTP, para o grupo multicast 239.255.42.42, porta 6666 (com RTCP usando a porta 6667). Este programa também possui um servidor RTSP (opcional). TestMP3Receiver faz o inverso: ele lê um fluxo MP3RTP (do mesmo grupo de multicast) e produz o fluxo de MP3 reconstituído para o stdout. Ele também envia relatórios de recepção RTCP. Alternativamente, o fluxo MP3RTP pode ser jogado usando uma dessas ferramentas. Os programas de teste de vídeo MPEG testMPEG1or2VideoStreamer repetidamente lêem de um arquivo de vídeo MPEG-1 ou 2 (chamado test. mpg) e transmite-o, usando RTP, para o grupo multicast 239.255.42.42, porta 8888 (com RTCP usando a porta 8889). Este programa também possui um servidor RTSP (opcional). Por padrão, o arquivo de entrada é assumido como um Fluxo Elementar de Vídeo MPEG. Se, no entanto, é um fluxo de programa MPEG, então você também pode inserir um filtro de demultiplexação para extrair o Stream Elementar de Vídeo. (Consulte testMPEG1or2VideoStreamer. cpp para obter detalhes.) Maçãs O QuickTime Player pode ser usado para receber e visualizar este vídeo transmitido (desde que seja MPEG-1 e não MPEG-2). Para usar isso, faça o QuickTime Player abrir o arquivo testMPEG1or2Video. sdp. (Se o servidor RTSP testMPEG1or2VideoStreamers estiver habilitado, o QuickTime Player também pode reproduzir o fluxo usando um rtsp: URL.) Os reprodutores de mídia Open Source VLC e MPlayer também podem ser usados. RealNetworks RealPlayer também pode ser usado para reproduzir o fluxo. (Uma versão recente é recomendada.) TestMPEG1or2VideoReceiver faz o inverso: lê uma transmissão MPEG VideoRTP (do mesmo grupo de multicast) e produz o fluxo de vídeo MPEG (elementar) reconstituído para stdout. Ele também envia relatórios de recepção RTCP. TestMPEG4VideoStreamer repetidamente lê de um arquivo de vídeo MPEG-4 Elementary Stream (chamado test. m4e), e transmite-o usando multicast RTP. Este programa também possui um servidor RTSP embutido. Apples QuickTime Player pode ser usado para receber e reproduzir este fluxo de áudio. Para usar isso, peça ao jogador que abra as sessões rtsp: URL (que o programa imprime quando ele começa a transmitir). Os reprodutores de mídia Open Source VLC e MPlayer também podem ser usados. TestH264VideoStreamer repetidamente lê a partir de um arquivo de vídeo H.264 Elementary Stream (chamado test.264), e transmite-o usando multicast RTP. Este programa também possui um servidor RTSP embutido. Apples QuickTime Player pode ser usado para receber e reproduzir este fluxo de áudio. Para usar isso, peça ao jogador que abra as sessões rtsp: URL (que o programa imprime quando ele começa a transmitir). Os reprodutores de mídia Open Source VLC e MPlayer também podem ser usados. TestH265VideoStreamer repetidamente lê de um arquivo de vídeo H.265 Elementary Stream (chamado test.265) e transmite-o usando o multidifusão RTP. Este programa também possui um servidor RTSP embutido. Programas de teste MPEG audiovideo (Stream do programa) testMPEG1or2AudioVideoStreamer lê um arquivo de fluxo de programa MPEG-1 ou 2 (chamado test. mpg), extrai um fluxo de áudio e um fluxo elementar de vídeo e transmite estes, usando RTP, para o grupo multicast 239.255. 42.42, porta 66666667 (para o fluxo de áudio) e 88888889 (para o fluxo de vídeo). Este programa também possui um servidor RTSP (opcional). Apples QuickTime Player pode ser usado para receber e visualizar este vídeo transmitido (desde que seja MPEG-1, e não MPEG-2). Para usar isso, faça o QuickTime Player abrir o arquivo testMPEG1or2AudioVideo. sdp. (Se o servidor RTSP testMPEG1or2VideoStreamers estiver habilitado, o QuickTime Player também pode reproduzir o fluxo usando um rtsp: URL.) Os reprodutores de mídia Open Source VLC e MPlayer também podem ser usados. TestMPEG1or2Splitter lê um arquivo de fluxo de programa MPEG-1 ou 2 (chamado in. mpg) e extrai um áudio e um fluxo elementar de vídeo. Esses dois fluxos elementares são escritos em arquivos chamados outaudio. mpg e outvideo. mpg, respectivamente. Programas de teste MPEG audiovideo (Stream de transporte) testMPEG2TransportStreamer lê um arquivo MPEG Transport Stream (chamado test. ts) e transmite-o, usando RTP, para o grupo multicast 239.255.42.42, porta 1234 (com RTCP usando a porta 1235). Este programa também possui um servidor RTSP (opcional). O reprodutor de mídia VLC Open Source pode ser usado para reproduzir este fluxo. TestMPEG2TransportReceiver faz o inverso: ele lê uma transmissão MPEG TransportRTP (do mesmo grouppport multicast) e produz o fluxo de fluxo de transporte MPEG reconstituído para stdout. Ele também envia relatórios de recepção RTCP. TestMPEG1or2ProgramToTransportStream lê um arquivo de fluxo de programa MPEG-1 ou 2 (chamado in. mpg) e converte-o para um arquivo de fluxo de transporte MPEG equivalente, denominado out. ts. TestH264VideoToTransportStream lê um arquivo H.264 Video Elementary Stream (chamado em.264) e converte-o em um arquivo de fluxo de transporte MPEG equivalente, denominado out. ts. TestH265VideoToTransportStream lê um arquivo H.265 Video Elementary Stream (chamado em.265) e converte-o em um arquivo de fluxo de transporte MPEG equivalente, denominado out. ts. O programa de teste de áudio do PCM testWAVAudioStreamer lê de um arquivo de áudio do formato WAV (chamado test. wav) e transmite o fluxo de áudio PCM incluído através do multicast IP, usando um servidor RTSP interno. O programa suporta transmissões PCM de 8 ou 16 bits, mono ou estéreo, em qualquer freqüência de amostragem. Apples QuickTime Player pode ser usado para receber e reproduzir este fluxo de áudio. Para usar isso, peça ao jogador que abra as sessões rtsp: URL (que o programa imprime quando ele começa a transmitir). Opcionalmente, os fluxos de PCM de 16 bits podem ser convertidos em formato de u-lei de 8 bits antes da transmissão. (Veja testWAVAudioStreamer. cpp para obter instruções sobre como fazer isso.) Os reprodutores de mídia Open Source VLC e MPlayer também podem ser usados. Teste do programa de teste de áudio AMRAMRAudioStreamer lê a partir de um arquivo de áudio de formato AMR (chamado test. amr) - conforme definido no RFC 3267, seção 5 - e transmite o fluxo de áudio incluído através do multicast IP, usando um servidor RTSP embutido. Apples QuickTime Player pode ser usado para receber e reproduzir este fluxo de áudio. Para usar isso, peça ao jogador que abra as sessões rtsp: URL (que o programa imprime quando ele começa a transmitir). O programa de teste de vídeo DV testDVVideoStreamer lê a partir de um arquivo de vídeo DV (chamado test. dv) e transmite-o através de multicast IP, usando um servidor RTSP interno. No momento, não conhecemos nenhum cliente de media player que possa reproduzir este fluxo. O programa de teste de transmissão de Matroska (ou Webm) testMKVStreamer lê de um arquivo Matroska (ou Webm) (chamado test. mkv) e transmite-o através de multicast IP, usando um servidor RTSP embutido. VOB (DVD) programa de teste de transmissão vobStreamer lê um ou mais arquivos. vob (por exemplo, a partir de um DVD), extrai os fluxos de áudio e vídeo e os transmite usando multicast RTP. Suporte para operações de truque de servidor em arquivos de fluxo de transporte MPEG Os aplicativos MPEG2TransportStreamIndexer e testMPEG2TransportStreamTrickPlay Outros programas de teste testRelay repetidamente lê de um soquete de multicast UDP e retransmite (relés) cada carga de pacotes para um novo endereço e porta (multicast ou unicast). TestReplicator é semelhante ao testRelay. Exceto que ele replica o fluxo de entrada - usando a classe FrameReplicator - e retransmite um fluxo de réplica para outro endereço e porta (multicast ou unicast), enquanto escreve o outro fluxo de réplica para um arquivo. SapWatch lê e imprime anúncios SDPSAP feitos no diretório SDPSAP padrão (224.2.127.2549875) registerRTSPStream envia um comando RTSP REGISTER personalizado para um determinado cliente RTSP (ou servidor proxy), pedindo que ele seja transmitido a partir de um determinado rtsp: URL. WindowsAudioInputDevice This is an implementation of the liveMedia librarys AudioInputDevice abstract class. This can be used by a Windows application to read PCM audio samples from an input device. (This project builds two libraries: libWindowsAudioInputDevicemixer. lib, which uses Windows built-in mixer, and libWindowsAudioInputDevicenoMixer. lib, which doesnt.) How to configure and build the code on Unix (including Linux, Mac OS X, QNX, and other Posix-compliant systems) The source code package can be found (as a. tar. gz file) here. Use tar - x and gunzip (or tar - xz, if available) to extract the package then cd to the live directory. Then run where ltos-platformgt is your target platform - e. g. linux or solaris - defined by a config. ltos-platformgt file. This will generate a Makefile in the live directory and each subdirectory. Then run make. If the make fails, you may need to make small modifications to the appropriate config. ltos-platformgt file, and then re-run genMakefiles ltos-platformgt . (E. g. you may need to add another - I ltdirgt flag to the COMPILEOPTS definition.) Some people (in particular, FreeBSD users) have reported that the GNU version of make - often called gmake - works better than their default, pre-installed version of make. (In particular, you should try using gmake if you encounter linking problems with the ar command.) If youre using gcc version 3.0 or greater: You may also wish to add the - Wno-deprecated flag to CPLUSPLUSFLAGS. If no config. ltos-platformgt file exists for your target platform, then try using one of the existing files as a template. If you wish, you can also install the headers, libraries, and applications by running make install. How to configure and build the code on Windows Unpack and extract the. tar. gz file (using an application such as WinZip). If the tools directory on your Windows machine is something other than c:Program FilesDevStudioVc, change the TOOLS32 line in the file win32config. In a command shell, cd to the live directory, and run This will generate - in each subdirectory - a. mak makefile suitable for use by (e. g.) Microsoft Visual Studio. Alternatively, if youre starting from a Unix machine, you can generate the Windows Makefiles by running (after - if necessary - changing the TOOLS32 line in the file win32config, as noted above). Then, copy the live directories and its subdirectories (in ASCII mode) to a Windows machine. To use these Makefiles from within Visual Studio, use the Open Workspace menu command, then (in the file selection dialog) for Files of type, choose Makefiles (.mak). Visual Studio should then prompt you, asking if you want to use this Makefile to set up a new project. Say OK. Note that you will need to build each of the UsageEnvironment, groupsock, liveMedia, and BasicUsageEnvironment projects first . before building testProgs. If you wish, you can build the WindowsAudioInputDevice project also. Doug Kosovic notes: Visual C 2003 no longer comes with the old IO Streams headers iostreams. h et al, or the corresponding library msvcirt. lib. So anybody trying to build the LIVE555 code with VC 2003 might find the following useful: A non-sourcecode modification workaround for VC 2003 is to copy the missing headers and msvcirt. lib from VC 2002. In file win32config add an extra - I switch to COMPILEOPTS to find the old headers and a - LIBPATH: switch to LINKOPTS0 to find msvcirt. lib. If youre using the Borland C compiler The instructions above assume that you use Microsoft Visual Studio (version 5 or greater) as your C development environment. If, however, you are using Borlands development tools, then the instructions above are amended as follows: Before running the genWindowsMakefiles. cmd script, edit it to replace each occurrence of win32config with win32config. Borland. After running genWindowsMakefiles, edit each of the new Makefiles by following these instructions. (Please read this before posting questions to the mailing list.) Source code license This code is open source, and is released under the LGPL. This allows you to use these libraries (via linking) inside closed-source products. It also allows you to make closed-source binary extensions to these libraries - for instance, to support proprietary media codecs that subclass the existing liveMedia class hierarchy. Nonetheless, we hope that subclass extensions of these libraries will also be developed under the LGPL, and contributed for inclusion here. We encourage developers to contribute to the development and enhancement of these libraries. Extend the liveMedia library to support even more media types andor codecs. Supply additional UsageEnvironment subclassed implementations - e. g. for use with scripted environments, such as Tcl, Python, or Perl. Expand the RTCP implementation to support more SDES items (other than just CNAME), and to more completely handle incoming RTCP packets. In places the code uses data types such as unsigned, where instead specific lengths (e. g. 32 bits) are required. The data types should be changed in each such case. Fix the groupsock implementation so that it could use IPv6 instead of IPv4. (At present, 4-byte addresses are hard-wired into the code in several places.) Switch to using ISO-conformant C headers (but in such a way that the code can remain portable across both Unix (using gcc) and Windows (using Visual C)). Implement network sockets (groupsocks) as liveMedia sources. This will make the code for RTP sources more consistent with the rest of the liveMedia library, allowing them to be FramedFilters. (This will make it possible to use synthetic network sockets - e. g. for debugging or simulation.) Add support for SRTP (secure RTP), and perhaps also RTSP-over-TLS. Some third-party applications Several third-party devices and applications have made use of the LIVE555 Streaming Media Software. Here is a list of some of them: RaspberrIPCam - a full HD IP Camera based on Raspberry Pi Network-enabled, RTP-streaming Security Cameras. from RVision The LMLM4 MPEG-4 audiovideo hardware encoder PCI board. from Linux Media Labs. WIS Technologies media encoders. (The wis-streamer server application - for Linux - can be used to stream from many of these encoders.) Elphel Network Video Cameras (with optional JPEG streaming over RTP ). The Cam. ly wireless security camera system uses openRTSP to archive recorded video. The VLC media player (uses the LIVE555 Streaming Media libraries for its RTSP client implementation). The MPlayer media player. Ralf Globischs Video Processing Project - a RTSP client DirectShow Filter Morgan RTP DirectShow TM Filters , from Morgan Multimedia Omnimeeting - a videoconferencing application Network-Integrated Multimedia Middleware (NMM) , from Saarland University ivrworx - a SIP IVR application - uses LIVE555 Streaming Media code for RTP mixing LiveMediaStreamer - an open source multimedia framework If you would like your product (or project) added to this list, please send email to the developers mailing list.