Sandep Project Report Final

URLBuilder for Smooth Streaming 2010-11
CHAPTER 1
Introduction
1.1 Introduction to Smooth Streaming
Smooth Streaming is a relatively new way to stream videos at an adaptive rate giving viewers
the best possible viewing experience. Smooth streaming can determine the available
bandwidth and select the appropriate bit-rate to display video.
Smooth Streaming delivers small fragments of a video at a time and verifies that each has
arrived at the destination within the appropriate time and played back at the expected quality.
If a fragment of video is not up to the expected quality then the next one will be delivered at
a slightly lower bit-rate. This process uses HTTP protocol.
Smooth Streaming dynamically detects local bandwidth and CPU conditions and switches in
real time the quality of the media file that the player receives. It is a combination of
progressive HTTP download with bandwidth conscious media delivery.
1.1.1 Where Does an URLBuilder come in Smooth Streaming?
The Smooth Streaming technology works on the principle of client-server architecture and is
formed by two different parts:
• The server, which provides the service,
• The client, which requests for service.
The purpose and requirement of an URLBuilder comes at the client side of the Smooth
Streaming technology. In Smooth Streaming technology the requested file is not delivered to
the client as one large block but instead it is divided in the form of small chunks each with a
minimum duration of 2 to 3 seconds and can be up to 10 second maximum duration
depending on the architecture. There will be different copies of the same file each with equal
number of chunks which all together make up one whole file that was requested with
different bitrates. Different bitrates represent various copies of the requested file one of them
being the best quality other copy of medium quality and least quality file.
Dept of PG Studies in CE&A, NIE, Mysore. 1

In order to download a file we need to download all the chunks corresponding to that file
sequentially and separately. These chunks are identified by the client Manifest file, which has
information of that particular file to be downloaded. The information carried by the Manifest
file is
• Chunk Number
• Bitrate
• Chunk start time
• Duration of that chunk
• Type of encoding used
Suppose we have a smooth streaming media file with 3 different qualities and each quality
having 10 chunks representing one complete media file then we will have 10 different URL’s
representing 10 chunks for a particular media quality file.
An URLBuilder is used to generate URL for each chunk for all quality files available for the
requested file by the customer. The information that the URLBuilder uses to generate URL
for a particular chunk is obtained form the client Manifest file which hold complete
information about the requested file. This is the first piece of information that the client
receives from the server when it request for a file.
Hence URLBuilder becomes an important aspect of Smooth Streaming client without which
URL for each chunk cannot be generated and a file can never be downloaded using Smooth
Streaming technology.
1.2 Problem Statement

In this project, Smooth Streaming is selected as the technology and URLBuilder
will be developed as per the requirement of the organization.
The problem domain of the project comprises the development of URLBuilder for Smooth
Streaming client on STB.

1.3 Objective of the Project

To develop an URLBuilder for Smooth Streaming client, a part of smooth
streaming support in Alcatel-Lucent IPTV STB. The URLBuilder has to be
developed in such a way that it can build a URL for the chunks to be
downloaded.
1.4 Brief Outline of the Project

Outline of the project is to develop an URLBuilder module for Smooth Streaming client. The
developed module will be integrated into the existing set-top-box and executed.
1.5 Thesis Organization

The Rest of the dissertation proceeds as follows. Chapter 2 focuses on the literature survey of
the project. The requirement analysis for developing the URLBuilder for Smooth Streaming
is discussed in chapter 3. The working of Smooth Streaming, its features are analyzed in the
Chapter 4. The design of URLBuilder for Smooth Streaming is discussed in chapter 5.
Chapter 6 explains the implementation of the designed URLBuilder. This dissertation
concludes with chapter 7 followed by bibliography.

Chapter 2
Requirement Analysis
The requirement analysis for the development of URLBuilder for Smooth Streaming consists
of:
 User requirements
 Functional requirements
 Software requirements
 Hardware requirements
User Requirements
• User needs to download a file depending on the available bitrates which would
suite customer bandwidth availability. A particular file has different copies based
on different quality. Depending on the customer bandwidth a particular quality
(high quality, average quality or least available quality) file must be downloaded.
• Proper URL must be generated corresponding to the bitrates that the available
bandwidth of the customer would easily support. Since the file has different copies
representing different quality the customer must be able to download a copy of the file
irrespective of the quality that suites his bandwidth criteria.
• Generated URL must be stored in a sequential manner corresponding to bitrates and
chunk numbers. As each copy of the file is divided into chunks URL must be generated to
represent each chunk for a particular quality that suites customer bandwidth and each chunk
must be downloaded as per its chunk number to avoid loss of chunk.
• The process of downloading and generation of URL must be quick to avoid
latency in further stages. As each chunk vary from 2 to 10 second depending on
architecture, number of chunks depend on duration of the file. Hence URL for
each chunk must be generated at quick pace to allow continuous download in
order to avoid/ minimize buffer time.

2.2 Functional Requirements

• The client Manifest file downloaded must be that which was requested by the
client. The system must be able to process and extract the exact information
from the server response out of available responses.
• System must be able to process and parse the obtained Manifest file. System
must be able to generate a tree structure representing the client manifest file
downloaded.
• The built URL must be used by other modules in Smooth Streaming client
architecture. The URL representing each chunk generated by URLBuilder
must be useful for other modules i.e. URL must be generated as and when
required
• URL must be in a format which other modules can easily process. The
modules that URL as input must be in a position to understand the generated
URL.
• URL generated must be in proper order corresponding to proper chunk
numbers. As each URL represent different chunk, the generated URL must be
in sequential order corresponding chunk number to eliminate the chunk loss
during further possessing.
Software Requirements
2.3.1 Languages
• C++
2.3.2 Platform
• Linux
2.3.3 Tools
• Cross compiler.
Hardware Requirements
• STB

Chapter 3
System Analysis
3.1 INTRODUCTION
Smooth Streaming dynamically detects local bandwidth and CPU conditions and seamlessly
switches, in near real time, the video quality of a media file that a player receives. Consumers
with high-bandwidth connections can experience high definition (HD) quality streaming
while others with lower bandwidth speeds receive the appropriate stream for their
connectivity, allowing consumers across the board to enjoy a compelling, uninterrupted
streaming experience and alleviating the need for media companies to cater to the lowest
common denominator quality level within their audience base.
This enables companies to boost brand awareness and advertising revenues by extending
average viewing times through higher quality true HD (resolution greater than 720p)
experiences. They can also benefit from unprecedented network scalability using distributed
HTTP-based Web servers and offer better quality to more customers.
When a client requests a specific source time segment from the server, the server
dynamically finds the appropriate Fragment box within the contiguous file and sends it over
the wire as a standalone file, thus ensuring full cacheability downstream.
In other words, with Smooth Streaming, file chunks are created virtually upon client request,
but the actual video is stored on disk as a single full-length file per encoded bit rate. This
offers tremendous file-management benefits.
3.2 SMOOTH STREAMING

3.2.1 INTRODUCTION
Smooth Streaming is based on Base Media File Format specification, better known as the
MP4 file specification. There are several reasons to use this format:
• MP4 is a lightweight container format with less overhead.

• MP4 is easier to parse in managed code.

• MP4 is based on a widely used standard, making 3rd party adoption and support
more straightforward.
• MP4 is architected with H.264 video codec support .
• MP4 is designed to natively support payload fragmentation within the file.
There are actually two parts to the Smooth Streaming format:

• Wire format
• Disk file format.
3.3 MANIFEST FILES

The Smooth Streaming Wire/File Format specification defines the manifest XML language
as well as the MP4 box structure. Because the manifests are based on XML, they are highly
extensible. Among the features already included in the current Smooth Streaming format
specification is support for the following:
• VC-1, WMA, H.264 and AAC codec’s
• Text streams
• Multi-language audio tracks

• Alternate video and audio tracks (for example, multiple camera angles, director's
commentary, etc.)
• Multiple hardware profiles (for example, a bit rate targeted at different playback
devices)
• Script commands, markers/chapters, captions
• Client manifest Gzip compression
• URL obfuscation
• Live encoding and streaming

Chapter 4
System Design
This chapter presents an architectural design of the URLBuilder for Smooth Streaming and
explains the modules used in the development.
4.1 Smooth Streaming Client Architecture
9
8
1
2
Manifest
3 HTTP
Downloader
Downloader Queue
4
SERVER
MP4
MP4
fragmented
fragmented
Parser (audio)
Parser (video)
URLBuilder
Audio
.::::::::::::Sync:::::::::::::Video
Decoder Decoder
Manifest
Parser
CLIENT
Figure 4.1 Smooth Streaming Client Architecture

1: client requests for a file; 2: server responds by sending the URL of the Manifest file; 3: Manifest Downloader
requests for Manifest file; 4: server responds by sending the Manifest file; 5: the downloaded Manifest file is
wafer sent to Manifest Parser; 6: the Parsed file is sent to URLBuilder; 7: URL of the chunk is sent to HTTP
Downloader; 8: HTTP Downloader requests for the chunk; 9: server responds by sending the chunk
Figure depicts the general block diagram of Smooth Streaming client architecture. It works as
a client-server architecture.
In Smooth Streaming technology a single file has multiple copies based on quality i.e. one
copy for best quality video, one for average quality, one for least quality video and so on.
These multiple copies of a file are stored virtually and identified by a Manifest file. Each
copy is further divided into small fragments called chunk each with minimum of 2 second
duration and maximum of 10 second depending on the architecture.
Following are the steps followed in order to download a Smooth Streaming file:
 Client requests for a file from the server.
 Server checks for the file if it has it, sends a URL as response to the client. This
URL tells the client where it can find the Manifest file for the requested media file.
 Manifest downloader picks up this URL and sends a request to the server asking for
the required Manifest file.
 The server responds by sending the requested Manifest file to the Manifest
downloader.
 The Manifest file has all the information of the requested file such as
 Different qualities of the requested file available
 Available bitrates
 Total duration of the file
 Number of chunks making up the file
 Which encoder is used to encode the file
 Version of the xml file
 Duration of each chunk

 And room for some additional information.
 This file is taken up by the Manifest Parser, stores it in some location in the
memory and parses this file and creates a tree structure so that the information can
be accessed easily.
 Using the information available from the parsed file URLBuilder build a URL of
the first chunk and gives it to the HTTP downloader.
 The first chunk given to the HTTP downloader is always from the low quality file.
This is because the system has to analyze the network bandwidth, network status
and CPU conditions. Based on the analysis the system decides which quality file it
can go to download the next chunk.
 The HTTP downloader requests the server for the chunk whose URL is obtained
from URLBuilder.
 The server responds by sending the requested chunk to the HTTP downloader.
 By the time the chunk is downloaded the system uses the analyzed output to build
the URL for the next chunk and sends it to the HTTP downloader. In the mean time
the HTTP downloader checks the status of the queue. If the queue is empty the
downloaded chunk is placed as the first element in the queue if the queue is not
empty it appends the chunk to end of the queue.
 The queue holds the downloaded chunk according to the chunk number and its size
may vary depending on the architecture but has a minimum capacity of holding 5
chunks.
 Each chunk based on its number and the format (audio or video) is given to the
corresponding MP4 Fragment Parser (audio or video) and based on the timestamp
obtained from the parser from each chunk it is sent to corresponding decoder to
obtain synchronization.

4.2 Project Overview

In order to develop an URLBuilder for Smooth Streaming following modules are required
a) Module to download a file from the server (Manifest Download).
b) Module to parse the downloaded file (Manifest Parser).
c) Module to download URL from the parsed file (URLBuilder).
Figure shows the work flow of URLBuilder for Smooth Streaming.
Manifest Manifest
Download URLBuilder
Parser
Figure 4.2 Project overview
Smooth streaming uses XML based manifest files to describe media parameters. Two sets of
manifests are used, one for server ingest and the other for the client. The Smooth Streaming
Wire/File Format specification defines the MP4 box structure as well as the manifest XML
language. As the manifests are based on XML, they are highly extensible.
The manifest enables support for the following
 Text streams
 Multi-language audio tracks
 Alternate video and audio tracks (for example, multiple camera angles,
director's commentary, etc.)
 Multiple hardware profiles (for example, a bit rate targeted at different
playback devices)
 Script commands, markers/chapters, captions
 URL obfuscation
 Live encoding and streaming

Client manifest file

• (*.ismc)
• Describes the available streams to the client: the codec’s used, bit rates
encoded, video resolutions, markers, captions, etc.
Manifest tells the client which codec’s were used to compress the content, which bit rates and
resolutions are available, and a list of the available chunks and format of a client manifest file
is as shown below.
The manifest file consists of various tags the explanation to few of the tags are as given
below:
• The first tag of an Manifest file is always of the form

<? xml version="1.0" encoding="UTF-16"?>
Specifies the version of XML being used, Encoding declarations inform the
processor what kind of code the document uses.
• The next tag explains about the type of media that is being requested by the client.
It also specifies the major version which is same as that of the xml version and the
total duration of the requested media file.
• The next tag gives information about the type of the media i.e. Audio or Video,
number of available chunks for this type and number of different quality types
available for this type of requested media file along with the display size and
format for the URL.
• Remaining tags consist of the quality type number, bitrates allotted for that
quality type, information on how it is encoded, display size of that quality type
and some additional information. Additional information consists of private data
that can be used by the client who has requested for the file. This information can
be used by the client to decode the chunk or for privacy purpose.

Figure 4.3 Format of Client Manifest file

4.2.1 Manifest Download

In order to download a Manifest file from the server we are using HTTP protocol by issuing
HTTP request and by receiving its response.
HTTP requests
An HTTP request is made by a client, to a named host, which is located on a server. The aim
of the request is to access a resource on the server. To make the request, the client uses
components of a URL (Uniform Resource Locator), which includes the information needed
to access the resource.
• A correctly composed HTTP request contains the following elements:
• A request line.
• A series of HTTP headers, or header fields.
• A message body, if needed.
Each HTTP header is followed by a carriage return line feed (CRLF). After the last of the
HTTP headers, an additional CRLF is used (to give an empty line), and then any message
body begins.
GET /Manifest.xml HTTP/1.1 Request Line
Date: Thu, 28 Apr 2011 10:14:49 GMT
Connection: close General Headers
Host: 10.10.40.16
Accept: text/xml Request Headers
User-Agent: Mozilla/4.0 (compatible: MSIE 5.0; Windows NT 5.1)
HTTP
REQUEST
Entity Headers
Message Body
Figure 4.4 HTTP Request

Flowchart of HTTP request is as shown below:
START
Get the request

Which file the user is requesting
Get the headers

Headers give information about content length, from
which host and which encoding type is used
Put Request
Put the request to the Server. A method i.e.“GET”
“POST” etc is used to begin request. URL of the file
is only the part path
Check status line

This line is the first line of the response
YES
Is the
Request
status A
already issued
IDLE
NO
Set status line
If the status line is not in IDLE state then the status
line is set to request started
Send body
Check for body data in the request message, if it is
there than send the body

Check the issued URL

Check weather the URL to the requested file is
valid or not
NO
Valid
YES
Connect to Server
Handles the socket connection, issuing of
requests and managing responses.
A
C
Update the connection
Regularly check the connection established
Pump
Called regularly to service outstanding
requests.
Connection close
Close connection, discarding any pending
requests
STOP
Figure 5.3 HTTP Request

The HTTP request issued to the server has four parameters

• Method, tells the type of action the user is requesting from the server. Examples
for methods are GET, PUT, POST etc…
• URL, is only path part: eg "/Manifest.xml".
• Header, is array of name/value pairs, terminated by a null-ptr.
• Body and
• Bodysize
Body & bodysize specify body data of request.
Example of an HTTP request
Request(“GET”,”/Manifest.xml”, 0, 0, 0)
HTTP responses
An HTTP response is made by a server to a client. The aim of the response is to provide the
client with the resource it requested, or inform the client that the action it requested has been
carried out; or else to inform the client that an error occurred in processing its request.
An HTTP response contains:
• A status line.
• A series of HTTP headers, or header fields.
• A message body, which is usually needed.
As in a request message, each HTTP header is followed by a carriage return line feed
(CRLF). After the last of the HTTP headers, an additional CRLF is used (to give an empty
line), and then the message body begins.
An example of HTTP response is as shown in the figure.

HTTP/1.1 200 OK Status Line

Date: Thu, 28 Apr 2011 10:14:52 GMT
Connection: close General Headers
Server: Apache/2.2.3
Accept-Ranges: bytes Response Headers
Content-Type: text/xml HTTP

Content-Length: 3433 Entity Headers RESPONSE
Last-Modified: Tue, 26 Apr 21:12:55 GMT
<html>
<head>
<title>Welcome to this site</title>
</head>
<body> Message Body
<p>This site is under construction</p>
</body>
</html>
Flowchart of HTTP response is as shown below
START
B
Get headers
Retrieve a header from the request
returns 0 if not present
Get status line

Status line is first line of response
Process Status line

Process the obtained status line

Check Status line

Check the processed status line
Is YES
<100 A
or C
>999
NO
Get content length
If the status line is greater than 100
and less than 999 then get the length
of the content requested
Get number of bytes

Get number of bytes in the content
Get location
Get the location where the requested
content is stored
Get reason
Get the HTTP response reason string
Pump
Pump some data in for processing.
Returns the number of bytes used

YES
Request
B s
waiting
NO
Connection close
A Tell in response that connection has
closed
STOP
Figure 5.4 HTTP Response
Examples for Good and Bad requests are as shown below

For an request such as
Request(“GET”, “/Manifest.xml”, 0, 0, 0)
The response would be something like this
header: ['date': 'Thu, 12 May 2011 14:45:35 GMT']
header: ['server': 'Apache/2.2.3 (Fedora)']
header: ['last-modified': 'Thu, 24 Feb 2011 08:16:20 GMT']
header: ['etag': '"3ff83ef-d69-49d02d40d9d00"']
header: ['accept-ranges': 'bytes']
header: ['content-length': '3433']
header: ['connection': 'close']
header: ['content-type': 'text/xml']
Invoke the user callback, if any
BEGIN (200 OK)
COMPLETE (3433 bytes)

And for the request such as

Request(“GET”, “Manifest.xml”, 0, 0, 0)
The response would be something like this
header: ['date': 'Thu, 12 May 2011 14:46:44 GMT']
header: ['server': 'Apache/2.2.3 (Fedora)']
header: ['content-length': '302']
header: ['connection': 'close']
header: ['content-type': 'text/html; charset=iso-8859-1']
Invoke the user callback, if any
BEGIN (400 Bad Request)
COMPLETE (302 bytes)
The response obtained for the first request is an example for GOOD request while the
response got for the second request is an example for BAD request.
4.1.2 Manifest Parser

The XML parser loads a full XML file in memory, it parses the file and it generates a tree
structure representing the XML file. We can also parse XML data that we have already
stored in a memory buffer. We can also modify the tree using "add" and "delete" functions
and regenerate a formatted XML string from a subtree. Memory management is totally
transparent through the use of smart pointers.
In an event-driven approach for processing XML data, a parser reads the data and notifies
specialized handlers that undertake the desired actions. Note that here the term event-driven
means a process that calls specific handlers when the contents of the XML document are
encountered.
The various XML parser implementations differ in their application program interfaces. For
example, one parser could notify a handler of the start of an element, passing it only the
name of the element and then requiring another call for the handling of attributes. Another
parser could notify a handler when it finds the same start-element tag and pass it not only the
name of the element, but a list of the attributes and values of that element.

Another important difference between XML parsers is in which representation they use to
pass data from the parser to the application: e.g. one parser could use an STL list of strings,
while another could use a specially made class to hold attributes and values. The methods for
handling a start-element tag with each approach would be very different and would certainly
affect how you program them.
A flowchart of the Manifest Parser depicting its working is as shown below,
START
Open File Helper

Obtain the location of the file
Open the File

Opens the file and returns a pointer
having first tag
Assume the value of global character

If 0 then all char are of same length of 1
bytes else char are of different lengths
from 1 to 4 bytes
Write to a file
Write the contents of the opened file
one string at a time
Duplicate the written string

Make a copy of the string

Obtain the tag

Tags contain the information based on
which the string is parsed
Extract the information from the tag

Has information such has xml version,
encoding type, available bitrates and
number of chunks and so on
Decode the string

Based on the information available from
the tag decoding is done to extract the
string
Obtain character from the string

Read one character at a time
NO All
character
s
obtained
Obtain next
character
YES
Find any tokens in the string

search the string for tokens like <, >,
=,’,’….

Find number of lines and columns in the

X string
Find all the information of the string so that
it can be parsed properly
Obtain the next Store the information extracted

tag Store all the information extracted from the
tag one at a time
NOS All tags

obtaine
d
YES
Obtain the stored information
Parse the string

Convert the string into tree structure
Create the header element

Create a root node for the tree structure
Return the root element

Return the root node
STOP
Figure 5.4 Flowchart depicting the working of Manifest Parser

4.1.3 URLBuilder
It generates the URL based on the information that is available from the parsed Manifest file.
The URL will contain the following information
• XML version
• Number of Chunks
• Bitrate
• Encoding type
• Duration of the file
• Type of information (Audio or Video)
Flowchart showing the working of URLBuilder is as shown below:
Start
Open a new stream for Reading

Opens the given URL
Allocate the internal Buffers

Size of the buffers depend on duration of
the chunk and maximum bitrate
Create a reader thread

Reads the data into the buffer

Z
NOT EMPTY
Chec Wait for the
k consumer to
Y
Buffe consume the data
r
EMPTY
NO
Is there a
A
URL
YES
Open connection to the given URL

Returns a file handler where the http
response can begin to be read
Read the data from the URL

Reads completely the available data
Load the file into the buffer

Saves the file in the allotted buffer
Open the file in the buffer

Opens the file in the buffer for which URL
is to be built
Compare the Bitrates

check the available bitrates for different
quality files

Select the least quality bitrate

First chunk is always of least quality bitrate
Check the network and CPU conditions

This is necessary for dynamic bitrate
switching in real time
FALSE Can the TRUE

user
support
better
bitrate
Select better quality bitrate

Continue with existing bitrate Out of the available bitrates
User cannot support higher quality select the one that user can
bitrate support
TRUE
Request
is from
X the
beginning
FALSE
Get the requested chunk

Update the chunk with chunk number +
requested offset
C
C
Dept of PG X
Studies in CE&A, NIE, Mysore. 27
Build URL
Builds into pointer a URL with the base path
Start Consumer Thread

Create a thread to perform data write operation
Pump the data to consumer thread

Update the thread this operation repeats until the
entire data is pumped
Consume the data

Y Consume n bytes of data returns a pointer where
the desired data is present
FALSE
No
P more
chunks
Z TRUE
Exit from consumer thread

Data writing operation completed
A
Exit from reader thread
Data completely read
Stop
Figure 5.5 Flowchart depicting the flow of URLBuilder

An example showing the format of the URL generated from the client Manifest file is as
shown below
http://10.10.40.16/Manifest.ism/QualityLevels(3450000)/Fragments(video= 610275114)
The URLBuilder gets the parsed Manifest file as input. This file has all the information
regarding the file to be downloaded. The URLBuilder uses the information obtained from the
previous stage to build the URL.
The URLBuilder gets the format of the URL to be build for each chunk from the parsed
client Manifest file.
Format of the URL to be generated would be some thing like this:

Url= QualityLevels(bitrate)/Fragments(video={start time})
There will be different quality levels for a single file and depending on these levels the
bitrates vary from one level to another. For the first chunk downloaded the URLBuilder by
default assumes the bitrate of least quality level and start time would be given by user and if
user has not given any start time than the start time would be assumed to be zero.
For the first chunk the bitrate is assumed to be of least quality because by the time this chunk
is downloaded the system would be able to analyze the network criteria, the user CPU
conditions, and users’ available bandwidth. This analyzed information would be used to
select the value for bitrate for corresponding chunks.
The URLBuilder after selecting the values for bitrate and start time would just append host
IP address and client Manifest file to form a complete URL.
In the above example, 10.10.40.16 is the host IP, Manifest.ism is the client Manifest file,
3450000 is the bitrate selected which tells the quality level of the video file and 610275114
is the start time of the video file.

Chapter 5
System Implementation
This chapter describes the development of URLBuilder for Smooth Streaming through the
languages used. This chapter also explains the pseudo code for subroutines used to
implement in each of the modules. The modules have been implemented using C++
language.
5.1 Manifest Download

We have 2 classes here, both are friend classes to each other and they are as follows :
.1 Connection and
.2 Response
The class Connection has the following public methods

Connection ( const char* host, int port )
~Connection()
void setcallbacks( ResponseBegin_CB begincb, ResponseData_CB datacb,
ResponseComplete_CB completecb, void* userdata )
void connect()
void close()
void pump()
bool outstanding()
void request( const char* method, const char* url, const char* headers[]=0,
const unsigned char* body=0, int bodysize=0 )
void putrequest( const char* method, const char* url )
void putheader( const char* header, const char* value )
void endheaders();
void send( const unsigned char* buf, int numbytes );

These methods are explained in the below sections.
And for the class Response, the methods are as follows :

const char* getheader (const char* name)
bool completed ()
int getstatus()
int getContentLength()
int getBytesRead()
Response (const char* method, Connection& conn )
int pump(const unsigned char* data, int datasize)
void notifyconnectionclosed()
The sequence of calls for Manifest download is

1. Connection (const char* host, int port)
Creates an object of connection class .
2. void setcallbacks( ResponseBegin_CB begincb, ResponseData_CB datacb,
ResponseComplete_CB completecb, void* userdata)
Handles callback functions, where ResponseBegin, invoke user callback if any,
ResponseData, invoke callback to pass out the data and ResponseComplete, once the
response is complete invoke this callback.
3. void putrequest( const char* method, const char* url )
Function to issues user requests, where method can be “GET”, “POST” etc and URL
is the part path url of the file.
4. void pump()
This function is called regularly until there are no outstanding requests. As responses
are received, the callbacks will be invoked. This process is done twice i.e.
 During Connection: Updates the connection (non-blocking). Just keeps calling

regularly to service outstanding requests.
 During Response: pump some data in for processing. Returns the number of bytes
used. Will always return 0 when response is complete.

5.1.1 Connection object methods

Sequence of calls for Connection is:
1. Connection (const char* host, int port)
2. void setcallbacks( ResponseBegin_CB begincb, ResponseData_CB datacb,
3. void connect()
4. void request( const char* method, const char* url, const char* headers[], const
unsigned char* body, int bodysize )
5. void putrequest( const char* method, const char* url )
6. void pump()
7. void close()
8. ~Connection()
Connection (const char* host, int port)

Constructor. Specifies host and port, but connection isn't made until request is issued
or connect() is called.
~Connection()
Destructor. If connection is open, it'll be closed, and any outstanding requests will be
discarded.
void setcallbacks( ResponseBegin_CB begincb, ResponseData_CB datacb,

Set up the response handling callbacks. These will be invoked during calls to pump().
begincb - called when the responses headers have been received
datacb - called repeatedly to handle body data
completecb - response is completed
userdata - passed as a param to all callbacks.

void connect()
Don't need to call connect() explicitly as issuing a request will call it automatically if
needed. But it could block (for name lookup etc), so you might prefer to call it in advance.
void close()
It closes the connection, discarding any pending requests.
void pump()
Update the connection (non-blocking) Just keep calling this regularly to service
outstanding requests. As responses are received, the callbacks will be invoked.
bool outstanding() const

Returns true if any requests are still outstanding.
void request( const char* method, const char* url, const char* headers[], const
unsigned char* body, int bodysize )
High-level request interface. Issues a request.
Method - "GET", "POST" etc...
url - eg "/Manifest.xml"
headers - array of name/value pairs, terminated by a null-ptr
body, bodysize - specify body data of request (eg values for a form)
void putrequest( const char* method, const char* url )

Begin a request
method is "GET", "POST" etc...
url is only path part: eg "/index.html"
void putheader( const char* header, const char* value )

void putheader( const char* header, int numericvalue )
Add a header to the request (call after putrequest() )
void endheaders()
Indicate that your are finished adding headers and the request can be issued.
void send( const unsigned char* buf, int numbytes )

send body data if any. To be called after endheaders()

5.1.2 Callback types

typedef void (*ResponseBegin_CB)( const Response* r, void* userdata )
Invoked when all the headers for a response have been received.
The Response object can be queried to determine status and header values.
userdata is the same value that was passed in to Connection::setcallbacks().
typedef void (*ResponseData_CB)( const Response* r, void* userdata, const unsigned

char* data, int numbytes )
This callback is invoked to pass out data from the body of the response. It may be
called multiple times, or not at all (if there is no body).
typedef void (*ResponseComplete_CB)( const Response* r, void* userdata )

Once a response is completed, this callback is invoked. When the callback returns, the
respsonse object will be destroyed.
5.1.3 Response object methods

When a callback is invoked, a response object is passed to it. The following member
functions can be used to query the response:
const char* getheader( const char* name ) const
retrieve the value of a header (returns 0 if not present)
int getstatus() const

Get the HTTP status code returned by the server
const char* getreason() const
Get the HTTP response reason string returned by the server
5.2 Manifest Parser
Sequence of calls for Manifest Parser is
1. openFileHelper ( filename.xml , tag)

2. parseString (xmlDoc, tag )
3. createXMLTopNode_WOSD(XMLCSTR lpszName, charisDeclaration=FALSE)
4. addChild(XMLCSTR lpszName, char isDeclaration=FALSE, int pos=-1)
5. addChild(XMLNode nodeToAdd, int pos=-1)
6. fromXMLString(XMLCSTR s, int lo, XML *pXML)
7. parseString(xmlDoc,"XYZ ")
Pseudo code of some of the important functions used for parsing are as shown below
XMLNode xMainNode=XMLNode::openFileHelper ( filename.xml , tag);

It takes the Manifest file to be downloaded as the first argument and the tag as the second
argument and is NULL by default. This function returns the address of the stored xml file.
To manipulate the data contained inside the XML file, the first operation is to get an instance
of the class XMLNode that is representing the XML file in memory.
XMLNode xMainNode=XMLNode::parseString (xmlDoc, tag );

This function can be used when the Manifest file is already stored in memory. The arguments
to this function are the address of the stored file and NULL for tag.
If he XML document is already in a memory buffer pointed by variable "char *xmlDoc" .
This will create an object called xMainNode that represents the first tag, named “tag” found
inside the XML document. This object is the top of tree structure representing the XML file
in memory.
static XMLNode createXMLTopNode_WOSD(XMLCSTR lpszName, char

isDeclaration=FALSE);
This function takes two arguments as input the first one being a constant character pointer
which is predefined as XMLCSTR to the element name and it’s value is NULL if it is the
root.

This function is used to create the top node of the Tree structure and return the root node of
type static XMLNode.
XMLNode addChild(XMLCSTR lpszName, char isDeclaration=FALSE, int pos=-1);

This function adds a node to the root in the tree structure, where the first argument is constant
character pointer which is predefined as XMLCSTR to the element name and it’s value is
NULL if it is root and the position where the child has to be placed.
We need to start by creating the top node with the "createXMLTopNode" function and then
add new nodes with the "addChild" function.The parameter 'pos' gives the position where the
childNode is to be inserted. The default value (pos=-1) inserts at the end. The value (pos=0)
insert at the beginning (Insertion at the beginning is slower than at the end).
XMLNode addChild(XMLNode nodeToAdd, int pos=-1);

This function takes two arguments as input one of them is the address of the node to be
inserted of the type XMLNode and the position where it has to be inserted in the tree
structure.
This node is first searched in all available tree structures and if the "nodeToAdd" has some
parents, it will be detached from its parents before being attached to the current XMLNode.
This function returns the root node of type XMLNode.
XMLNode fromXMLString(XMLCSTR s, int lo, XML *pXML)

This function takes three parameters as inputs which are a string (s) and length (lo) of string
and the Output is new allocated string converted from xml.
This function decodes the escape sequences and replaces them by the characters. This
function is used internally by the XML Parser. All the calls to the XML library will always
gives you back the "decoded" strings.
XMLNode xMainNode=XMLNode::parseString(xmlDoc,"XYZ ");

This function takes two parameters as input one of them is the document to be parsed starting
from the tag given as input ( here “XYZ”). This function returns the first node of the tree
structure of the type XMLNode.

This will create an object called xMainNode that represents the first tag named “XYZ” found
inside the XML document. This object is the top of tree structure representing the XML file
in memory.
XMLNode xNode=xMainNode.getChildNode("Header");
This function is used to append header information to the first tag obtained from the previous
function. The header information may contain the tag number, tag length etc.
This command creates a new object called xNode that represents the "Header" tag inside the
first tag and returns the address of the first tag of type XMLNode.
5.3 URLBuilder
Here we have only one class namely, URLBuilder and it’s methods are as follows :
URLBuilder()
~URLBuilder()
struct Stream *openstream(char *url, int buflen, int flags, struct Stream *sstream )
void closestream()
int consumestream(int lg, unsigned char **pbuf, struct ChunkBuf **pattr)
bool pump ( void )
int Duration(void)
void setcallbacks(ResponseBegin_CB begincb, ResponseData_CB datacb, ResponseComplete_CB
completecb, void *UserData)
int build_url(char *pdest, char *pbase, char *purl, int maxlen)
static void *reader_thread(void *p)
The last two are private.
Sequence of calls for URLBuilder is
1. openstream (char *url, int buflen, int flags, stream *sstream )

2. consumestream(int lg, unsigned char **pbuf, struct ChunkBuf **pattr)

3. pump(void)
4. closestream()
struct stream openstream (char *url, int buflen, int flags, stream *sstream )
This function opens a new adaptative stream for reading and has three input arguments. The
first argument has an address of the URL requested by the user, second argument is an
integer variable whose initial value is assumed to be zero, the third argument specifies what
has to be done with the supplied URL i.e. just open the contents in the URL, open it quickly
and completely and so on and the final argument is the address of the stream structure which
has the information about the stream.
This will open the given URL, read the appropriate playlists (if required) and allocate all
internal buffers. The function will return as soon as stream reading has been launched (no
data yet).buflen indicates the desired buffer size in seconds; if 0, the library will decide the
size. Returns a pointer to the allocated Stream struct or NULL on error. The members of the
stream structure as shown
 unsigned long maxbitrate
 unsigned long minbitrate
 unsigned long duration
 unsigned long no_chunks
Maxbitrate holds the maximum bitrate obtained from client Manifest file where as minbitrate
holds the minimum bitrate, duration gives a value equivalent to (Total duration/Total number
of chunks) where total duration and total number of chunks gives maximum duration of the
file and maximum chunks available and no_chunks has Total number of chunks obtained
from client Manifest file
closestream()
It will close the given adaptative stream, kills reading threads and frees buffers.
int consumestream(int lg, unsigned char **pbuf, struct Chunk **pattr)

This function takes three arguments as input, first argument is of integer type and has a
default value equivalent to Play size. The second argument is a double pointer of unsigned
character type and holds an address of a unsigned character pointer. The final argument is a
pointer to a structure Chunk.
The members of structure Chunk are as shown,
 unsigned long lg
 unsigned long received
 unsigned long consumed
 unsigned long seq
 unsigned long pos
 int br
 int netbr
 unsigned char *pdata
This structure has seven members, member lg represents value equal to chunk length,
member received represents number of received bytes, consumed represents number of
consumed bytes, members seq and pos represents sequence number and position of file from
the beginning in milliseconds respectively, members br and netbr represents value of bitrate
of a particular quality file and content of that bitrate respectively final member holds the
address of the actual chunk.
This function returns (into pbuf) a pointer where the desired data or less is present. Actual
length of piece is returned as function result. More information about the provided data can
be found in structure whose address is stored in *pattr (unless pattr is NULL). This function
never blocks. If there is nothing available, it returns 0. If the file is finished or if there was an
error, returns -1.
bool pump(void)
pumps the data to the consumer thread
int Duration(void)

Gives total duration of the stream and return a integer value equivalent to total
duration divided by 1000.
Chapter 6
Conclusion and Future Enhancement

6.1 Conclusion
This report concludes that, the Smooth Streaming acts like streaming, but is based on HTTP
progressive download. The HTTP downloads are performed in a series of small chunks,
allowing the media to be easily and cheaply cached along the edge of the network, closer to
clients. Providing multiple encoded bit rates of the same media source also allows clients to
seamlessly and dynamically switch between bit rates depending on network conditions and
CPU power. The resulting user experience is one of reliable, consistent playback without
stutter, buffering or "last mile" congestion.
The URLBuilder for Smooth Streaming has been developed to extract all possible
information from the parsed file and generate a URL accordingly. The developed code works
in all configuration, boundary, functionality, interoperability and integration.
6.2 Future Enhancement

Using the generated URL from the URLBuilder can be used as an input to a fragment parser
i.e. parsing audio and video information separately and send decoding these in corresponding
decoders. The decoded information is applied to the rendering module.
Over the next couple of years, we will notice everything available in web, and the emergence
of Over The Top (OTT), hence this technology assumes significant importance.

Bibliography
[1] Alex Zambelli, Media Technology Evangelist” IIS Smooth Streaming Technical
Overview”, March 2009.
[2] Docum Tak Cheung Lam and Jianxun Jason Dingent “XML Document Parsing:
Operational and Performance Characteristics”, October 2008
[3] http://www.alcatel-lucent.com
[4] http://www.xml.com/

Sandep Project Report Final

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sandep Project Report Final

Caricato da

Copyright:

Formati disponibili

URLBuilder for Smooth Streaming 2010-11

1.1.1 Where Does an URLBuilder come in Smooth Streaming?

• The server, which provides the service,

• The client, which requests for service.

Dept of PG Studies in CE&A, NIE, Mysore. 1

• Chunk start time

• Duration of that chunk

• Type of encoding used

1.2 Problem Statement

Dept of PG Studies in CE&A, NIE, Mysore. 2

1.3 Objective of the Project

1.4 Brief Outline of the Project

1.5 Thesis Organization

Dept of PG Studies in CE&A, NIE, Mysore. 3

Dept of PG Studies in CE&A, NIE, Mysore. 4

2.2 Functional Requirements

Dept of PG Studies in CE&A, NIE, Mysore. 5

3.2 SMOOTH STREAMING

• MP4 is a lightweight container format with less overhead.

Dept of PG Studies in CE&A, NIE, Mysore. 6

There are actually two parts to the Smooth Streaming format:

3.3 MANIFEST FILES

• VC-1, WMA, H.264 and AAC codec’s

• Multi-language audio tracks

Dept of PG Studies in CE&A, NIE, Mysore. 7

4.1 Smooth Streaming Client Architecture

Figure 4.1 Smooth Streaming Client Architecture

Dept of PG Studies in CE&A, NIE, Mysore. 8

Dept of PG Studies in CE&A, NIE, Mysore. 9

 And room for some additional information.

Dept of PG Studies in CE&A, NIE, Mysore. 10

4.2 Project Overview

Figure 4.2 Project overview

Dept of PG Studies in CE&A, NIE, Mysore. 11

Client manifest file

• The first tag of an Manifest file is always of the form

Dept of PG Studies in CE&A, NIE, Mysore. 12

Figure 4.3 Format of Client Manifest file

Dept of PG Studies in CE&A, NIE, Mysore. 13

4.2.1 Manifest Download

Figure 4.4 HTTP Request

Dept of PG Studies in CE&A, NIE, Mysore. 14

Flowchart of HTTP request is as shown below:

Get the request

Get the headers

Check status line

Dept of PG Studies in CE&A, NIE, Mysore. 15

Check the issued URL

Figure 5.3 HTTP Request

Dept of PG Studies in CE&A, NIE, Mysore. 16

The HTTP request issued to the server has four parameters

An example of HTTP response is as shown in the figure.

Dept of PG Studies in CE&A, NIE, Mysore. 17

HTTP/1.1 200 OK Status Line

Content-Type: text/xml HTTP

Flowchart of HTTP response is as shown below

Get status line

Process Status line

Dept of PG Studies in CE&A, NIE, Mysore. 18

Check Status line

Get number of bytes

Dept of PG Studies in CE&A, NIE, Mysore. 19

Figure 5.4 HTTP Response

typedef void (ResponseData_CB)( const Response r, void* userdata, const unsigned

typedef void (ResponseComplete_CB)( const Response r, void* userdata )