Streaming de mídia de páginas HTML internas, por exemplo

Então, eu sou um engenheiro de software tentando entender alguns detalhes básicos sobre como a mídia de streaming funciona. Passei a maior parte do dia tentando entender os vários codecs, formatos de contêiner e protocolos de streaming que são pertinentes ao meu aplicativo. Até agora, aqui está o meu entendimento de como funciona, que pode muito bem ser enganado:

• A mídia de streaming realmente se resume ao formato do contêiner e ao protocolo de streaming :
  • Todos os dados de áudio são codificados (via codec de áudio) em um fluxo de bits de áudio
  • Todos os dados de vídeo são codificados (novamente, via codec) em um fluxo de bits de vídeo
  • Os dois fluxos são mesclados ( multiplexados? ) Em um contêiner que acaba se tornando um arquivo (como MP4, etc.)
  • Um servidor de mídia especial serve esse contêiner (arquivo MP4 ou algum outro formato) para um cliente (talvez um player de vídeo HTML5 sendo executado no navegador de alguém) por meio de algum protocolo de streaming padrão, como o RTSP
    • No caso de um cliente de navegador, presumo que o próprio navegador tenha um cliente RTSP que, de alguma forma, apresente aos usuários o HTML5 Video Player
• Eu poderia hospedar um arquivo MP4 de um servidor da web , como nginx ou httpd, mas como esses servidores não são servidores RTSP, apenas seria possível tratar solicitações para o MP4 como solicitações de download e, portanto, não conseguiria transmitir o arquivo arquivos de mídia
  • Da mesma forma, se eu fosse curlbuscar os arquivos de um servidor nginx, já que curlnem o nginx falam RTSP, ele seria tratado como um download de arquivo
• Mas, quando eu hospedo um arquivo MP4 de um servidor de mídia de streaming (VideoLAN, Red5, Wowza etc.), e uso um cliente RTSP (ou qualquer outro cliente de mídia de streaming compatível) para solicitar um fluxo desse servidor, que então e somente em seguida, faz qualquer real streaming de ocorrer
  • Portanto, mesmo que os "vídeos" do YouTube ou Vimeo estejam hospedados em páginas HTML veiculadas em HTTP (S) por servidores HTTP, presumo que os reprodutores de vídeo incorporados nessas páginas (onde os vídeos realmente são reproduzidos) estão realmente começando um segundo , conexão subseqüente a um servidor de streaming e o streaming está ocorrendo através de RTSP ou outro protocolo não HTTP

Portanto, esse é o meu entendimento, e acho que pediria primeiro que, se algo que afirmei acima estiver incorreto, comece me corrigindo! Supondo que eu esteja mais ou menos correto:

Como os players de mídia de streaming, executados em páginas HTML e servidos por servidores HTML, estabelecem conexões de streaming (RTSP, etc.) com servidores de mídia de streaming (atendendo solicitações de RTSP)?

Como os players de mídia de streaming, executados em páginas HTML e servidos por servidores HTML, estabelecem conexões de streaming (RTSP, etc.) com servidores de mídia de streaming (atendendo solicitações de RTSP)?

Aplicações comuns

RTSPAtualmente, o parece ser usado mais com interfaces de aplicativos / dispositivos que transmitem diretamente ao vivo (por exemplo, câmera IP) ou retransmitem (como um mecanismo) do que para transmitir arquivos de mídia salvos de um local físico por meio de uma interface de reprodução na Web HTTP com uma interface de reprodução HTTP. player incorporado.

Parece que o RTSP é um protocolo estável e usa UDP mais do que TCP ao transmitir, e é usado mais como um dispositivo de servidor (como uma câmera IP) conectado a uma rede TCP / IP e que transmite fluxos via UDP, etc. Em seguida, você se conecta a esses feeds (o servidor) como o cliente na mesma rede e pode emitir solicitações RTSP para utilizar de acordo.

^{Diretivas de protocolo}

^{Embora parecido com o HTTP, o RTSP define sequências de controle úteis para controlar a reprodução de multimídia. Enquanto o HTTP é sem estado , o RTSP tem estado; um identificador é usado quando necessário para rastrear sessões simultâneas. Como o HTTP, o RTSP usa o TCP para manter uma conexão ponta a ponta e, enquanto a maioria das mensagens de controle do RTSP é enviada pelo cliente ao servidor, alguns comandos trafegam na outra direção (ou seja, do servidor para o cliente).}

^{Aqui são apresentados os pedidos básicos de RTSP. Algumas solicitações HTTP típicas, como a solicitação OPTIONS, também estão disponíveis. O número da porta da camada de transporte padrão é 554 [3] para TCP e UDP, sendo este último raramente usado para solicitações de controle.}

^_fonte

^{Sem Estado}

^{Um protocolo sem estado não exige que o servidor mantenha informações ou status da sessão sobre cada parceiro de comunicação pela duração de várias solicitações. Por outro lado, um protocolo que requer a manutenção do estado interno no servidor é conhecido como protocolo com estado .}

^{Uma desvantagem da apatridia é que pode ser necessário incluir informações adicionais em cada solicitação, e essas informações extras precisarão ser interpretadas pelo servidor.}

^_fonte

Fluxo Lógico

A maneira como entendo o fluxo de mídia de streaming neste formulário é:

• o servidor em que o conteúdo da mídia reside encapsulará, compactará, codificará etc. o conteúdo dos dados de vídeo / áudio nos formatos e segmentos adequados para a entrega do fluxo
• o servidor da Web que escuta conexões para acessar a mídia de streaming fornecerá todos os recursos necessários para transmitir a mídia
• o cliente solicita e baixa recursos e arquivos aplicáveis ​​e os monta de maneira contínua para reprodução através do ponteiro da URL, conforme configurado e outros parâmetros. O software de reprodução no nível do cliente reúne os pacotes transmitidos em sequência para permitir a reprodução adequada do conteúdo.

Consulte a seção Tecnologias de streaming abaixo para obter uma comparação geral de HTTP versus RTSP.

além disso

Nas 10 razões abaixo, você nunca deve hospedar seus próprios vídeos , citei as partes que chegam ao ponto de ajudar a responder sua pergunta em "geral" sem ser muito específico.

Essencialmente, ele diz que o site que possui o media player incorporado controla:

• ⁽¹⁾ detectar as configurações do navegador da Web do cliente mediante "conexão e solicitação" do cliente e
• ⁽²⁾ isso definirá o codec e quaisquer outras configurações de detecção do lado do cliente com os valores de parâmetros aplicáveis ​​e, em seguida,
• ⁽³⁾ transmitirá o vídeo diretamente do servidor de streaming em que você hospeda os arquivos de vídeo e áudio, com base em códigos adicionais nas configurações incorporadas do media player, apontando para o URL do arquivo de mídia no servidor hospedado.

^{Tecnologias de Streaming}

^{O navegador do cliente deve receber os dados do servidor e passá-los para o aplicativo de streaming para processamento. O aplicativo de streaming converte os dados em imagens e sons. Um fator importante no sucesso desse processo é a capacidade do cliente de receber dados mais rapidamente que o aplicativo pode exibir as informações. Os dados em excesso são armazenados em um buffer - uma área de memória reservada para armazenamento de dados no aplicativo. Se os dados atrasarem a transferência entre os dois sistemas, o buffer será vazio e a apresentação do material não será suave.}

^{Protocolo HTTP}

^{O HTTP é a maneira predominante na qual os documentos são vinculados na Internet. O cliente faz uma conexão com o servidor que contém o arquivo a ser transmitido, o arquivo é recuperado e a conexão fechada. O servidor HTTP comunica ao navegador o tipo de arquivo a ser transferido.}

^{Benefícios usando HTTP}

^{Ao transmitir um arquivo usando HTTP, um servidor de streaming especial não é necessário. Enquanto o seu navegador entender os tipos MIME, ele poderá receber um arquivo de streaming de um servidor HTTP. Uma das vantagens distintas do streaming de arquivos usando HTTP é que ele pode passar por firewalls e utilizar servidores proxy.}

^{Algumas desvantagens}

^{O fluxo HTTP usa TCP / IP (Transmission Control Protocol e Internet Protocol) para garantir a entrega confiável dos arquivos. Esse processo verifica se há pacotes ausentes e solicita que eles sejam retransmitidos. Isso se torna problemático no cenário de streaming quando você deseja que os dados sejam desconsiderados se forem perdidos na entrega, para que os arquivos dinâmicos continuem sendo reproduzidos. O HTTP não pode detectar a velocidade do modem; portanto, os administradores do servidor devem produzir arquivos com diferentes taxas de compactação para usuários do servidor com diferentes tipos de conexões. O streaming de arquivos de servidores HTTP não é recomendado para situações de alta demanda.}

^{Protocolo RTSP}

^{RTSP é o protocolo padrão usado pela maioria dos fornecedores de servidores de streaming. Os servidores RTSP usam o UDP (User Datagram Protocol) para transferir arquivos de mídia. O UDP não verifica continuamente se os arquivos chegaram ao seu destino. Essa é uma vantagem para aplicativos de streaming, pois permite que as transferências de arquivos sejam interrompidas desde que o atraso não seja muito longo. O resultado desse método é que às vezes há perda de dados, mas os arquivos continuam sendo reproduzidos se o atraso for pequeno.}

^fonte

^{10 razões pelas quais você nunca deve hospedar seus próprios vídeos}

^{Estamos falando de incorporação vs. vídeo auto-hospedado}

^{Primeiro, você carrega seu arquivo de vídeo em um serviço de hospedagem de vídeo de terceiros, como YouTube, Vimeo ou Wistia.}

^{Em seguida, copie um pequeno pedaço de código que eles fornecem e cole-o em sua postagem ou página em seu próprio site WordPress. O vídeo aparecerá no seu site, no local em que você colou o código de incorporação, mas o próprio vídeo está sendo transmitido dos servidores do host de vídeo, em oposição ao seu próprio servidor da web, onde o site do WordPress está hospedado.}

^{4. Nenhum padrão de formato de arquivo único para vídeo na Web}

^{A especificação atual de rascunho em HTML5 não especifica quais formatos de vídeo os navegadores devem suportar. Como resultado, os principais navegadores da web divergiram, cada um suportando um formato diferente. O Internet Explorer e o Safari reproduzirão vídeos H.264 (MP4), mas não o WebM ou Ogg. O Firefox reproduz vídeos Ogg ou WebM, mas não o H.264. Felizmente, o Chrome reproduzirá todos os principais formatos de vídeo, mas se você quiser garantir que o vídeo seja reproduzido em todos os principais navegadores da Web, será necessário converter o vídeo em vários formatos: .mp4, .ogv e .webm}

^{5. Espero que você goste de converter vídeos. Muito.}

^{É provável que a maioria do seu público assista a seus vídeos em seus computadores ou laptops com o benefício de uma conexão à Internet de alta velocidade. Para essas pessoas, você desejará entregar um arquivo grande com qualidade HD para que eles possam assisti-lo em tela cheia, se assim o desejarem. Geralmente, isso significa um arquivo de 1080p ou 720p com uma alta taxa de bits de streaming (5000 - 8000 kbps).}

^{Mas você também desejará codificar uma versão menor e de menor resolução para entrega em dispositivos móveis, como telefones e tablets, e também para os espectadores com conexões mais lentas com a Internet.}

^{6. Leitores de vídeo}

^{Um reprodutor de vídeo é um pequeno software da web que você instala no seu site que detecta automaticamente qual dispositivo está solicitando o vídeo, juntamente com a velocidade da conexão, e entrega a versão apropriada para essa pessoa.}

^{7. Código complicado [ou códigos de acesso]}

^{Se você usa um plug-in de terceiros ou os recursos de vídeo integrados do WordPress, precisará criar um pouco de código para informar ao player de vídeo quais formatos você criou, bem como a localização deles no servidor. Parece algo assim…}

<video poster="movie.jpg" controls>
<source src="movie.webm" type='video/webm; codecs="vp8.0, vorbis"'/>
<source src="movie.ogg" type='video/ogg; codecs="theora, vorbis"'/>
<source src="movie.mp4" type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/>
<p>This is fallback content</p>
</video>

Então, qual é a melhor solução para adicionar vídeo ao seu site?

Basta usar um serviço de hospedagem de vídeo de terceiros e incorporar seu vídeo à sua postagem ou página do WordPress.

Etapa 1: faça o upload do seu vídeo para um dos serviços populares e bem estabelecidos de hospedagem de vídeos, como o Vimeo PRO.

Etapa 2: depois que o vídeo tiver sido enviado e estiver pronto para visualização, copie o URL no seu vídeo. Volte ao seu site WordPress e cole o URL na sua postagem ou página onde deseja que o vídeo apareça.

---

^{Quando as pessoas visualizarem sua página, o vídeo aparecerá no local em que você colou o URL. Mas o próprio arquivo de vídeo será transmitido dos servidores do host de vídeo, em oposição ao seu próprio servidor, onde o site do WordPress está hospedado.}

_{O reprodutor de vídeo incorporado detectará automaticamente a velocidade do dispositivo, navegador e conexão com a Internet do usuário e servirá a versão apropriada do arquivo de vídeo. Nada para instalar no seu site. Não há plugins para manter-se atualizado. Nenhum código complicado.}

_fonte

A seguir, tratarei principalmente da sua pergunta sobre o que acontece quando um vídeo é exibido no navegador. O assunto é vasto, por isso só tocarei nos itens relevantes.

O HTML5 introduziu a <VIDEO>tag que resolveu o problema de integrar o vídeo exibido no navegador ao usar JavaScript e CSS. A <OBJECT>tag anterior exigia software externo e estava mal integrada à página. A nova tag em vigor exigia que o navegador também se tornasse um player de vídeo, embora nenhum padrão fosse imposto. O resultado foi uma fragmentação total dos padrões, para a qual a única solução é que o servidor de vídeo disponibilize vários formatos de vídeo e que todas essas fontes alternativas sejam especificadas na <VIDEO>tag, na qual o navegador escolherá o que ele suporta.

Um exemplo de uma tag com várias fontes:

<video width=320 height=240 controls poster=image.jpg>
   <source src="movie.mpd">
   <source src="movie.webm">
   Your browser does not support the video tag.
</video>

A <VIDEO>tag em si é independente de protocolo, portanto, pode usar qualquer protocolo suportado pelo navegador, incluindo o RTSP. Ultimamente, o suporte ao protocolo MPEG-DASH (Dynamic Adaptive Streaming over HTTP) tornou-se muito abrangente, sendo reproduzido na maioria dos dispositivos e navegadores nativos ou usando HTML5, o que significa que nenhum plug-in extra é necessário. Consulte esta tabela de compatibilidade de dispositivos e navegadores . Consulte também este artigo da Mozilla para preparar seu servidor para servir MPEG-DASH. O DASH funciona via HTTP; portanto, isso funcionará desde que o servidor HTTP suporte solicitações de intervalo de bytes e esteja configurado para veicular arquivos .mpd commimetype="application/dash+xml" .

A interação normal entre cliente e servidor é semelhante à seguinte. Para o HTML5 VIDEO, o navegador também é o reprodutor, embora possa abrir uma nova conexão para reprodução.

A conexão inicial fornece os metadados que o cliente usa para exibir o vídeo. Se o protocolo RTSP foi usado para obter esses metadados, uma conexão RTP é criada posteriormente para transferir os dados de vídeo + áudio. O protocolo RTCP é usado para transferir comandos adicionais para o servidor.

RTP, RTCP e RTSP todos operam em portas diferentes. Normalmente, quando o RTP está na porta N, o RTCP está na porta N + 1. Uma sessão RTP pode conter múltiplos fluxos a serem combinados no final do receptor; por exemplo, áudio e vídeo podem estar em canais separados.

Para que ninguém fique bloqueado no seu conteúdo, você deve disponibilizar codecs isentos de royalties, webM ou Theora e vídeo H.264 e áudio Vorbis e MP3. (Fácil, difícil de fazer.)

É o que acontece em detalhes para o RTSP:

1. O cliente estabelece uma conexão TCP com os servidores, normalmente na porta TCP 554, a porta conhecida para RTSP.

2. O cliente começará a emitir uma série de comandos de cabeçalho RTSP que têm um formato semelhante ao HTTP, sendo que cada um é reconhecido pelo servidor. Dentro desses comandos RTSP, o cliente descreverá para o servidor detalhes dos requisitos da sessão, como a versão do RTSP que ele suporta, o transporte a ser usado para o fluxo de dados e qualquer informação de porta UDP ou TCP associada. Essas informações são transmitidas usando os cabeçalhos DESCRIBE e SETUP e são aumentadas na resposta do servidor com um ID de sessão que o cliente e qualquer dispositivo proxy transitório podem usar para identificar o fluxo em trocas adicionais.

3. Após a conclusão da negociação dos parâmetros de transporte, o cliente emitirá um comando PLAY para instruir o servidor a iniciar a entrega do fluxo de dados RTP.

4. Depois que o cliente decide fechar o fluxo, um comando TEARDOWN é emitido junto com o ID da sessão instruindo o servidor a interromper a entrega RTP associada a esse ID.

Leitura adicional:

• Noções básicas de protocolos de streaming
• Noções básicas sobre protocolos da camada de aplicativos - RTSP (Real Time Streaming Protocol)
• Introdução ao vídeo HTML5 (Opera)
• Áudio e vídeo HTML5: o que você deve saber
• Análise RTSP Wireshark

Aqui está uma resposta rápida e suja:

Há uma diferença entre reproduzir um vídeo na Web e transmiti-lo em tempo real.

A reprodução é feita por meio de um player incluído na página da web (pode estar usando flash, JS ou um objeto de vídeo html5). O cliente (navegador) baixa esse player e o executa. O player, por sua vez, busca o vídeo a partir de um simples URL de download. De fato, mesmo com o Youtube, existem programas que permitem acessar diretamente os arquivos de vídeo hospedados e baixá-los como faria com qualquer arquivo. Como o sistema usa um link de download antigo e regular, não há necessidade de protocolos de streaming complexos, como o RTSP

O streaming em tempo real (por exemplo, de uma webcam) é ... bem, mais complicado. O Flash possui essa funcionalidade incorporada, mas não deve mais ser usada. O vídeo HTML5 não suporta streaming em tempo real, mas as pessoas conseguem "enganá-lo", fazendo com que o servidor de hospedagem de arquivos altere constantemente o arquivo de vídeo que ele oferece.