Streaming Video / Audio basado en navegador (no descarga progresiva)

Question

Estoy tratando de entender conceptualmente la mejor manera de entregar contenido de audio y video de transmisión real. Me gustaría que se consumiera con un navegador web, utilizando la menor cantidad de tecnología patentada. No estaría sirviendo archivos estáticos y usando descargas progresivas, estas serían transmisiones de audio reales capturadas en vivo. ¿Cómo se transmite una transmisión que estará razonablemente sincronizada con la fuente? ¿Qué tipo de protocolo es adecuado?

Edición :

En una investigación descubrí que hay algunos protocolos: RTSP, HTTP Streaming, RTMP y RTP.

La

transmisión HTTP es algo inadecuada si está transmitiendo una presentación / comunicación en vivo de algún tipo porque se basa en TCP (como su base HTTP) y no pierde paquetes. En una situación de bajo ancho de banda, el cliente puede retrasarse significativamente en la reproducción. ref

RTMP es una tecnología patentada que requiere un servidor de medios flash. Mierda en eso. La razón por la que miré flash es porque son extremadamente flexibles en lo que respecta a la experiencia del usuario. SoundManager2 proporciona una excelente interfaz de JavaScript para reproducir archivos multimedia con flash. Esto es lo que buscaría en una aplicación cliente.

RTSP / RTP es lo que Microsoft cambió a usar, desaprobando su protocolo MMS. RTSP es el protocolo de control. Es similar a HTTP con algunas diferencias distintas: el servidor también puede hablar con el cliente y hay comandos adicionales, como PAUSE. También es un protocolo con estado, que se mantiene con una identificación de sesión. RTP es el protocolo para entregar la carga útil (audio o video codificado). Hay algunos proyectos de código abierto, uno de ellos con el respaldo de apple aquí . Parece que esto podría hacer lo que quiero, y parece que bastantes jugadores lo admiten. . Parece que sería adecuado para un "en vivo" transmitido desde esta página aquí .

Gracias Josh

Answer 1

Primero, déjame eliminar dos puntos incorrectos rápidamente. Detalles a seguir a continuación:

• RTMP se puede hacer en otros servidores que no sean Flash Media Server
• TCP está bien para vivir. Hay demasiado F.U.D. de la gente que ama UDP por ahí. Apple acaba de lanzar un borrador de especificación de hacer transmisiones en vivo simples sobre HTTP (y, por lo tanto, TCP) para el iPhone. Espero que termine en los navegadores también. Además, TCP tiene la ventaja de atravesar los firewalls corporativos con mucha más frecuencia y facilidad.

Mi lectura es que la transmisión compleja y basada en UDP está disminuyendo gradualmente. No estoy pronosticando la muerte, solo una parte cada vez menor del mercado. Los servidores de transmisión basados ??en UDP consumen enormes recursos, en relación con las soluciones basadas en TCP (como 10x o más), y los beneficios no son tan tangibles.

¿Dices que no quieres tecnología patentada y " mierda en [Flash] " ;, pero aún quieres hacer Real streaming? Odio decírtelo, pero tanto RealAudio como RealVideo son propiedad de ambos.

Si ir a Open Source es realmente tan importante para usted, lo que puedo entender, entonces deberá ignorar la gran mayoría del mercado de medios de transmisión. Echa un vistazo a

• Theora : un video libre de regalías, estándar abierto y con pérdidas tecnología de compresión
• Vorbis : un software libre / proyecto de código abierto que produce un audio especificación de formato e implementación de software para compresión de audio con pérdida.
• Ogg : un formato de contenedor estándar abierto y gratuito

Si el pragmatismo se apodera de ti, reconsidera tu aversión a los productos de Adobe. Recuerde, Flash se distribuye más ampliamente que cualquier otro reproductor basado en navegador (es decir, Windows Media Player, Quick Time y Real Players).

Todavía puede usar RTMP con código abierto: Red5 es probablemente de gran interés: puede transmitir en vivo a Flash navegadores habilitados.

Recomendaría pensar en sus prioridades. Escríbalos en su pregunta.

Answer 2

Agregaría a la respuesta de Stu que los protocolos de transmisión basados ??en UDP a menudo tienen una complejidad adicional para trabajar cuando están detrás de firewalls o NAT. Por ejemplo, si planea usar puntos de acceso WIFI fuera del hogar, muchos de estos no admitirán RTP mediante la entrega UDP. Muchos clientes tienen un mecanismo de recuperación de fallas en el que si no se reciben paquetes antes de un tiempo de espera, el cliente intentará la entrega TCP.