Este tema es muy cercano y querido para mí, ya que soy parte del equipo de Microsoft que está utilizando ampliamente HTTP como la nueva forma de transmisión. Considere esto como una revelación de mi parte. Dicho esto, las opiniones expresadas en esta respuesta son mías.
Los protocolos de transmisión tradicionales como RTSP / RTMP ofrecen excelentes opciones para la transmisión, ya que permiten el control sobre lo que se envía a un cliente y también ofrecen la opción de controlar la transmisión al cliente en función de lo rápido que consumen. Hay una conexión 1-1 entre el cliente y el servidor y el cliente solicita el video del servidor. El servidor a su vez envía este video a un ritmo que el cliente puede consumir. Además, el cliente podría enviar más comandos al servidor para controlar algunos aspectos de lo que espera (por ejemplo, comandos como reproducir / pausar / cambiar el idioma de audio). Todo suena genial. Sin embargo, un gran desafío con este enfoque es que cuando se conecta en línea es muy difícil de escalar. Como cada conexión es 1-1, está sujeto a cuántos clientes puede admitir un servidor. La opción aquí es agregar más servidores. Además, cuando utiliza una red de entrega de contenido (CDN) para acelerar, deben configurar una red dedicada para la transmisión.
La otra opción discutida en el hilo era la descarga progresiva. En este caso, aloja un video en el servidor web y el cliente lo descarga como cualquier otro contenido a través de HTTP (por ejemplo, una página html). Esto es genial ya que la transacción puede ser apátrida. Esto significa que podría servir al cliente a través de un caché, etc. Puedo profundizar más si me ayuda, solo envíeme una nota. El problema con este enfoque es a menudo el ancho de banda desperdiciado y la falta de control. El cliente a menudo termina descargando más de lo que necesitaría. Imagine un video de YouTube en el que solo mira un primer minuto durante 5 minutos. video y date cuenta de que no es para ti. Si la red es buena, puede terminar descargando todo el video. ¡Que desperdicio!
- Cómo hacer un elemento en mi página web como este en un enlace
- ¿Qué hace que sitios web como Slickdeals e INRDeals sean tan pegajosos para los usuarios?
- ¿Cómo descubres nichos de lo que las personas buscan en Google?
- ¿El rediseño de un sitio web afecta su clasificación?
- ¿Puedes recomendar sitios web donde uno pueda intercambiar habilidades por otras habilidades? (como Skilltrade)
Mientras discutimos el futuro de la transmisión, realmente necesitamos tener un enfoque híbrido aquí. Una buena solución sería:
- Uno que escala. Esto significa que la conexión debe ser sin estado (sin conexión 1-1 entre el servidor y el cliente).
- El tráfico debe ser sobre HTTP. La razón es que la mayoría de las redes soportan HTTP. Por ejemplo, los CDN ya tienen una red HTTP enorme y no deberían necesitar pararse en una red independiente.
- Uno que minimiza el desperdicio de ancho de banda de la red. El cliente debe descargar solo lo que necesita.
Además de lo anterior, la transmisión HTTP permite mejorar la experiencia del usuario al admitir la transmisión adaptativa mucho mejor que la transmisión tradicional. La transmisión adaptativa permite ajustar la calidad de la reproducción de video en el cliente de acuerdo con las capacidades de la red / máquina. En cada uno de estos casos, el cliente elige la mejor calidad de acuerdo con la red y otras condiciones de recursos. Ejemplos de estas tecnologías son:
- Microsoft IIS Smooth Streaming
- Apple HTTP Live Streaming (esto también se discute en la respuesta de Jeff)
- Adobe HTTP Dynamic Streaming
Para resumir, como ya estamos viendo, la transmisión adaptativa HTTP se está convirtiendo en la norma con servicios como Netflix, ESPN y NBC Olympics. Es probable que vea que el uso de la transmisión tradicional como RTSP / RTMP disminuya rápidamente.
También di una charla sobre Microsoft IIS Smooth Streaming en PDC 09. Si bien esta charla trata sobre Smooth Streaming, en general tendrá una buena idea de lo que significa la transmisión adaptativa: http://www.microsoftpdc.com/2009….
