Solución:
¿Cómo los reproductores de medios de transmisión, que se ejecutan dentro de páginas HTML y servidos por servidores HTML, establecen conexiones de transmisión (RTSP, etc.) con servidores de medios de transmisión (que atienden solicitudes RTSP)?
Aplicaciones Comunes
Actualmente, RTSP parece usarse más con aplicaciones / interfaces de dispositivos que directamente transmisión en vivo (por ejemplo, cámara IP) o retransmitir (como un motor) de lo que es para transmisión de archivos multimedia guardados desde una ubicación física a través de una interfaz de reproducción web HTTP con un reproductor integrado.
Parece que RTSP es un 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 envía transmisiones a través de UDP, etc. Luego, se conecta a estas fuentes (el servidor) como el cliente en la misma red y puede emitir Solicitudes de RTSP 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 que HTTP no tiene estado, RTSP tiene estado; se utiliza un identificador cuando es necesario para realizar un seguimiento de las sesiones simultáneas. Al igual que HTTP, RTSP usa TCP para mantener una conexión de extremo a extremo y, aunque la mayoría de los mensajes de control de RTSP son enviados por el cliente 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 utiliza 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 socio de comunicaciones durante la duración de múltiples solicitudes. Por el contrario, un protocolo que requiere mantener el estado interno del 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 el servidor deberá interpretar esta información adicional.
fuente
Flujo lógico
La forma en que entiendo el flujo de medios de transmisión en esta forma 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 transmisión por secuencias
- 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 reproducirlos a través del puntero de URL según lo configurado y otros parámetros. El software de reproducción a nivel de cliente ensambla los paquetes transmitidos en secuencia para permitir la reproducción adecuada del contenido.
Por favor vea el Tecnologías de transmisión sección a continuación para una comparación general de HTTP versus RTSP.
es más
En el de abajo 10 razones por las que nunca deberías alojar tus propios videos sección He citado las partes que van al grano para ayudar a responder su pregunta en “general” sin ser demasiado específico.
Básicamente, dice que el sitio web que tiene los controles del reproductor multimedia integrado:
- (1)detectar la configuración del navegador web del cliente tras la “conexión y solicitud” del cliente y
- (2)esto establecerá el códec y cualquier otra configuración de detección del lado del cliente a los valores de parámetro aplicables, y luego
- (3)transmitirá el video directamente desde el servidor de transmisión en el que aloja los archivos de video y audio basado en código adicional en las configuraciones de su reproductor multimedia integrado 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 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 la transferencia de datos se retrasa entre los dos sistemas, el búfer se vacía y la presentación del material no será fluida.
Protocolo HTTP
HTTP es la forma predominante de vinculación de documentos en Internet. El cliente establece una conexión con el servidor que contiene el archivo que se va a transmitir, el archivo se recupera y la conexión se cierra. El servidor HTTP comunica al navegador el tipo de archivo que se va a transferir.
Beneficios del uso de HTTP
Cuando se transmite un archivo mediante HTTP, no se requiere un servidor de transmisión especial. Siempre que su navegador comprenda 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 atravesar 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 comprueba si hay paquetes faltantes y solicita su retransmisión. Esto se vuelve problemático en el escenario de transmisión cuando desea que los datos se ignoren si se pierden en la entrega, por lo que los archivos dinámicos se siguen reproduciendo. HTTP no puede detectar la velocidad del módem, por lo que los administradores del servidor deben producir deliberadamente archivos con diferentes tasas de compresión para los usuarios del servidor con diferentes tipos de conexiones. No se recomienda la transmisión de archivos desde servidores HTTP 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 utilizan el UDP (Protocolo de datagramas de usuario) para transferir archivos multimedia. UDP no comprueba 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 se pierden 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 frente a video autohospedado
Primero, sube su archivo de video a un servicio de alojamiento de videos de terceros como YouTube, Vimeo o Wistia.
Luego, copia un pequeño fragmento de código que le proporcionan y lo pega en su publicación o página en su 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 en sí se transmite desde los servidores del host de video, a diferencia de su propio servidor web, donde está alojado su sitio de WordPress.
4. No hay estándar de formato de archivo único para video web
La especificación actual del borrador de HTML5 no especifica qué formatos de video deben 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 reproduzca en todos los navegadores web principales, tendrá que convertir su video en varios formatos: .mp4, .ogv y .webm
5. Espero que te guste convertir videos. Mucho.
La mayoría de su audiencia probablemente verá 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. Generalmente, esto significa un archivo de 1080p o 720p con una alta tasa de transmisión de bits (5000 – 8000 kbps).
Pero también querrá codificar una versión más pequeña y de menor resolución para la entrega a dispositivos móviles como teléfonos y tabletas, así como para la entrega a los espectadores con conexiones a Internet más lentas.
6. Reproductores de video
Un reproductor de video es una pequeña pieza de software web que instalas en tu sitio que detectará automáticamente qué dispositivo está solicitando tu video, junto con su velocidad de conexión, y luego entregará la versión apropiada a esa persona.
7. Código engorroso [or Shortcodes]
Ya sea que use un complemento de terceros o las capacidades de video integradas de WordPress, deberá crear un poco de código para indicarle al reproductor de video qué formatos ha creado, así como su ubicación en el servidor. Se parece a esto …
<video poster="movie.jpg" controls> <source src="https://foroayuda.es/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 videos a su sitio?
Simplemente use un servicio de alojamiento de videos de terceros, luego simplemente incruste su video en su publicación o página de WordPress.
Paso uno: Sube tu video a uno de los servicios de alojamiento de videos más populares y bien establecidos, como Vimeo PRO.
Segundo paso: Una vez que su video se haya subido y esté listo para su visualización, 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í 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 apropiada del archivo de video. Nada para instalar en su sitio. No hay complementos para mantenerse actualizado. Sin código complicado.
fuente
A continuación, trataré principalmente su pregunta sobre qué sucede cuando se muestra un video en el navegador. El tema es vasto, por lo que solo tocaré los temas relevantes.
HTML5 ha introducido la <VIDEO> etiqueta que resolvió el problema de integrar el video mostrado en el navegador mientras se usa JavaScript y CSS. El anterior <OBJECT> La etiqueta requería software externo y estaba mal integrada con la página. En efecto, la nueva etiqueta 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 especifiquen en el <VIDEO> etiqueta, de la cual el navegador seleccionará la que admita.
Un ejemplo de una etiqueta con múltiples fuentes:
<video width=320 height=240 controls poster=image.jpg>
<source src="https://foroayuda.es/movie.mpd">
<source src="https://foroayuda.es/movie.webm">
Your browser does not support the video tag.
</video>
los <VIDEO> La 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 sobre 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 que funcione con 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 con mimetype="application/dash+xml".
La interacción normal entre cliente y servidor es similar a lo 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 usó 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 utiliza 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 que se combinarán en el extremo del receptor; por ejemplo, el audio y el video pueden estar en canales separados.
Para que nadie se quede bloqueado de su contenido, debe poner a disposición tanto los códecs libres de derechos, webM o Theora, como el video H.264, y el audio Vorbis y MP3. (Fácil dicho, difícil de hacer).
Esto es lo que sucede en detalle para RTSP:
-
El cliente establece una conexión TCP con los servidores, normalmente en el puerto TCP 554, el puerto conocido para RTSP.
-
Luego, el cliente comenzará a emitir una serie de comandos de encabezado RTSP que tienen un formato similar al 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 asociada. Esta información se pasa utilizando los encabezados DESCRIBE y SETUP y se aumenta en la respuesta del servidor con un ID de sesión que el cliente y cualquier dispositivo proxy transitorio pueden usar para identificar el flujo en intercambios posteriores.
-
Una vez que se ha completado la negociación de los parámetros de transporte, el cliente emitirá un comando REPRODUCIR para indicar al servidor que comience la entrega del flujo de datos RTP.
-
Una vez que el cliente decide cerrar la secuencia, se emite un comando TEARDOWN junto con el ID de sesión que indica al servidor que cese la entrega RTP asociada con ese ID.
Otras lecturas :
- Conceptos básicos de los protocolos de transmisión
- Comprensión de los protocolos de 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