O download progressivo de HTTP é uma alternativa viável ao HLS / DASH / RTMP para fornecer vídeo ao vivo?


16

Estou trabalhando em um site que precisa transmitir vídeo ao vivo para os usuários e, como tal, tive que pensar no triste estado da atual tecnologia de transmissão de vídeo baseada em navegador. As soluções mais populares para transmissão ao vivo atualmente têm problemas de compatibilidade; O RTMP requer Flash, o HLS é suportado apenas de forma nativa no Safari e Chrome para Android, o DASH não é suportado de maneira nativa em nenhum lugar e o uso do dash.js requer Extensões de fonte de mídia , que ainda não são amplamente suportadas.

Isso leva a uma pergunta que me parece óbvia: é possível usar o download progressivo simples como uma alternativa a protocolos como HLS, RTMP e DASH que requerem suporte ao navegador ou plug-ins?

A idéia de usar o download progressivo para transmitir mídia ao vivo não é inédita; as pessoas já fazem isso por áudio. Ferramentas como o liveCaster permitem transmitir áudio MP3 ao vivo através de uma única resposta HTTP progressiva sem a necessidade de um arquivo MP3 pré-gravado, e bibliotecas como o AmplitudeJS se esforçaram para adicionar recursos relacionados a esse tipo de transmissão de áudio ao vivo .

No entanto, não vi nenhum exemplo dessa técnica sendo usado na natureza para vídeo , e não sei dizer por quê. Parece que isso removeria uma camada de problemas de compatibilidade complicados e difíceis do lado do navegador por uma troca relativamente pequena. (E a compatibilidade ainda é um grande problema para a transmissão ao vivo, mesmo quando os profissionais o fazem; se eu tentar assistir a um vídeo ao vivo no iPlayer da BBC no Firefox, isso me dá uma mensagem de erro dizendo para instalar o Flash.) No entanto, ninguém está usando essa técnica, e nunca vi ninguém mencionar a idéia além de mim.

Por quê? Existe uma limitação fundamental que eu não vejo que tornaria impossível apenas transmitir um arquivo de vídeo como um MP4 por download progressivo à medida que ele está sendo gerado, e reproduzi-lo em um <video>elemento durante o download?


Não foi possível usar uma biblioteca javascript HLS (por exemplo, hls.js aqui: github.com/video-dev/hls.js/tree/master ) para adicionar suporte HLS em vários navegadores à sua página? Eu acho que isso talvez não existisse quando você fez essa pergunta originalmente ... mas, existe agora. :)
presoj 15/09/17

Respostas:


3

Sua pergunta é válida e, teoricamente, acho que você pode usar downloads progressivos para transmissão de vídeo ao vivo. Na verdade, muitos vídeos de streaming on-line como o YouTube etc. já usam HTTP. Eu estou supondo que você está estritamente falando ao vivo streaming e não apenas streaming de.

Você terá que implementar os casos de uso de transmissão ao vivo, você mesmo! Caso contrário, os protocolos de streaming (RTMP etc.) fazem a si mesmos. Aqui estão alguns motivos para preferir esses protocolos e arquitetura:

1. Taxa de bits variável

A maioria dos vídeos ao vivo é codificada em VBR e seu vídeo terá que se adaptar rapidamente às mudanças no congestionamento da rede do seu cliente. Assim, seu vídeo pode alternar várias resoluções em um tempo muito curto, dependendo da velocidade ou velocidade da conexão do cliente.

De acordo com a Wikipedia

Ele funciona detectando a largura de banda do usuário e a capacidade da CPU em tempo real e ajustando a qualidade de um fluxo de vídeo de acordo.

2. Conteúdo ao vivo

O ponto mais importante é que a transmissão ao vivo significa conteúdo ao vivo . Ao contrário do HTTP Progressive Download, você não pode fazer buffer a qualquer momento. O usuário deve ver o último quadro destinado ao mundo inteiro e não pode ficar para trás.

3. Desativar busca

Um problema menor, mas o protocolo não deve especificamente permitir que o usuário procure para trás (e obviamente para frente). Isso não deve ser controlado apenas no nível do Player de vídeo, mas também no nível da rede.

4. Desconexões frequentes / rede não confiável

Eu sou um pouco incerto sobre esse ponto, mas sei que, uma vez que um download HTTP recebido seja desconectado, pode levar algum tempo para estabelecer outro handshake (mesmo com keep-alive). Os protocolos ao vivo são muito mais rápidos para conectar e desconectar devido ao próximo ponto ->

5. Latência

O HTTP é inerentemente executado sobre o TCP, o que fornece entrega garantida de pacotes. Compare isso com o UDP usado em muitos protocolos (especialmente jogos multiplayer ao vivo), onde a velocidade é priorizada sobre as garantias.

Para mais informações, consulte aqui -> https://en.wikipedia.org/wiki/Streaming_media#Protocols

6. Cópia de Conteúdo

A maioria dos servidores de transmissão ao vivo responde apenas ao conteúdo da hora atual. Embora ainda seja possível copiar o conteúdo de transmissões ao vivo, é preciso recorrer à captura de tela etc. A realização de um download progressivo HTTP torna a tarefa de copiar o conteúdo bastante trivial (daí, muitos downloaders do YouTube por aí).

Agora, o HTTP pode ser modelado para fornecer a maioria dos itens acima.

O HTTP Live Streaming (HLS) da Apple , você mencionou, aproxima-se mais do que você está tentando alcançar.

E há pesquisas ativas em andamento neste campo, conforme indicado aqui -> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65749&PageNum=2

Estou à procura de mais informações e atualizarei esta resposta.


Parece incorreto mencionar a latência como uma desvantagem do uso do download progressivo HTTP, uma vez que os principais concorrentes incluem DASH e HLS, que fornecem segmentos de vídeo por meio de várias solicitações HTTP sequenciais. Não conheço todos os detalhes dos protocolos, mas suponho que a última abordagem exija uma latência mínima de pelo menos o comprimento do segmento sendo usado, enquanto que com a abordagem de download progressivo não há latência mínima teórica - uma latência menor deve ser um anúncio de vista da abordagem download progressivo, certo?
Mark Amery

Além disso, algumas das outras preocupações aqui - como procurar e recuperar de desconexões - são problemas que se aplicam igualmente a uma implementação JavaScript do DASH, mas o dash.js presumivelmente os supera. Eu imagino que eles poderiam ser superados por um player de download progressivo apenas roubando as soluções que os desenvolvedores do dash.js.
Mark Amery

@ MarkAmery Se você comparar com DASH e HLS, então sim, acho que é comparável. Mas, se você compará-lo com alguns dos protocolos mais antigos que estão sobre o UDP, o HTTP perde as mãos! Mesmo que você veja muitos sistemas em tempo real hoje em dia, são criados usando Websockets e evita o HTTP por causa de seus problemas de latência.
Gaurav Ramanan

1
A facilidade de copiar conteúdo é uma desvantagem real sobre o dash.js e o HLS. E não tenho certeza de como os fluxos de taxa de bits variáveis ​​podem ser implementados usando o download progressivo, embora eu espere que isso seja possível com um pouco de astúcia.
Mark Amery

@MarkAmery Quando se trata de transmissão em tempo real e ao vivo, devemos considerar o desempenho e não apenas a possibilidade. Analisarei o DASH, mas me pergunto se existem benchmarks que mostram comparações de desempenho entre os protocolos de streaming e a recuperação de HTTP de uma desconexão.
Gaurav Ramanan
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.