Pergunta

Eu estou tentando compreender conceitualmente a melhor maneira de entregar verdadeira streaming de conteúdo de áudio e vídeo. Eu quero que ele seja consumido com um navegador web, utilizando a menor quantidade de tecnologia proprietária. Eu não estaria servindo arquivos estáticos e usando download progressivo, este seria fluxos de áudio reais de ser capturado vivo. Como é que um transmitir um fluxo que será razoavelmente em sincronia com a fonte? Que tipo de protocolo é adequado?

Editar:

Na pesquisa eu descobri que existem alguns protocolos: RTSP, HTTP Streaming, RTMP e RTP.

HTTP streaming de é um tanto inadequada se estiver transmitindo um live performance / comunicação de algum tipo, porque ele depende de TCP (como HTTP baseado) e você não faz pacotes perder. Em uma situação de pouca largura de banda, o cliente pode obter significativamente para trás em reprodução. ref

RTMP é uma tecnologia proprietária, exigindo servidor de mídia flash. Excremento sobre isso. A razão que eu olhei para o flash é porque eles são extremamente flexíveis, tanto quanto a experiência do usuário vai. SoundManager2 fornece uma excelente interface javascript para reprodução de mídia com flash. Isto é o que eu iria procurar em um aplicativo cliente.

RTSP / RTP é o que a Microsoft passou a usar, depreciativo seu protocolo MMS. RTSP é o protocolo de controlo. Sua semelhante ao HTTP com alguns diferença distinta - servidor também pode falar com o cliente, e há comandos adicionais, como PAUSA. Seu também um protocolo stateful, que é mantido com um ID de sessão. RTP é o protocolo para a entrega da carga útil (áudio ou vídeo codificado). Existem alguns projetos de código aberto, um deles sendo suportado pela Apple aqui . Parece que este pode fazer o que eu quero que ele, e parece que bastante alguns jogadores apoiá-lo . Parece que seria adequado para uma transmissão "ao vivo" a partir desta página aqui .

Obrigado, Josh

Foi útil?

Solução

Em primeiro lugar, deixe-me derrubar dois pontos incorretos rapidamente. Detalhes a seguir abaixo:

  • RTMP pode ser feito em relação a outros servidores do que Flash Media Server
  • TCP é bom para ao vivo. Há muita F.U.D. dos povos amantes da UDP lá fora. Apple acaba de lançar um especificação preliminar de fazer simples, streaming ao vivo sobre HTTP (e, portanto, TCP) para o iPhone. Espero que ele vai acabar em navegadores também. Além disso, o TCP tem a vantagem de obter através de firewalls corporativos muito mais frequentemente e facilmente.

A minha leitura é que complexos e baseados em UDP streaming é diminuindo. Eu não estou prevendo a morte, apenas uma parte menor e menor do mercado. servidores de streaming baseados em UDP consomem enormes recursos, em relação a soluções baseadas em TCP (como 10x ou mais), e os benefícios apenas que não são tangíveis.

Você diz que você não quer que a tecnologia proprietária, e "crap em [Flash]", , mas você ainda quer fazer streaming de Real? Odeio dizer isso para você, mas ambos RealAudio e RealVideo são ambos proprietária.

Se vai Open Source é realmente tão importante para você, o que eu posso entender, então você precisa ignorar a grande maioria do mercado de streaming media. Ter um olhar para

  • Theora : um livre de royalties, padrão aberto, com perdas video tecnologia de compressão
  • Vorbis : um projeto de código de software livre / aberto que produz um áudio especificação do formato e implementação de software para compressão de áudio com perdas.
  • Ogg :, um formato contêiner padrão aberto livre

Se o pragmatismo tem o melhor de você, então reconsiderar a sua aversão a produtos da Adobe. Lembrar, o Flash é mais amplamente distribuído do que qualquer outro jogador baseado no navegador (ou seja, Windows Media Player, Quick Time e jogadores reais.)

Você ainda pode usar RTMP com código aberto: Red5 é provavelmente de maior interesse - pode transmitir ao vivo para o Flash navegadores habilitados.

Eu recomendaria pensar sobre suas prioridades. Escrevê-los para nós na sua pergunta.

Outras dicas

Gostaria de acrescentar a resposta de Stu que os protocolos de streaming baseados UDP muitas vezes têm uma complexidade adicional ao trabalho quando atrás de firewalls ou NATs. Por exemplo, se você planeja usar pontos de acesso Wi-Fi fora de casa, muitos deles não vai apoiar RTP usando a entrega UDP. Muitos clientes têm um mecanismo de retorno de falha onde se nenhum pacote for recebido antes de um tempo limite, o cliente tentará entrega TCP.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top