Application of Live Video Streaming over
GRID and Cloud infrastructures
Authors:
Dimitris Karakasilis, Fotis Georgatos,
Theodoros Alexopoulos, Lambros Lambrinos
Speaker :吳靖緯 MA0G0101
2011 IEEE 11th International Conference on
Computer and Information Technology (CIT),
On page(s): 379 - 384, Sep 2011
2012.05.11
Outline
• Introduction
• Background
• Implementation-Deployment
• The GRID
• The cloud
• Limitations
2
• Conclusion
Introduction
• We used a previously proposed architecture, to implement a
solution that will use the GRID or a Cloud infrastructure to
stream video.
• The goal was to create an application that will allocate
resources dynamically and escalate in a manner corresponding
to the demand.
• Video amongst all, is the most demanding in the matter of
bandwidth and CPU resources.
• Multicasting and P2P are two popular approaches.
3
Introduction
• Multicasting is still highly unsupported on many networks and
P2P can’t provide full control over the quality of the delivered
video.
• Given the above, the case for streaming video using the Grid of
Cloud Infrastructure has been proposed in the past as an
alternative solution.
• Our main purpose, has been to demonstrate that such a concept
is realistic.
4
Background
• Streaming of audio-video data has been on the research agenda
for many years.
• The general idea is to serve clients from multiple locations;
some architectures even follow the peer-to-peer paradigm and
clients may serve other clients.
• From our point of view, the fact that resources are predefined
is an important drawback.
5
Background
• The Grid and the Cloud are large computing infrastructures
combining storage, networking and processing.
• This particular characteristic makes them highly suitable for
our application as they can serve as the underlying data
distribution network.
• In later sections, after we describe our particular application,
we will explain in more detail the advantages offered by the
use of the Grid and the Cloud in our work.
6
Implementation-Deployment
• We will look into the architecture(See Figure 1).
7
Implementation-Deployment
• Anywhere data is sent or received, the UDP protocol is used.
• We considered this to be a better choice after trying TCP.
• UDP is faster and more suitable when it comes to video
streaming, but is also connectionless which makes the process
of deployment easier.
8
Implementation-Deployment
A. The Source
• We wanted to be free to choose, from a list of possible video
sources.
• VLC is only used as a case study to take whatever was chosen
as a Source and create a UDP stream.
• In case the video Source creates its own stream, VLC can be
used to transcode the stream to the desired format if needed.
9
Implementation-Deployment
B. Distributor
• The video created by VLC is further sent to a computer which
we call “Distributor”.
• This computer will distribute the video, to all GRID computers
we use to serve the users (we will call them “Reflectors”).
• Distributor runs a Python script which is responsible for both,
sending the data to the Reflectors and adding new Reflectors to
an SQLite3 database.
10
Implementation-Deployment
• Three threads were used to achieve this.
• One thread, listens for reports from the Reflectors and
updates the database with the time of the last report.
We use this value to decide, whether a Reflector is alive or
not.
• Another thread runs with an interval and populates the list
with the alive Reflectors.
These are the addresses that will receive the video.
11
Implementation-Deployment
• The last thread, receives the video on one port and uses the
previous list to send the video to all alive Reflectors.
One important thing to point out here is that we didn’t use a
buffer.
• The serving a page decides which Reflector is the best at the
time and updates the database with the new viewer and the
assigned Reflector.
• The balancing function used was, choosing the alive Reflector
with the least assigned viewers.
12
Implementation-Deployment
• Ajax methods were used, to update the database with the
viewer “report” time.
• Viewers, much like Reflectors, are decided alive or dead based
on the last report time.
• Another page the Distributor serves, is one that holds
information about the viewers assigned to every Reflector.
• Reflectors will use this page to learn where to send the video.
13
Implementation-Deployment
C. Reflectors
• Every Reflector is a Worker Node which runs a job.
• The job the Reflectors run, is a Python script which uses
threads to do the following :
• One thread masquerades itself as a browser. Using that info,
it builds a list with destination addresses.
• Another thread receives the video on a port and sends it to
the destinations.
14
Implementation-Deployment
• The Reflector sends reports to the Distributor, using another
thread.
With these reports, the Distributor can decide which
Reflectors are alive.
• Finally a control thread just listens for any data on a specific
port.
15
Implementation-Deployment
D. Users
• Users will need to open the web page served by Distributor
and enjoy watching the video.
• NAT traversal techniques, require the user to send data from
the port on which he expects the data to arrive, to the computer
that will send the data.
• This mechanism is examined on a later section with the related
title.
16
Implementation-Deployment
E. UI – Administrator
• Job submission is usually done, through a UI on which the
GRID user has an account.
• We created our own graphical tool for this implementation,
using Python and GTK library (Figure 2).
17
The GRID
• Special characteristics of GRID, that make it a good candidate
for the job are :
• Middleware layer is responsible for resource allocation.
• GRID has its own mechanisms which guarantee, that resources
are not being wasted.
• Stopped jobs, automatically release their resources.
18
The GRID
• GRID is a distributed network resource (Figure 3).
19
The cloud
• Unlike GRID, Cloud doesn’t offer a middleware layer.
• Resources are predefined, as opposed to the dynamic resource
allocation of GRID.
• Cloud resources can be used to transmit live video.
• A blade server was used as a Reflector (Figure 4).
20
Limitations
A. Security
• In the matter of security no action was taken.
• Neither Distributor, nor the Reflectors check strictly who
delivers them the video.
21
Limitations
B. Streaming Protocol
• We used UDP streaming, although VLC offers a lot of choices.
• We deliberately chose the most generic protocol.
• Using a more complex protocol would mean, setting up the
architecture in a way that may be hard to change later.
22
Limitations
C. NAT traversal
• Our setup is not a standard case, so VLC doesn’t implement
this initialization package.
• We need to either modify VLC code or create a wrapper script
that will initialize the “connection” and then fire up VLC.
23
Limitations
D. Buffering
• To achieve a low latency transmission, we didn’t use a buffer.
• We used the following serial method to retransmit the data to
all destination addresses:
• Receive package
• Send the package to the first address
• Send the package to the second address
• So on, so forth, for more addresses
24
Conclusion
• This paper was tested and achieved in transmitting live video,
from VLC supported input.
• All choices were made, so as to have an open architecture and
allow further evolvement of the application.
• Our main goal for the future is to address the known
limitations and make the application more safe.
25