04 Streaming
04 Streaming
04 Streaming
1. Introduccin
una tasa predeterminada para el envi de los datos. TCP incrementar dicha tasa hasta
que una prdida significativa de los paquetes que se han enviado indique que la red se
encuentra congestionada. Y en dicho punto, como consecuencia, la tasa de envo
disminuir. Otra desventaja que presenta TCP para su uso en streaming de video, es
que TCP hace uso del mecanismo de ventana deslizante para el control del flujo de
datos. Esto da como resultado que los paquetes se procesen ni bien llegan, por lo que
si la informacin llega muy rpido puede darse un buffer overflow. En tal caso, el
cliente notificar al servidor que disminuya la tasa de envo, de forma de evitar dicho
inconveniente o la necesidad de memorias de reproduccin grandes para ocultar el
efecto de la prdida de un segmento al usuario.
Supongamos que uno quiere transmitir un stream codificado a 40 kbit/s. La
transmisin TCP podra empezar a 10 kbit/s. Luego podra llegar a 100 kbit/s , tasa
sobre la cual se congestionara la red y por ende, quedara definida la tasa mxima.
Supongamos ahora, que un nuevo usuario se conecta a la red y la transmisin se
acelera nuevamente a 30 kbit/s. En ningn momento la tasa de transferencia se
asemeja a la tasa de codificado del stream que se quiere transmitir. Lo que da lugar a
que el usuario note que el video se ha parado [8].
En el caso de que se de una recepcin incorrecta, si se utilizara UDP, la mejor opcin
en la interpolacin de los dato o algn otro tipo de compensacin, pero en este caso al
estar implementado sobre TCP, se reenva el paquete en cuestin.
A su vez, en steaming Tradicional se gana velocidad, dado que este posee un
menor retardo que TCP a costa de sacrificar la confiabilidad que TCP ofrece, pero que
es solucionada utilizando el protocolo RTCP y RTP.
Hay que destacar tambin, la posibilidad del streaming tradicional de proveer
el contenido por medio de tcnicas multicast, ideal para la difusin de medios en vivo.
Por otro lado, con el uso de RTCP, se podr sincronizar flujos de datos de audio y
video antes de realizar la operacin de descodificacin. Incluso brindar la posibilidad
multiservidor y la capacidad de agregar un nuevo stream en una presentacin en vivo.
Se podr informar al emisor los paquetes que se pierden, se podr cambiar el tipo de
codificacin, datos el tamao del buffer e incluso negociar el mtodo de transporte
ms adecuado antes de comenzar la transferencia del flujo datos [9] [10].
Mientras que si nos centramos en el streaming alternativo podemos afirmar
que es una alternativa ms fcil de configurar, permite dado que esta implementada
sobre HTTP, llegar a una mayor audiencia, y por sobre todas las cosas ofrece un
servicio que combinado con un servidor web permite dar una solucin acorde sin la
necesidad de grandes inversiones. Obviamente dispuesto a perder determinados
beneficios y la escalabilidad que el streaming tradicional ofrece.
4. Casos de Estudio
Se describen luego, los resultados obtenidos luego de haber analizado el
funcionamiento del streaming proporcionado por Youtube y Netflix.
4.1 Youtube
request.
Observamos que, al querer adelantar el video, lo que sucede es que se
cancela la descarga de la parte del video que actualmente se est reproduciendo y
comienza a descargarse y reproducirse la nueva parte del video desde la posicin
seleccionada por el usuario. En dicho request, es el atributo range, el que nos
determina la posicin de comienzo del video. Ms precisamente el range se refiere al
cdigo de tiempo de cada frame (fotograma o cuadro, es una imagen particular dentro
de una sucesin de imgenes que componen una animacin). A su vez, si dicha url la
decodificamos, la pegamos en la barra de direccin del navegador es posible
descargar el video desde esa posicin.
Se descarta tambin la posibilidad de encontrar paquetes RTP dado que sobre
TCP no tendran sentido. Y esto se debe a que RTP es una capa diseada para actuar
sobre protocolos no confiables proveyendo determinados beneficios como los que
proveen los protocolos confiables (garantiza orden, timestamp) sin las desventajas que
trae TCP, por lo que aplicar este tipo de combinacin sera totalmente desacertado.
Incluso utilizando Wireshark, no fue posible encontrar evidencia de paquetes con el
protocolo RTP.
La sospecha de que se estuviera haciendo DASH queda totalmente
descartada dado que no se encontraron archivos de extensin .f4v ni .F4M. El primero
seran los fragmentos que se divide el video que se esta stremeando, en cuyo
contenido se encuentra el video y el segundo describe el medio en cuestin, pudiendo
de esta forma ir determinando como debera ir variando el bitRate. Tal como establece
la especificacin de Adobe.
De todos modos, se pudo comprobar que independientemente de la
resolucin de video, en todos los casos siempre se experimento una descarga a las
mayores velocidades posibles y nunca cambiando la calidad de video durante la
reproduccin. La calidad de video en youtube es fija, si bien se puede cambiar
voluntariamente a lo largo del video, esta se mantendr constante y ser el ancho de
banda del cliente quin determine como se ver un video. A mayor ancho de banda,
mayor ser el bitrate que el cliente podr streamear. Y si se diera un cambio en la
calidad del video, producto de que youtube.com est haciendo DASH, el contenido
total del video descargado utilizando un ancho de banda y otro ancho de banda
diferente debera ser distinto. Sin embargo, utilizando 1Mb o 3Mb siempre, en cada
una de las resoluciones, el tamao del archivo final es aproximadamente el mismo.
Por lo que podemos concluir que youtube.com no muestra sus videos
mediante streaming tradicional ni tampoco HTTP Dynamic Streaming. Youtube.com
lleva a cabo pesudo-streaming para la entrega y reproduccin de sus videos. No tiene
en cuenta el ancho de banda del cliente y tampoco enva los videos al bit rate que son
codificados, usa en todos los casos la mxima velocidad de descarga. Los videos
quedan alojados en la cache del browser y todo su mecanismo de streaming se pasa en
HTTP, incluso las acciones de play y adelantar. En todos los casos hace uso de TCP.
4.2 Netflix
5. Conclusin
A lo largo de este trabajo, se pudo darle un marco de referencia a lo que se
entiende cuando hablamos de streaming. Evidenciando un streaming tradicional,
basado en protocolos tradicionales diseados para la transferencia de datos sujetos a
limitaciones de tiempo real y un streaming alternativo que sobre el protocolo HTTP
pretende dar una solucin similar.
De esta forma el streaming tradicional se caracteriz en poder enviar video y
que este llegue al usuario sin pausas, que este pudiera controlar su recepcin as como
tambin, poder recibir video en tiempo real con la mejor calidad de acuerdo a su
ancho de banda y poder ir notificando la calidad del servicio que estaba recibiendo.
6. Bibliografa
[1] "Utilizacin de video Streaming." J. Aramberri y J. Lasa. N.p., n.d. Web. 07 Aug.
2012.<http://www.rediris.es/difusion/publicaciones/boletin/58-59/ponencia10.html />.
Sitio
[2] "RTSP: FAQ." Computer Science - Columbia University. N.p., n.d. Web. 07 Aug.
2012. < http://www.cs.columbia.edu/~hgs/rtsp/faq.html >.Sitio
[3] Streaming de Audio y Vdeo Grupo de Redes de Computadoras Universidad
Pontificia de Valencia. N.p., n.d. Web. 07 Aug. 2012.
<http://www.grc.upv.es/docencia/tdm/practicas/P3.pdf >. Prctica
[4] "RTSP" Computer Science - Columbia University. H. Schulzrinne, A. Rao, R.
Lanphier. N.p, 2 Feb. 1998. Web. 07 Aug. 2012.
<http://www.cs.columbia.edu/~hgs/rtsp/draft/draft-ietf-mmusic-rtsp-09.pdf >. Paper
[5] " RTP: A Transport Protocol for Real-Time Applications" The Internet
Engineering Task Force (IETF). H. Schulzrinne,S. Casner, R. Frederick,V. Jacobson,
Jul 2003. Web. 07 Aug. 2012. < http://www.ietf.org/rfc/rfc3550.txt >. Paper
[6] "Video Delivery in HTTP." Roman10. N.p., n.d. Web. 07 Aug. 2012.
<http://www.roman10.net/video-delivery-in-http/ />. Sitio
[7] "Redes de Computadoras e Internet". Fred Halsall, Editorial Pearson
[8] "Streaming Media Bible". Steve Mack, Editorial Hungry Minds.
[9] "RTCP, RTP Control Protocol." Network Sorcery, Inc. N.p., n.d. Web. 07 Aug.
2012. < http://www.networksorcery.com/enp/protocol/rtcp.htm >.Sitio
[10] "6.1 RTCP Packet Format." Freesoft.org. N.p., n.d. Web. 10 Aug. 2012.
<http://freesoft.org/CIE/RFC/1889/14.htm >.Sitio
[11] " An Experimental Evaluation of Rate-Adaptation Algorithms in Adaptive
Streaming over HTTP". Saamer Akhshabi, Ali C. Begen, Constantine Dovrolis, Feb
2011. Web. 07 Aug. 2012. <http://www.cc.gatech.edu/~dovrolis/Papers/final-saamer-
mmsys11.pdf>. Paper
[12]Live_and_On_Demand_Video_with_Silverlight_and
IIS_Smooth_Streaming_FINAL Microsoft N.p., n.d. Web. 10 Aug. 2012.
<http://download.microsoft.com/download/3/A/4/3A4A066C-6543-4BC1-
A8B_and_On_Demand_Video_with_Silverlight_and%20IIS_Smooth_Streaming_
FINAL.pdf />.Sitio
[13] "Analysis of Netflixs security framework for Watch Instantly service " Pomelo,
LLC TechMemo. N.p, Mar 2009. Web. 07 Aug. 2012.
<http://pomelollc.files.wordpress.com/2009/04/pomelo-tech-report-netflix.pdf>.
Paper.