Transmisión de medios desde páginas HTML internas, por ejemplo

Así que soy un ingeniero de software que intenta comprender algunos detalles esenciales sobre cómo funcionan los medios de transmisión. He pasado la mayor parte del día tratando de comprender los diversos códecs, formatos de contenedor y protocolos de transmisión que son pertinentes para mi aplicación. Hasta ahora, aquí está mi comprensión de cómo funciona, que bien podría confundirse:

• La transmisión de medios realmente se reduce a formato de contenedor y protocolo de transmisión :
  • Todos los datos de audio están codificados (a través de un códec de audio) en un flujo de bits de audio
  • Todos los datos de video están codificados (nuevamente, a través de un códec) en un flujo de bits de video
  • Las dos corrientes se fusionan ( ¿multiplexan? ) Juntas en un contenedor que finalmente se convierte en un archivo (como MP4, etc.)
  • Un servidor de medios especial sirve este contenedor (archivo MP4 u otro formato) a un cliente (quizás un reproductor de video HTML5 que se ejecuta dentro del navegador de alguien) a través de algún protocolo de transmisión estándar, como RTSP
    • En el caso de un cliente de navegador, supongo que el navegador en sí tiene un cliente RTSP que luego presenta de alguna manera a los usuarios HTML5 Video Player
• Yo podía anfitrión de un archivo MP4 de una web servidor, como Nginx o httpd, pero desde aquellos servidores que no son servidores RTSP, sólo sería capaz de solicitudes placer para el MP4 como solicitudes de descarga , y por lo tanto, no sería capaz de transmitir los archivos multimedia
  • Del mismo modo, si tuviera que usar curlpara recuperar los archivos de un servidor nginx, ya que ni curlni nginx hablan RTSP, se trataría como una descarga de archivos
• Pero, cuando alojo un archivo MP4 de un servidor de transmisión de medios (VideoLAN, Red5, Wowza, etc.), y uso un cliente RTSP (o cualquier cliente de transmisión de medios compatible) para solicitar una transmisión de ese servidor, ese entonces y solo a continuación, haga algún real de streaming se producen
  • Por lo tanto, a pesar de que los "videos" de YouTube o Vimeo están alojados en páginas HTML servidas a través de HTTP (S) por servidores HTTP, supongo que los reproductores de video incrustados en esas páginas (que son donde realmente se reproducen los videos) en realidad están comenzando un segundo , conexión posterior a un servidor de transmisión y la transmisión se produce a través de RTSP o algún otro protocolo que no sea HTTP

Así que eso es lo que entiendo, y supongo que primero pediría que si algo de lo que he dicho anteriormente es incorrecto, ¡ comience por corregirme! Asumiendo que soy más o menos correcto:

¿Cómo los reproductores de medios de transmisión, que se ejecutan dentro de páginas HTML y son atendidos por servidores HTML, establecen conexiones de transmisión (RTSP, etc.) con servidores de medios de transmisión (que atienden solicitudes RTSP)?

¿Cómo los reproductores de medios de transmisión, que se ejecutan dentro de páginas HTML y son atendidos por servidores HTML, establecen conexiones de transmisión (RTSP, etc.) con servidores de medios de transmisión (que atienden solicitudes RTSP)?

Aplicaciones comunes

RTSP actualmente parece usarse más con aplicaciones / interfaces de dispositivos que transmiten directamente en vivo (por ejemplo, cámara IP) o retransmiten (como un motor) que para transmitir archivos multimedia guardados desde una ubicación física a través de una interfaz de reproducción web HTTP con jugador incrustado

Parece que RTSP es un protocolo con estado y usa UDP más que TCP cuando se transmite, y se usa más como un dispositivo de servidor (como una cámara IP) que está conectado a una red TCP / IP y alimenta las transmisiones a través de UDP, etc. Luego se conecta a estos feeds (el servidor) como el cliente en la misma red y puede emitir solicitudes RTSP para utilizar en consecuencia.

^{Directivas de protocolo}

^{Si bien es similar en algunos aspectos a HTTP, RTSP define secuencias de control útiles para controlar la reproducción multimedia. Mientras HTTP no tiene estado , RTSP tiene estado; se utiliza un identificador cuando es necesario para rastrear sesiones concurrentes. Al igual que HTTP, RTSP usa TCP para mantener una conexión de extremo a extremo y, aunque el cliente envía la mayoría de los mensajes de control RTSP al servidor, algunos comandos viajan en la otra dirección (es decir, de servidor a cliente).}

^{Aquí se presentan las solicitudes básicas de RTSP. Algunas solicitudes HTTP típicas, como la solicitud OPTIONS, también están disponibles. El número de puerto de la capa de transporte predeterminado es 554 [3] tanto para TCP como para UDP, este último rara vez se usa para las solicitudes de control.}

^_fuente

^Apátrida

^{Un protocolo sin estado no requiere que el servidor retenga la información de la sesión o el estado de cada interlocutor durante la duración de múltiples solicitudes. Por el contrario, un protocolo que requiere mantener el estado interno en el servidor se conoce como protocolo con estado .}

^{Una desventaja de la apatridia es que puede ser necesario incluir información adicional en cada solicitud, y esta información adicional deberá ser interpretada por el servidor.}

^_fuente

Flujo lógico

La forma en que entiendo el flujo de transmisión de medios en este formulario es:

• el servidor donde reside el contenido multimedia encapsulará, comprimirá, codificará, etc. el contenido de datos de video / audio en los formatos y segmentos adecuados para la entrega de la transmisión
• el servidor web que escucha las conexiones para acceder a los medios de transmisión entregará todos los recursos necesarios para transmitir los medios
• el cliente solicita y descarga los recursos y archivos aplicables, y luego los ensambla de manera continua para su reproducción a través del puntero URL como se configuró y otros parámetros. El software de reproducción a nivel del cliente ensambla los paquetes transmitidos en secuencia para permitir la reproducción adecuada del contenido.

Consulte la sección Tecnologías de transmisión a continuación para obtener una comparación general de HTTP versus RTSP.

además

En las siguientes 10 razones por las que nunca deberías alojar tus propios videos , he citado las partes que llegan al punto para ayudarte a responder tu pregunta en "general" sin ser demasiado específico.

Esencialmente dice que el sitio web que tiene los controles del reproductor multimedia incorporado:

• ⁽¹⁾ detectar la configuración del navegador web del cliente tras "conexión y solicitud" del cliente y
• ⁽²⁾ esto establecerá el códec y cualquier otra configuración de detección del lado del cliente a los valores de parámetros aplicables, y luego
• ⁽³⁾ transmitirá el video directamente desde el servidor de transmisión en el que aloja los archivos de video y audio según el código adicional en las configuraciones de su reproductor multimedia incorporado que apunta a la URL del archivo multimedia en el servidor alojado.

^{Tecnologías de transmisión}

^{El navegador del cliente debe recibir los datos del servidor y pasarlos a la aplicación de transmisión para su procesamiento. La aplicación de transmisión convierte los datos en imágenes y sonidos. Un factor importante en el éxito de este proceso es la capacidad del cliente para recibir datos más rápido de lo que la aplicación puede mostrar la información. El exceso de datos se almacena en un búfer, un área de memoria reservada para el almacenamiento de datos dentro de la aplicación. Si los datos se retrasan en la transferencia entre los dos sistemas, el búfer se vacía y la presentación del material no será fluida.}

^{Protocolo HTTP}

^{El HTTP es la forma predominante en la que los documentos están vinculados en Internet. El cliente realiza una conexión con el servidor que contiene el archivo a transmitir, el archivo se recupera y la conexión se cierra. El servidor HTTP comunica al navegador el tipo de archivo a transferir.}

^{Beneficios del uso de HTTP}

^{Cuando se transmite un archivo usando HTTP, no se requiere un servidor de transmisión especial. Mientras su navegador entienda los tipos MIME, puede recibir un archivo de transmisión desde un servidor HTTP. Una de las ventajas distintivas de la transmisión de archivos mediante HTTP es que puede pasar a través de firewalls y utilizar servidores proxy.}

^{Algunas desventajas}

^{La transmisión HTTP utiliza TCP / IP (Protocolo de control de transmisión y Protocolo de Internet) para garantizar la entrega confiable de los archivos. Este proceso busca paquetes faltantes y pide que se retransmitan. Esto se vuelve problemático en el escenario de transmisión cuando desea que los datos se descarten si se pierden en la entrega, por lo que los archivos dinámicos siguen reproduciéndose. HTTP no puede detectar la velocidad del módem, por lo que los administradores del servidor deben producir archivos a diferentes velocidades de compresión a los usuarios del servidor con diferentes tipos de conexiones. La transmisión de archivos desde servidores HTTP no se recomienda para situaciones de alta demanda.}

^{Protocolo RTSP}

^{RTSP es el protocolo estándar utilizado por la mayoría de los proveedores de servidores de transmisión. Los servidores RTSP usan el UDP (Protocolo de datagramas de usuario) para transferir archivos multimedia. UDP no verifica continuamente que los archivos hayan llegado a su destino. Esta es una ventaja para las aplicaciones de transmisión porque permite que las transferencias de archivos se interrumpan siempre que el retraso no sea demasiado largo. El resultado de este método es que a veces hay pérdida de datos, pero los archivos continúan reproduciéndose si el retraso es pequeño.}

^fuente

^{10 razones por las que nunca deberías alojar tus propios videos}

^{Estamos hablando de incrustación vs video autohospedado}

^{Primero, sube su archivo de video a un servicio de alojamiento de video de terceros como YouTube, Vimeo o Wistia.}

^{Luego, copia un pequeño código que te proporcionan y lo pegas en tu publicación o página en tu propio sitio de WordPress. El video aparecerá en su sitio, en la ubicación donde pegó el código de inserción, pero el video mismo se transmite desde los servidores del host de video, a diferencia de su propio servidor web, donde está alojado su sitio de WordPress.}

^{4. Sin formato de archivo único estándar para video web}

^{La especificación actual del borrador HTML5 no especifica qué formatos de video deberían admitir los navegadores. Como resultado, los principales navegadores web han divergido, y cada uno admite un formato diferente. Internet Explorer y Safari reproducirán videos H.264 (MP4), pero no WebM u Ogg. Firefox reproducirá videos Ogg o WebM, pero no H.264. Afortunadamente, Chrome reproducirá todos los formatos de video principales, pero si desea asegurarse de que su video se reproducirá en todos los principales navegadores web, tendrá que convertir su video en múltiples formatos: .mp4, .ogv y .webm}

^{5. Espero que te guste convertir videos. Mucho.}

^{Es probable que la mayoría de su audiencia vea sus videos desde su computadora de escritorio o portátil con el beneficio de una conexión a Internet de alta velocidad. Para esas personas, querrá entregar un archivo grande de calidad HD para que puedan verlo en pantalla completa si así lo desean. En general, esto significa un archivo de 1080p o 720p a una velocidad de bits de transmisión alta (5000 - 8000 kbps).}

^{Pero también querrá codificar una versión más pequeña y de menor resolución para enviarla a dispositivos móviles como teléfonos y tabletas, así como entregarla a los espectadores con conexiones de Internet más lentas.}

^{6. Reproductores de video}

^{Un reproductor de video es una pequeña pieza de software web que instala en su sitio que detectará automáticamente qué dispositivo solicita su video, junto con su velocidad de conexión, y luego entregará la versión adecuada a esa persona.}

^{7. Código engorroso [o códigos cortos]}

^{Ya sea que use un complemento de terceros o las capacidades de video integradas de WordPress, deberá crear un poco de código para decirle al reproductor de video qué formatos ha creado, así como su ubicación en el servidor. Se parece a algo así ...}

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

Entonces, ¿cuál es la mejor solución para agregar video a su sitio?

Simplemente use un servicio de alojamiento de video de terceros, luego incruste su video en su publicación o página de WordPress.

Paso uno: cargue su video en uno de los servicios de alojamiento de video populares y bien establecidos como Vimeo PRO.

Paso dos: Una vez que su video se haya cargado y esté listo para ser visto, copie la URL a su video. Regrese a su sitio de WordPress y pegue la URL en su publicación o página donde desea que aparezca el video.

---

^{Cuando la gente vea su página, el video aparecerá en la ubicación donde pegó la URL. Pero el archivo de video en sí mismo se transmitirá desde los servidores del host de video, a diferencia de su propio servidor, donde está alojado su sitio de WordPress.}

_{El reproductor de video incorporado detectará automáticamente el dispositivo del usuario, el navegador y la velocidad de conexión a Internet, y luego les entregará la versión adecuada del archivo de video. Nada que instalar en su sitio. No hay complementos para mantenerse al día. No hay código complicado.}

_fuente

Trataré a continuación principalmente su pregunta de lo que sucede cuando se muestra un video en el navegador. El tema es amplio, por lo que solo tocaré los elementos relevantes.

HTML5 ha introducido la <VIDEO>etiqueta que resolvió el problema de integrar el video que se muestra en el navegador al usar JavaScript y CSS. La <OBJECT>etiqueta anterior requería software externo y estaba mal integrada con la página. La nueva etiqueta en efecto requería que el navegador también se convirtiera en un reproductor de video, aunque no se impusieron estándares. El resultado fue una fragmentación total de los estándares, para lo cual la única solución es que el servidor de video pondrá a disposición varios formatos de video y que todas estas fuentes alternativas se especificarán en la <VIDEO>etiqueta, de la cual el navegador elegirá la que admite.

Un ejemplo de una etiqueta con múltiples fuentes:

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

La <VIDEO>etiqueta en sí es independiente del protocolo, por lo que puede usar cualquier protocolo compatible con el navegador, incluido RTSP. El soporte para el protocolo MPEG-DASH (Dynamic Adaptive Streaming over HTTP) se ha vuelto muy completo últimamente, por lo que se reproducirá en la mayoría de los dispositivos y navegadores nativos, o usando HTML5, lo que significa que no se requieren complementos adicionales. Consulte esta tabla de compatibilidad de dispositivos y navegadores . Consulte también este artículo de Mozilla para preparar su servidor para servir MPEG-DASH. DASH funciona a través de HTTP, por lo que funcionará siempre que su servidor HTTP admita solicitudes de rango de bytes y esté configurado para servir archivos .mpd mimetype="application/dash+xml".

La interacción normal entre el cliente y el servidor es similar a la siguiente. Para HTML5 VIDEO, el navegador también es el reproductor, aunque puede abrir una nueva conexión para jugar.

La conexión inicial proporciona los metadatos que el cliente usa para mostrar el video. Si se utilizó el protocolo RTSP para obtener esos metadatos, luego se crea una conexión RTP para transferir los datos de video + audio. El protocolo RTCP se usa para transferir comandos adicionales al servidor.

RTP, RTCP y RTSP operan en diferentes puertos. Por lo general, cuando RTP está en el puerto N, RTCP está en el puerto N + 1. Una sesión RTP puede contener múltiples flujos para ser combinados al final del receptor; por ejemplo, el audio y el video pueden estar en canales separados.

Para que nadie quede bloqueado de su contenido, debe poner a disposición códecs libres de regalías, webM o Theora, y video H.264, y audio Vorbis y MP3. (Fácil, difícil de hacer).

Esto es lo que sucede en detalle para RTSP:

1. El cliente establece una conexión TCP a los servidores, generalmente en el puerto TCP 554, el conocido puerto para RTSP.

2. Luego, el cliente comenzará a emitir una serie de comandos de encabezado RTSP que tienen un formato similar a HTTP, cada uno de los cuales es reconocido por el servidor. Dentro de estos comandos RTSP, el cliente describirá al servidor los detalles de los requisitos de la sesión, como la versión de RTSP que admite, el transporte que se utilizará para el flujo de datos y cualquier información de puerto UDP o TCP asociado. Esta información se pasa usando los encabezados DESCRIBE y SETUP y se aumenta en la respuesta del servidor con una ID de sesión que el cliente y cualquier dispositivo proxy transitorio pueden usar para identificar la secuencia en intercambios posteriores.

3. Una vez que se haya completado la negociación de los parámetros de transporte, el cliente emitirá un comando PLAY para indicar al servidor que comience la entrega del flujo de datos RTP.

4. Una vez que el cliente decide cerrar la secuencia, se emite un comando de DESPLAZAMIENTO junto con la ID de sesión que indica al servidor que cese la entrega de RTP asociada con esa ID.

Otras lecturas :

• Conceptos básicos de los protocolos de transmisión
• Comprender los protocolos de la capa de aplicación: protocolo de transmisión en tiempo real (RTSP)
• Introducción al video HTML5 (Opera)
• Audio y video HTML5: lo que debe saber
• Análisis RTSP Wireshark

Aquí hay una respuesta rápida y sucia.

Hay una diferencia entre reproducir videos en la web y transmitirlos en tiempo real.

La reproducción se realiza por medio de un reproductor que está incluido en la página web (podría estar usando flash, JS o un objeto de video html5). El cliente (navegador) descarga este reproductor y lo ejecuta. El reproductor, a su vez, obtiene video de una simple URL de descarga. De hecho, incluso con Youtube, hay programas que le permiten acceder a los archivos de video alojados directamente y descargarlos como lo haría con cualquier archivo. Dado que el sistema usa un enlace de descarga antiguo regular, no hay necesidad de protocolos de transmisión complejos como RTSP

La transmisión en tiempo real (por ejemplo, desde una cámara web) es ... bueno, más complicada. Flash tiene esta funcionalidad incorporada, pero ya no debería usarse. El video HTML5 no admite la transmisión en tiempo real, pero las personas han podido "engañarlo" haciendo que el servidor de alojamiento de archivos cambie constantemente el archivo de video que ofrece.