2. ABSTRACT
•In today’s world streaming media plays a vital role, with the advanced
technologies recently developed in the areas of high-speed networks and
multimedia, video-on- demand service (VOD) is considered as the emerging
trend in home entertainment, as well as in education, banking, home
shopping, and interactive games. Better quality video, as well as efficient way
to send and receive them is necessary. Streaming media is multimedia that is
constantly received by and presented to an end-user while being delivered by
a streaming provider. With streaming, the client browser or plug-in can start
displaying the data before the entire file has been transmitted. Quality of
video, streaming time of video and the streaming protocols that we use for
make a lot of difference. Hence we present two different types of streaming
media protocols, HTTP Live Streaming (HLS) and Real Time Streaming Protocol
(RTSP) and their comparison, a DoS resilient self healing video architecture to
provide a better quality video and a survey on different VoD Batching
techniques.
.
Ahlam Ansari 2
3. INTRODUCTION
•HTTP Live Streaming (HLS) is an HTTP-based media streaming communications
protocol implemented by Apple Inc.
It works by breaking the overall stream into a sequence of small HTTP-based file
downloads, each download loading one short chunk of an overall potentially
unbounded transport stream.
Ahlam Ansari 3
4. The Real Time Streaming Protocol (RTSP) is a network control protocol designed
for use in entertainment and communications systems to control streaming media
servers.
RTSP was developed by the Multiparty Multimedia Session Control Working
Group (MMUSIC WG) of the Internet Engineering Task Force (IETF)
Ahlam Ansari 4
5. Video request is delayed for a period of time so that more requests for the same
video are collected. The batch of requests is then served by a multicast video
stream.
The major drawback of this scheme is that the customers have to wait for a
batching interval until the video is started to play. Hence, it may increase the
customer dissatisfaction if the waiting interval is too long.
Ahlam Ansari 5
8. 1. Media Encoder:
The Encoder encodes the video/audio. Videos are compressed into H.264/MPEG-4
format and the audio is encoded using advance audio coding. The video or audio
format is encapsulated in MPEG 2.
Transport Stream is specified in MPEG-2 Part 1, Systems (formally known as
ISO/IEC standard 13818-1 or ITU-T Rec. H.222.0) [3][4][5]. Transport stream
specifies a container format encapsulating packetized elementary streams, with
error correction and stream synchronization features for maintaining transmission
integrity when the signal is degraded.
Program stream is a container format for storage applications specified in MPEG-1
Systems and MPEG-2 Part 1. A program stream contains only one content channel
and is suited to authoring and storage not broadcasting. Contrast with transport
stream, which is designed to address the delivery of the content.
Ahlam Ansari 8
9. 2. Stream Segmenter
The Segmenter segments the video/audio in small duration segmentation. All the
segments are placed in separate files. For protection purpose, the Segmenter
might encrypt the segments and create a key file.
Ahlam Ansari 9
10. 3. Distribution System
Distributed System is a regular HTTP Server. It could be Apache or any embedded
server. Segments are stored with .ts extension and the index files are stored
with .m3u8 extension. The file format of index is as follows:
Ahlam Ansari 10
11. 4. Client:
The client gets all the videos or audios through a HTTP connection. HTTP creates a session
between the client and the file at the DS. The session can be either a Live Stream Broadcast
session or a Video on Demand Session.
A) Live Stream Broadcast Session
LSD contains an index file that is dynamic in type and is continuously
updated and refreshed. It includes a moving window of segments.
B) Video on Demand Session
VoD contains an index file that is static in type and it contains all the
segments of the file. [2]
Ahlam Ansari 11
12. Deploying HTTP Live Streaming
Step 1: Creating a HTML Page
Step 2: Configuring a Web Server
Step 3: Validating the Streams
Step 4: downloade video / audio at client side
Ahlam Ansari 12
13. Step 1: Creating a HTML Page
The easiest way to distribute HTTP Live Streaming media is to create a webpage that
includes the HTML5 <video> tag, using an .M3U8 playlist file as the video source. An
example is shown below:
<html>
<head>
<title>HTTP Live Streaming Example</title>
</head>
<body>
<video
src="http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8"
height="300" width="400" >
</video>
</body>
</html>
Ahlam Ansari 13
14. Step 2: Configuring a Web Server
•HTTP Live Streaming can be served from an ordinary web server; no special
configuration is necessary, apart from associating the MIME types of the files
being served with their file extensions.
Configure the following MIME types for HTTP Live Streaming:
File Extension MIME Type
.M3U8 application/x-mpegURL or vnd.apple.mpegURL
.ts video/MP2T
Ahlam Ansari 14
15. Step 3: Validating the Streams
•The media stream validator tool is a command-line utility for validating HTTP Live
Streaming streams and servers . The media stream validator simulates an HTTP
Live Streaming session and verifies that the index file and media segments
conform to the HTTP Live Streaming specification. It performs several checks to
ensure reliable streaming. If any errors or problems are found, a detailed
diagnostic report is displayed.
You should always run the validator prior to serving a new stream or alternate
stream set. The media stream validator shows a listing of the streams you provide,
followed by the timing results for each of those streams. (It may take a few
minutes to calculate the actual timing.) An example of validator output follows.
Ahlam Ansari 15
16. •Validating
http://devimages.apple.com/iphone/samples/bipbop/gear3/prog_index.m3u8
against iPhone OS 3.1.0
Average segment duration: 8.77 seconds
Average segment bitrate: 510.05 kbit/s
Average segment structural overhead: 96.37 kbit/s (18.89 %)
Video codec: avc1
Video resolution: 480x360 pixels
Video frame rate: 29.97 fps
Average video bitrate: 407.76 kbit/s
H.264 profile: Baseline
H.264 level: 2.1
Audio codec: aac
Audio sample rate: 22050 Hz
Average audio bitrate: 5.93 kbit/s Ahlam Ansari 16
17. Step 4: Download video/audio at client side
How actually the video / audio is downloaded at client side [8]
1. Download the wowza URL (playlist)
2. Display the contents of the file
3. Download the first/second playlist url
4. Display the contents
5. wget the key URL
6. wget the ts file sequence
If the file is encrypted
7. Hexdump the key
8. Using calc get the HEXADECIMAL Value of "MEDIA-SEQUENCE", to get IV -> 95 =
5F using openssl decrypt the file
9. Now play the file "decr_tmp.ts" using "VLC media player"
Ahlam Ansari 17
18. RTSP vs. HTTP
Interoperability
RTSP is an interoperability disaster. None of the three big commercial
implementations seem to abide by the standard (Microsoft Windows Media,
Apple/Darwin and RealMedia), and writing a client stack that can handle all of
them, plus the open-source servers properly, is tough to say the least.
HLS is widely interoperable. It has countless implementations both on the server
and client sides. It has Apache as a de facto reference implementation that every
client can interoperate with.
Ahlam Ansari 18
19. •Transport Layer Protocol
RTSP uses UDP
HTTP uses TCP
•Seeking
RTSP, the server takes care of it
With HLS, client will probably be the one
Ahlam Ansari 19
20. • Play and Pause
RTSP does have built-in PLAY and PAUSE commands, which namely respectively
play and pause the media.
There are several ways you can pause a stream with HTTP:
. Stop de-queuing data from the TCP session, and let the TCP stacks handle pause
with TCP congestion control, until you want to resume,
. Shutdown/reset the TCP session to pause, and start a new one to resume
Ahlam Ansari 20
21. •Congestion
In case of network congestion or packet loss, RTSP will cause part of the stream to be lost.
In case of network congestion or packet loss, HLS will never cause part of the stream to be
lost.
•You Tube
RTSP is used in YouTube Mobile.
HLS is used on You Tube main site.
Ahlam Ansari 21
22. •Reliability
RTSP only carries the signaling reliably.
HTTP conveys both signaling and payload reliably.
•NAT Traversal
RTSP just does not work, without ugly TCP encapsulation that makes it look like HTTP.
HLS just works through Network address translation
Ahlam Ansari 22
23. •Firewall traversal
Not so many firewalls handle or allow RTSP. RTSP has theoretical firewall traversal
capability.
HLS goes through almost any firewall. Even from tightly restricted Intranets, you
can always find an outgoing HTTP proxy to use.
Ahlam Ansari 23
26. •I n the basic architecture of a VoD system consists of:
Video Encoder
Video Server
Directory Server
Client
Network
The Network connects all the other VoD system components together as they are
distributed geographically. The encoder accepts the video input and then uploads it on the
video server after compressing/encoding the video stream received. The video server is a
server with huge amount of disk space to accommodate day by day increasing videos in
segments, not as a single file. The directory server keeps the index file which points to all
the segments of those videos in video server, and these videos are published to the client so
that they can access it. The figure below shows the architecture of basic VoD system.
Ahlam Ansari 26
27. Types of Streaming
1. Realtime
The data have a pre-determined sequence and time of presentation.
For example, video and audio.
2. Non-Realtime
The data does not have presentation time requirement.
For example, progressive JPEG.
Ahlam Ansari 27
28. Types of Video Services
1. Broadcast / Multicast Video
2. Near-Video-on-Demand
3. True Video-on-Demand
Ahlam Ansari 28
30. •The multicast facility of modern communication networks [12] offers an efficient
means of one-to-many data transmission. The basic idea is to avoid retransmitting
the same packet more than once on each link of the network by having branch
routers duplicate and then send the packet over multiple downstream branches.
Multicast can significantly improve the VoD performance.
Passive receive with no control except selecting the channels. One channel is
needed per movie / programme.
Ahlam Ansari 30
32. •Near video on demand is a video delivery service that allows a customer to select
from a limited number of broadcast video channels when they are broadcast.
NVOD channels have pre-designated schedule times and are used for pay-per-view
services. Passive receive with limited controls. System response time inversely
proportional to number of required channels [12].
Ahlam Ansari 32
34. •True Video-on-Demand system uses one dedicated channel for each service
request, offering the client the best TVoD service. However, such a system incurs
very high costs, especially in terms of storage-I/O and network bandwidths. Full
interactive controls, like pause/resume, seeking, fast forward, etc .
Ahlam Ansari 34
35. Comparisons
Broadcast Video True Video-on-
Near-Video-on-Demand Demand
(Pay-Per-View)
Yes, but limited to a Yes, but limited to a few
Select video? Yes
few channels programmes
Select time to
No Yes (limited to fixed time slots) Anytime
watch?
Interactive? No None or very little VCR-like control
No. of Viewers Unlimited Unlimited Limited
Cost / Viewer Low Medium High
Ahlam Ansari 35
36. LITERATURE SURVERY
Some authors have worked on reducing the start-up delay in
multicast delivery systems as the major problem with the batching
approach is that it introduces a significant start-up delay to the
customer, which in fact contradicts the idea of on-demand service.
Ahlam Ansari 36
37. Batching policy for video-on-demand in multicast environment
W.-F. Poon, K.-T. Lo and J. Feng Says:
•Piggybacking approach
It merges different requests together by adjusting the play-out rate of the videos
so as to reduce the start-up delay of the system. The greedy policy attempts to
merge the requests as many times as possible during the entire video session in
order to save more bandwidth.
If the play-out rate is adjusted in real time, a specialized hardware is required to
keep up with the demand. If a replica of the video is generated in advance, since it
is possible that requests can be merged during the entire video session, very large
disk storage is required at the server side.
Ahlam Ansari 37
38. •Double-rate (DR) batching policy
Considering the waiting time (conventional batching approach) of the customers
and the complexity (piggybacking approach) of the VoD system, we develop a
double-rate (DR) batching scheme that attempts to merge the customer requests
in an improvised manner by means of buffering. Instead of changing the play-out
rate of the video, we double the transmission rate so that the trailing customers
are able to catch up with the leading customer. Once the transmitting frames of
the customers are the same, they are grouped together and served by a multicast
stream.
A new batching scheme has been proposed to reduce the start-up delay of VoD
services in a multicast delivery system. When a new customer arrives, a unicast
stream is immediately opened for the new request so that the customer does not
have to wait. The transmission rate is then doubled so that the customer can catch
up with the previous multicast stream.
Ahlam Ansari 38
39. Advantage:
A new batching scheme has been proposed to reduce the start-up delay of VoD
services in a multicast delivery system. When a new customer arrives, a unicast
stream is immediately
opened for the new request so that the customer does not have to wait. The
transmission rate is then doubled so that the customer can catch up with the
previous multicast stream.
Drawback:
It is shown that the DR batching scheme outperforms the greedy policy of the
piggybacking approach only in terms of the bandwidth requirement. As it has fixed
batching time, popularity of the movies affects the performance of the VoD
system.
Ahlam Ansari 39
40. Adaptive Batching Scheme for Multicast Video-On-Demand Systems
W.-F. Poon, K.-T. Lo, Member, IEEE, and J. Feng, Member, IEEE says:
•An adaptive algorithm is developed for providing true video on demand (VoD)
services in multicast environment. If the batching time is wrongly estimated, the
performance of the system will be greatly degraded. This algorithm tries to
dynamically find the optimal batching time by the newly updated arrival rate so as
to minimize the bandwidth requirement.
Adaptive algorithm enhances the double-rate batching policy so that the
popularity of the movies will not affect the performance of the VoD system as the
batching time can be adjusted.
Ahlam Ansari 40
41. •Advantage:
Adaptive algorithm enhances the double-rate batching policy so that the
popularity of the movies will not affect the performance of the VoD system as the
batching time can be adjusted.
Drawback:
If the batching time is wrongly estimated, the performance of the system will be
greatly degraded.
Ahlam Ansari 41
42. Virtual Batching: A New Scheduling Technique for Video-On-Demand Servers
Simon Sheu and Kien A. Hua and Ta-Hsiung Hu says:
•In a video-on-demand (VOD) environment, batching of requests is often applied
to reduce the I/O demand and increase the availability of VOD services. However,
batching unfairly forces first comers to wait for subscribers arriving late at the
batch. Some of these victims may become impatient and decide to renege. To
address this issue, we introduce a chaining technique which allows a client station
being served to forward its video data to other client stations, which requested
the same video, at a slightly later time.
Thus, chaining enjoys the benefit of batching without its side effect of causing long
access latencies. By combining batching and chaining, we also design a scheme
called Virtual Batching.
This property reduces the service latencies and therefore improves the reneging
probability. This characteristic addresses the network-I/O bottleneck problem
facing today’s media servers.
Ahlam Ansari 42
43. •Advantage:
First comers no longer have to wait for requests arriving late at the batch. This
property reduces the service latencies and therefore improves the reneging
probability. This characteristic addresses the network-I/O bottleneck problem
facing today’s media servers.
Drawback:
This policy makes use of Batching as well as Chaining hence it is more complex.
The clients should also have chaining and forwarding mechanism in order to
implement Virtual Batching policy.
Ahlam Ansari 43
46. •The self-healing architecture comprises of four main components: performance
analyzer, repair planner, sensors and effectors. The performance analyzer takes:
(1) server performance parameters collected by sensors to detect performance
degradation; and (2) service parameters collected from synthetic sessions
established with the server. It detects performance degradation and pinpoints the
resources responsible for these anomalous states. The repair planner takes
notifications issued by the performance analyzer, decides the best repair action to
be executed (e.g., session migration and protocol-level redirection of sessions) and
plans the repair to be executed by effectors.
Ahlam Ansari 46
47. •Sensors are responsible for collecting performance parameters. Two types of
sensors are devised server-side: (1) pace sensors; and (2) resource sensors. Pace
sensors capture delays on accomplishment of scheduling of video content. The
unit of scheduled work depends on server implementations and streaming
protocols. In RTSP streaming the packet is the unit of work to be scheduled and
transmitted. Other video standards require coarse-grain performance metrics at
server: HTTP Streaming and HTTP Adaptive streaming. They fragment video
objects into slices that are selectively requested by clients and downloaded
similarly to other web objects.
Ahlam Ansari 47
48. Conclusion
•YouTube uses HTTP/TCP to buffer video into the flash player on its main site. The
video is stored on Google Video's content distribution network. It's not streamed
as much as just sent as fast as possible to your computer. However, for 3g mobile
handsets, m.youtube.com uses RTSP to stream video. So, YouTube uses both
transfer methods [10]. Another thing to consider is that YouTube is popular
because "it just works". RTSP isn't always supported well through routers, which
would prevent that for use on the desktop. Also, m.youtube.com doesn't stream
the same video file as youtube.com. Most YouTube videos are not streamed, but
progressively download over HTTP. A small number of partner videos are securely
streamed, using RTMPE.
Ahlam Ansari 48
49. •DR batching scheme reduce the start-up delay of VoD services in a multicast delivery
system. When a new customer arrives, a unicast stream is immediately opened for the new
request so that the customer does not have to wait. The transmission rate is then doubled
so that the customer can catch up with the previous multicast stream.
Adaptive batching scheme enhances the double-rate batching policy so that the popularity
of the movies will not affect the performance of the VoD system as the batching time can
be adjusted.
Virtual Batching scheme generalize the conventional batching methods to allow requests
arriving at a virtual batch to receive immediate services. First comers no longer have to wait
for requests arriving late at the batch. This property reduces the service latencies and
therefore improves the reneging probability. This characteristic addresses the network-I/O
bottleneck problem facing today’s media servers.
Ahlam Ansari 49