Streaming Media de dentro de páginas HTML, por exemplo

Question

Então eu sou um engenheiro de software tentando entender alguns detalhes minuciosos 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, o que poderia muito bem ser enganado:

• A mídia de streaming realmente se resume a formato de contêiner e 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? ) juntos em um container que finalmente se torna um arquivo (como MP4, etc.)
  • Um servidor de mídia especial exibe esse contêiner (arquivo MP4 ou outro formato) para um cliente (talvez um player de vídeo HTML5 em execução no navegador de alguém) por meio de um 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, apresenta aos usuários o HTML5 Player de vídeo
• Eu poderia hospedar um arquivo MP4 de um servidor web , como nginx ou httpd, mas como esses servidores não são servidores RTSP, só seria capaz de tratar pedidos para o MP4 como pedidos de download , e assim, seria incapaz de transmitir os arquivos de mídia
  • Da mesma forma, se eu usasse curl para buscar os arquivos de um servidor nginx, já que nem curl nem 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 fluxo contínuo (VideoLAN, Red5, Wowza, etc.), e uso um cliente RTSP (ou qualquer cliente de mídia de fluxo compatível) para solicitar um fluxo desse servidor < strong> that then and only then qualquer streaming real ocorre
  • Portanto, embora os "vídeos" do YouTube ou do Vimeo estejam hospedados em páginas HTML veiculadas por HTTP (S) por servidores HTTP, presumo que os players de vídeo incorporados nessas páginas (que são os locais em que os vídeos realmente são reproduzidos) estão realmente iniciando uma segunda conexão subsequente a um servidor de streaming, e o streaming está ocorrendo em RTSP ou em algum outro protocolo não HTTP

Então, esse é o meu entendimento, e acho que primeiro eu pergunto se algo que eu tenha dito acima está incorreto, por favor, comece corrigindo-me! Supondo que eu esteja mais ou menos correto:

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

    

Answer 1

How do streaming media players, running inside HTML pages and served by HTML servers, establish streaming (RTSP, etc.) connections with streaming media servers (serving RTSP requests)?

Aplicativos comuns

RTSP atualmente parece ser mais usado com aplicativos / interfaces de dispositivos que diretamente fluxo ao vivo (por exemplo, câmera IP) ou re-stream (como um mecanismo) do que para transmitir arquivos de mídia salvos a partir de um local físico por meio de uma interface HTTP de reprodução na Web com um jogador incorporado.

Parece que RTSP é um protocolo stateful e usa UDP mais que TCP quando streaming, e é usado mais como um dispositivo de servidor (como uma câmera IP) que está conectado a uma rede TCP / IP, e transmite fluxos via UDP, etc. Você então se conecta a esses feeds (o servidor) como o cliente no mesma rede e você pode emitir solicitações RTSP para utilizar adequadamente.

^{Protocol directives}

^{While similar in some ways to HTTP, RTSP defines control sequences useful in controlling multimedia playback. While HTTP is stateless, RTSP has state; an identifier is used when needed to track concurrent sessions. Like HTTP, RTSP uses TCP to maintain an end-to-end connection and, while most RTSP control messages are sent by the client to the server, some commands travel in the other direction (i.e. from server to client).}

^{Presented here are the basic RTSP requests. Some typical HTTP requests, like the OPTIONS request, are also available. The default transport layer port number is 554[3] for both TCP and UDP, the latter being rarely used for the control requests.}

^_source

^Stateless

^{A stateless protocol does not require the server to retain session information or status about each communications partner for the duration of multiple requests. In contrast, a protocol which requires keeping of the internal state on the server is known as a stateful protocol.}

^{A disadvantage of statelessness is that it may be necessary to include additional information in every request, and this extra information will need to be interpreted by the server.}

^_source

Fluxo Lógico

A maneira como eu entendo o fluxo de mídia de fluxo nessa forma é:

• o servidor no qual o conteúdo de mídia reside encapsulará, comprimirá, codificará, etc., o conteúdo de dados de vídeo / áudio nos formatos e segmentos adequados para entrega de fluxo
• o servidor da web que ouve conexões para acessar a mídia de fluxo contínuo fornecerá todos os recursos necessários para transmitir a mídia
• o cliente solicita e faz o download de recursos e arquivos aplicáveis e, em seguida, os reúne de maneira contínua para reprodução por meio do ponteiro de URL, conforme configurado e outros parâmetros. O software de reprodução no nível do cliente reúne os pacotes transmitidos em seqüência para permitir a reprodução adequada do conteúdo.

Consulte a seção Streaming Technologies abaixo para uma comparação geral entre HTTP e RTSP.

Além disso

Na seção abaixo 10 razões pelas quais 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, diz que o site que possui os controles do media player incorporado:

• ⁽¹⁾ detecta as configurações do navegador da web do cliente na "conexão e solicitar "do cliente e
• ⁽²⁾ isto irá definir o codec e qualquer outro lado do cliente configurações de detecção para valores de parâmetros aplicáveis e, em seguida,
• ⁽³⁾ ele transmitirá o vídeo diretamente do servidor de streaming você hospeda os arquivos de vídeo e áudio em com base em mais código em seu configurações do media player incorporado apontando para a URL da mídia arquivo no servidor hospedado.

^{Streaming Technologies}

^{The client browser must receive the data from the server and pass it to the streaming application for processing. The streaming application converts the data into pictures and sounds. An important factor in the success of this process is the ability of the client to receive data faster that the application can display the information. Excess data is stored in a buffer – an area of memory reserved for data storage within the application. If the data is delayed in transfer between the two systems, the buffer empties and the presentation of the material will not be smooth.}

^{HTTP Protocol}

^{The HTTP is the predominant way in which documents are linked on the Internet. The client makes a connection to the server containing the file to be streamed, the file is retrieved and the connection closed. The HTTP server communicates to the browser the type of file to be transferred.}

^{Benefits Using HTTP}

^{When streaming a file using HTTP, a special streaming server is not required. As long as your browser understands MIME types it can receive a streaming file from a HTTP server. One of the distinct advantages of streaming files using HTTP is that it can pass through firewalls and utilize proxy servers.}

^{Some Disadvantages}

^{HTTP streaming uses TCP/IP (Transmission Control Protocol and Internet Protocol) to ensure reliable delivery of the files. This process checks for missing packets and asks for them to be retransmitted. This become problematic in the streaming scenario when you want the data to be disregarded if it is lost in delivery, so dynamic files keep playing. HTTP cannot detect modem speed so server administrators must purposefully produce files at different compression rates to server users with different types of connections. Streaming files from HTTP servers is not recommended for high-demand situations.}

^{RTSP Protocol}

^{RTSP is the standard protocol used by most of the streaming server vendors. RTSP servers use the UDP (User Datagram Protocol) to transfer media files. UDP does not continually check that files have arrived at their destination. This is an advantage for streaming applications because it allows for file transfers to be interrupted as long as the delay is not too long. The result of this method is that there is data loss at times, but files continue to play if the delay is small.}

^source

^{10 Reasons Why You Should Never Host Your Own Videos}

^{We’re Talking About Embedding vs. Self-Hosted Video}

^{First, you upload your video file to a third-party video hosting service like YouTube, Vimeo, or Wistia.}

^{Then, you copy a small bit of code that they furnish to you, and paste it into your post or page on your own WordPress site. The video will appear on your site, in the location where you pasted the embed code, but the video itself is being streamed from the video host’s servers, as opposed to your own web server, where your WordPress site is hosted.}

^{4. No Single File Format Standard for Web Video}

^{The current HTML5 draft specification does not specify which video formats browsers should support. As a result, the major web browsers have diverged, each one supporting a different format. Internet Explorer and Safari will play H.264 (MP4) videos, but not WebM or Ogg. Firefox will play Ogg or WebM videos, but not H.264. Thankfully, Chrome will play all the major video formats, but if you want to ensure your video will play back on all the major web browsers, you’ll have to convert your video into multiple formats: .mp4, .ogv, and .webm}

^{5. Hope you like converting videos. A lot.}

^{Most of your audience will likely watch your videos from their desktop or laptop with the benefit of a high-speed Internet connection. For those folks, you’ll want to deliver a large, HD-quality file so they can watch it full-screen if they so choose. Generally, this means a 1080p or 720p file at a high streaming bitrate (5000 – 8000 kbps).}

^{But you’ll also want to encode a smaller, lower-resolution version for delivery to mobile devices like phones and tablets, as well as delivery to viewers with slower Internet connections.}

^{6. Video Players}

^{A video player is a small piece of web software you install on your site that will automatically detect which device is requesting your video, along with its connection speed, and then deliver the appropriate version to that person.}

^{7. Cumbersome Code [or Shortcodes]}

^{Whether you use a third-party plugin or WordPress’ built-in video capabilities, you’ll need to create a bit of code to tell the video player which formats you’ve created, as well as their location on the server. It looks something like this…}

<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>

So what’s the best solution for adding video to your site?

Simply use a third-party video hosting service, then just embed your video into your WordPress post or page.

Step One: Upload your video to one of the popular, well-established video hosting services like Vimeo PRO.

Step Two: Once your video has been uploaded and is ready for viewing, copy the URL to your video. Return to your WordPress site and paste the URL into your post or page where you want the video to appear.

     

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

     

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

     

_source

    

Answer 2

Eu vou tratar abaixo principalmente sua pergunta sobre o que acontece quando um vídeo é exibido no navegador. O assunto é vasto, por isso só vou tocar sobre os itens relevantes.

O HTML5 introduziu a tag <VIDEO> , que resolveu o problema da integração o vídeo exibido no navegador enquanto estiver usando JavaScript e CSS. A tag <OBJECT> anterior precisava de 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 tenha sido imposto. O resultado foi total fragmentação dos padrões, para os quais a única solução é que o vídeo servidor disponibilizará vários formatos de vídeo e que todos esses as fontes devem ser especificadas na tag <VIDEO> , a partir da qual o navegador escolherá aquele que suporta.

Um exemplo de uma tag com várias origens:

<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 tag <VIDEO> é independente do protocolo, portanto, pode usar qualquer protocolo suportado pelo navegador, incluindo RTSP. Suporte para o protocolo MPEG-DASH (Dynamic Adaptive Streaming over HTTP) ultimamente se tornou muito abrangente, por isso vai jogar na maioria dos dispositivos e navegadores nativos, ou usando HTML5, o que significa que nenhum plug-in extra é necessário. Veja este Gráfico de compatibilidade de dispositivos e navegadores . Veja também este artigo da Mozilla para preparar seu servidor para servir MPEG-DASH. O DASH funciona via HTTP, então isso funcionará enquanto seu servidor HTTP suportar solicitações de intervalo de bytes e está configurado para servir arquivos .mpd com mimetype="application/dash+xml" .

A interação normal entre cliente e servidor é semelhante à seguinte. Para HTML5 VIDEO, o navegador também é o player, embora possa abrir um novo conexão para jogar.

Aconexãoinicialforneceosmetadadosqueoclienteusaparaexibirovídeo.SeoprotocoloRTSPfoiusadoparaobteressesmetadados,entãoAconexãoRTPéposteriormentecriadaparatransferirosdadosdevídeo+áudio.OprotocoloRTCPéusadoparatransferircomandosadicionaisparaoservidor.

RTP,RTCPeRTSPoperamemportasdiferentes.Normalmente,quandooRTPestánaportaN,oRTCPestánaportaN+1.UmasessãoRTPpodecontermúltiplosfluxosaseremcombinadosnofinaldoreceptor;Porexemplo,áudioevídeopodemestaremcanaisseparados.

Paraqueninguémfiquebloqueadodoseuconteúdo,vocêdevedisponibilizarambososcodecslivresderoyalties,webMouTheoraevídeoH.264,eáudioVorbiseMP3.(Fácildisse,difícildefazer.)

IssoéoqueaconteceemdetalhesparaoRTSP:

1. OclienteestabeleceumaconexãoTCPcomosservidores,geralmentenaportaTCP554,aportaconhecidaparaoRTSP.

2. OclientecomeçaráaemitirumasériedecomandosdecabeçalhoRTSPquetenhamumformatosemelhanteaoHTTP,cadaumdelesreconhecidopeloservidor.DentrodessescomandosRTSP,oclientedescreveráosdetalhesdoservidordosrequisitosdasessão,comoaversãodoRTSPqueelesuporta,otransporteaserusadoparaofluxodedadosequalquerinformaçãodeportaUDPouTCPassociada.EssasinformaçõessãopassadasusandooscabeçalhosDESCRIBEeSETUPesãoaumentadasnarespostadoservidorcomumIDdesessãoqueocliente,equalquerdispositivoproxytransitório,podeusarparaidentificarofluxoemfuturastrocas.

3. Umavezconcluídaanegociaçãodosparâmetrosdetransporte,oclienteemitiráumcomandoPLAYparainstruiroservidorainiciaraentregadofluxodedadosRTP.

4. Depoisqueoclientedecidefecharofluxo,umcomandoTEARDOWNéemitidojuntocomoIDdasessãoinstruindooservidorainterromperaentregaRTPassociadaaesseID.

Leituraadicional:

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

Answer 3

Aqui está uma resposta rápida e suja -

Há uma diferença entre reproduzir 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) faz o download desse player e o executa. O jogador, por sua vez, busca vídeo de um URL de download simples. De fato, mesmo com o Youtube, existem programas que permitem acessar os arquivos de vídeo hospedados diretamente e baixá-los como você faria com qualquer arquivo. Como o sistema usa um link de download antigo comum, não há necessidade de protocolos complexos de streaming, como o RTSP

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