[en] The recent advances and development of inexpensive computers and high speed networking technology have enabled the Video on Demand (VoD) application to connect to shared-computing servers, replacing the traditional computing environments where each application was having its own dedicated special purpose computing hardware. The VoD application enables the viewer to select, from a list of video files, his favourite video file and watch its reproduction at will. However, the VoD application is known as one of the applications that must provide long-lived video streams which consume high resources such as I/O and network bandwidth to a large number of clients. Therefore, a video server must secure the necessary resources for each stream during a long period of time (e.g. 7200 seconds) so that the clients can reproduce (play) the video data without witnessing jitter or starvation in their buffers. This thesis presents the design and implementation for a video proxy server (VPS) which can provide interactive video on demand. The VPS consists of three main parts. The first part is the Admission Control Module which receives the clients' requests, negotiates the required resources, and decides whether to accept or reject a client based on the available resources. The second part is the Resources Management Module which manages several shared resources such as the CPU, the Memory, the Network and the Disk It consists of four brokers that can reserve the necessary resources based on a predefined policy. The third part is the CB_MDA algorithm which is responsible for regulating the resources assignment and scheduling the video streams. The CB_MDA uses a combination of multicast and unicast channels for transmitting the video data. The multicast streams are initiated to start a video file from the beginning while the unicast channels are used to join the later arrivals to the appropriate multicast stream. In the implementation, the CB_MDA discovers the period of time when the server has plenty of resources an assigns them to appropriate clients in order to create work-ahead video data. The thesis further goes beyond the design of the VPS and presents a video client architecture that can synchronize with the server and work as a plug-in for producing the video data on different players such as MPEG-Berkely player, Xine.etc.

[es] El desarrollo y las avances recientes de la tecnología de los ordenadores y de la tecnología de alta velocidad de redes han hecho posible que las aplicaciones de video bajo demanda estén conectadas a "shared-computing" servidores reemplazando los sistemas tradicionales donde cada aplicación tenía su propia máquina dedicada para servirla. La aplicación de video bajo demanda permite a los usuarios seleccionar de una lista de videos su película favorita y ver su reproducción a su gusto. Sin embargo, la aplicación de video bajo demanda se considera como una de las aplicaciones que debería soportar largos "video streams", que consumen muchos recursos como el anch de banda de red y I/O, a gran número de clientes. Por eso, el servidor de video debería asegurar los recursos necesarios para cada "stream" durante un periodo de tiempo largo (e.g. 7200 segundos) para que los clientes reproduzcan el video sin "jitter" y "starvation" en sus búferes. Esta tesis presenta el diseño y la implementación de un Servidor Proxy de Video (VPS) que puede proveer video bajo demanda interactiva. El VPS consiste de tres componentes (partes) principales. La primera parte es el Modulo de Control de Admisión (ACM) que recibe las peticiones de los clientes, negocia los recursos requeridos, y decide si la petición puede ser aceptada o rechazada basado en la disponibilidad de los recursos. La segunda parte es el Modulo de Manejo de los Recursos (RMM) que maneja los recursos del sistema como el CPU, la Memoria, la Red, y el Disco. Este consta de cuatro "brokers" que reservan a los recursos necesarios basado en una política predefinida. La tercera parte es el algoritmo CB_MDA "Credit_Based Media Delivery Algorithm" que controla y regula el flujo de los "streams" del video. La CB_MDA utiliza una combinación de canales unicast y "multicast" para transmitir el video. Los "streams" de "multicast" se inician para empezar a emitir el video desde el principio, mientras los canales unicast se usan para juntar los llegados tardes a un "stream multicast" apropiado. En la implementación, el CB_MDA detecta los momentos cuando el servidor tiene disponibilidad de recursos y les asigna a los usuarios apropiados para crear un trabajo en adelanto.