Transmisión de video/audio en tiempo real (descarga no progresiva)

Question

Estoy tratando de entender conceptualmente la mejor manera de ofrecer contenido real de audio y video. Me gustaría que se consuma con un navegador web, utilizando la menor cantidad de tecnología patentada. No estaría sirviendo archivos estáticos y utilizando la descarga progresiva, esto sería secuencias de audio reales que se capturan en vivo. ¿Cómo se transmite una transmisión que estará razonablemente sincronizada con la fuente? ¿Qué tipo de protocolo es adecuado?

Editar:

En la investigación he encontrado que hay algunos protocolos: RTSP, HTTP Streaming, RTMP, y RTP.

La transmisión HTTP no es adecuada si está transmitiendo en vivo algún tipo de performance/comunicación porque depende de 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 sobre 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 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 fuente abierta, uno de ellos con el apoyo de apple here. Parece que esto podría hacer lo que yo quiero, y se ve como quite a few players support it. Parece que sería adecuado para una transmisión "en vivo" desde esta página here.

Gracias, Josh

Answer 1

En primer lugar, me dejaron desprender dos puntos incorrectos rápidamente. Detalles a seguir a continuación:

• RTMP se puede hacer por otros servidores que Flash Media Server
• TCP está muy bien para vivir. Hay demasiados F.U.D. de la gente amante de UDP por ahí. Apple has just released a draft specification de hacer una transmisión simple en vivo a través de 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 firewalls corporativos con mucha más frecuencia y facilidad.

Mi lectura es que la transmisión compleja y basada en UDP se está reduciendo. No estoy pronosticando la muerte, solo una parte menor y 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 simplemente no son tan tangibles.

Usted dice que no quiere que la tecnología patentada, y "basura en [Flash]", pero todavía quiere hacer el streaming real? Odio decírtelo, pero tanto RealAudio como RealVideo son ambos propietarios.

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

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

Si el pragmatismo saca lo mejor de ti, entonces reconsiderar su aversión a los productos de Adobe. Recuerde, Flash tiene una distribución más amplia 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 lo más interesante: puede transmitir en vivo a navegadores habilitados para Flash.

Yo recomendaría pensar en sus prioridades. Deletéreos para nosotros en tu pregunta.

Answer 2

Me gustaría agregar a la respuesta de Stu que los protocolos de transmisión basados ​​en UDP a menudo tienen complejidad adicional para trabajar cuando están detrás de firewalls o NAT. Por ejemplo, si planea usar puntos de acceso WIFI fuera de la casa, muchos de ellos no admitirán RTP mediante la entrega de UDP. Muchos clientes tienen un mecanismo de conmutación por recuperación donde si no se reciben paquetes antes de un tiempo de espera, el cliente intentará la entrega de TCP.