Application of Live Video Streaming over GRID and Cloud infrastructures

2012.05.11

Speaker : 吳靖緯 MA0G0101

2011 IEEE 11th International Conference onComputer and Information Technology (CIT),

On page(s): 379 - 384, Sep 2011

Authors:Dimitris Karakasilis, Fotis Georgatos,Theodoros Alexopoulos, Lambros Lambrinos

Outline

• Introduction

• Background

• Implementation-Deployment

• The GRID

• The cloud

• Limitations

• Conclusion

2

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