MASTER'S THESIS
Mobile video bit rate adaption
Jonas Öhlund
Master of Science in Engineering Technology Computer Science and Engineering
Luleå University of Technology
Department of Computer science, Electrical and Space engineering
Mobile video bit rate adaption
Jonas ¨ Ohlund
Lule˚ a University of Technology
Dept. of Computer Science and Electrical Engineering
November 12, 2009
A BSTRACT
The last few years mobile devices have become more and more powerful and with larger and more colorful displays. This has paved the way for delivering high video quality for these devices.
Every year each of the big mobile manufacturers, Motorola, SonyEricsson, Nokia, Sam- sung and so on, release numerous devices - each with different technical specifications.
Some of them follows most of the standards, most of them follows some of the standards.
This never ending flow of new devices with varying amount of standards followed com- bines to fragmenting the market in a way that makes it extremely difficult to support different devices when developing mobile clients or mobile web sites. This fragmentation also makes it difficult to deliver the best possible video quality to each individual device.
This thesis proposes a way of combined approaches to find out the available bandwidth for a specific device, and thus be able to adapt the video bit-rate. The different techniques which winded up in the final solutions consists of values found in HTTP headers as well as values parsed from a User-Agent Profile of a device, but also of more protocol specific solutions: iPhone Live Streaming, MBR ASF and a modification to Darwin Streaming Server. As a final fallback a small sample image was downloaded before the video was requested to provide an approximate measurement of the available bandwidth.
The solution proposed in this thesis covers all three delivery methods used; MMS, RTSP and progressive download. A switch should not be executed in all cases, however, the solution will improve the user experience for many users.
ii
P REFACE
Two and a half years ago I just finished a school project where we worked together with Ericsson Research. This was the first time I ever had to develop for mobile device. Just after finishing this project I was presented with the opportunity of working for Mobizoft over the summer holiday. When the summer had passed I was asked if I was interested of working part time while studying - I said yes.
During the time at Mobizoft I have learned to appreciate working for a small company.
Being part of a small group of people, everyone becomes invaluable because of the knowl- edge they possess and everyone gets a lot of responsibility. When the time for my master thesis approached, I was asked to do it at Mobizoft.
Working on this project has been tremendously educating. Since mobile video is a quite small and new area finding information has been a challenge. Another challenge has been to limit oneself. The project grew when new technologies were found and new approaches taken. Of course I wanted to deliver the best possible solution, which made it tough to narrow it down to the seemingly best technologies.
I am satisfied how the project turned out and so I hope Mobizoft is. The future for mobile video has never been brighter.
In closing, I would like to thank my supervisor at LTU; Ulf Bodin for assistance with the report. I would also like to thank everyone at Mobizoft for assisting me throughout the thesis and for giving me the opportunity of making a significant contribution to their product - C4M (Content 4 Mobile).
Jonas ¨Ohlund November 2009
iii
C ONTENTS
Chapter 1 – Introduction 2
1.1 Background . . . 2
1.1.1 Market . . . 2
1.1.2 Technical . . . 2
1.1.3 Cost . . . 4
1.2 The C4M platform . . . 5
1.2.1 Concept . . . 5
1.2.2 Backbone . . . 6
1.2.3 Dependencies . . . 6
1.2.4 Transcoding . . . 6
1.2.5 Streaming . . . 6
1.2.6 Unique Devices . . . 7
1.2.7 Rules . . . 7
1.2.8 External Device Description Repositories - DDR . . . 7
1.2.9 Content Lines . . . 7
1.2.10 Toolsteps . . . 8
1.3 Goal . . . 8
1.4 Delimitations . . . 9
Chapter 2 – Problem 10 2.1 Technology Analysis . . . 10
2.1.1 Switching Definitions . . . 10
2.1.2 Decoding Capacity . . . 10
2.1.3 Delivery Method . . . 11
2.2 Approach . . . 12
2.2.1 QuickTime Reference Movie - QRM . . . 12
2.2.2 SMIL . . . 13
2.2.3 Headers . . . 13
2.2.4 User-Agent Profile . . . 13
2.2.5 Brute Force Test . . . 13
2.2.6 RTSP proxy/server . . . 13
2.2.7 Windows . . . 14
2.3 Technology Discussion . . . 14
Chapter 3 – Requirements 15
3.1 Mobile Devices . . . 15
3.1.1 Database validity/representation . . . 15
3.2 Performance issues . . . 16
3.3 Correctness . . . 16
Chapter 4 – Results 17 4.1 Overview . . . 17
4.2 Techniques Evaluated . . . 17
4.2.1 Multiple Bit Rate (MBR) ASF . . . 18
4.2.2 Intelligent Streaming . . . 19
4.2.3 SMIL . . . 20
4.2.4 RTSP . . . 20
4.2.5 User-Agent Profile . . . 24
4.2.6 pss6:MediaAlternatives . . . 28
4.2.7 ThreeGPFileFormat component . . . 28
4.2.8 3GPP-Adaptation-Support . . . 28
4.2.9 X-Headers . . . 28
4.2.10 iPhone . . . 31
4.2.11 Brute Force Test . . . 35
4.3 Threshold . . . 40
4.3.1 Standard Data Rates . . . 40
4.3.2 iPhone . . . 45
4.4 Complete solution . . . 45
4.4.1 Flow . . . 46
4.4.2 Detailed Description . . . 47
4.5 Testing The Solution . . . 49
4.5.1 Coverage . . . 49
4.5.2 Performance Analysis . . . 51
Chapter 5 – Discussion 53 5.1 Drawbacks . . . 53
5.2 Future Work . . . 53
5.2.1 RTSP Bitrate header - RTSP 2.0 . . . 54
5.2.2 Microsoft Live Smooth Streaming . . . 55
5.2.3 UserAgent Profile . . . 55
5.2.4 Manufacturer API . . . 55
5.2.5 Flash . . . 56
v
5.2.6 IP Address Lookup . . . 56
5.2.7 Other Possibilities . . . 56
Chapter 6 – Conclusion 57 6.1 The Problem . . . 57
6.2 The Solution . . . 57
6.3 The Analysis . . . 59
6.4 The Discussion . . . 59
6.5 Final Words . . . 59
Appendix A – Example of an .m3u8 file 61
Appendix B – Possible values of CurrentBearerService 62
Appendix C – List of available X-HTTP headers 63
Appendix D – Rules for CurrentBearerService attribute 64
Appendix E – Rules for SupportedBearers attribute 67
Appendix F – Rules for VideoDecodingByteRate attribute 70 Appendix G – Tables of values found in SupportedBearers attribute 72
Appendix H – JavaScript Test Setup 75
Appendix I – List of devices which benefits from the 3G. rule 79 Appendix J – Sequence diagram of the server side test 80
vi
A BBREVIATIONS
C4M Content 4 Mobile
RTMP Real Time Messaging Protocol MMS Microsoft Media Services RTCP RTP Control Protocol
RTP Real-time Transport Protocol RTSP Real-Time Streaming Protocol
3GPP The 3rd Generation Partnership Project PSS Packet-Switched Streaming Service SDP Session Description Protocol
SMIL Synchronized Multimedia Integration Language IIS Internet Information Server
DSS Darwin Streaming Server
WURFL Wireless Universal Resource File VOD Video On Demand
OMA Open Mobile Alliance
1
C HAPTER 1 Introduction
1.1 Background
1.1.1 Market
”Pyramid Research says mobile video services will generate some $16 billion in revenue worldwide in 2014 and represent 15 percent of all wireless data sales by that time in leading markets like the U.S.” [1]
There are many more articles with the similar conclusion: mobile video is going to be huge.
A question which arises with a foreseeing like this is where the revenues will come from. One apparent answer is advertising, but there are certainly others. One other way is adding additional value to your site; which is what SF1 has done by displaying trailers on their mobile site. A fundamental issue to overcome to achieve a real value from mobile video is the user experience. When watching video with a mobile phone the perceived user experience is tightly connected to the quality of the video. The quality is based on multiple aspects, e.g. which codec is used. One of the most apparent property is the bit-rate of the movie. Hence, to be able to generate revenues from mobile video, producing videos with the best possible quality is crucial.
1.1.2 Technical
The problem arising from the fragmentation of the market is that there are so many different levels of video support; codecs, macro blocks, bit-rates, fps etc. Most man- ufacturers does not provide this kind of detail in their specifications, they settle with informing which codec is supported - if even that.
To deliver the best possible mobile video experience one have to overcome this frag-
1A Swedish cinema chain
2
1.1. Background 3 mentation. There is no easy solution to this problem, and they all have their advantages and disadvantages.
A common approach is to develop tests to go through and test the capabilities of a mobile device. The probably most well-known example of this technique is WURFL.
It relies on its users to provide the information they have found out about a device.
The most prominent drawback of this approach is the lack of information when a new device enters the market. Another drawback, as WURFL themselves says: ”There is no guarantee of any kind that any of the info in the WURFL is correct. All the information has been gathered by collecting reports from users and developers around the globe.” [2].
Another well known example is Device-Atlas. They rely on multiple sources; operators, device manufacturers, Mobizoft etc. The data is then cross referenced and verified [3].
This approach suffers from the same drawback as WURFL; when a new device enters the market they will need to update their data, verify it and then release a new database.
A different approach would be to detect these capabilities in real-time - when they access the web. This is what Mobizofts C4M (Content 4 Mobile) does.
The mission at hand is to enhance the C4M platform so it will not just be able to detect capabilities about the device itself, but also to detect valuable information about the connection - in real-time - and use this information to choose the video with the optimal bit-rate.
A question that might arise when reading this thesis is: Can’t this be controlled by the streaming server itself? Yes, it does control this, to some extent. Darwin Streaming Server (DSS) will adjust the rate based on RTCP Receiver Reports and values found in the PSS part of the User-Agent Profile. The rate is adjusted to prevent the clients buffer from underflowing and overflowing. DSS will also adapt the stream by removing selected video frames from a single video stream to achieve a lower bit rate. Drawbacks of this approach is that the user will still have to wait for the player to buffer and try to playback the stream for a while, until the server realizes that the receiver can’t accommodate the full bit-rate. The user will also suffer from not receiving all the frames. These two drawbacks combined, gives a poor user-experience. Instead, if the server would choose a file with a more appropriate bit-rate the user would not have to buffer as much and will receive a video of better perceived quality.
There is another form of bit rate adaptation, stream switching. When using stream switching you have the same video file encoded in multiple bit rates, either in different tracks in the same file or using multiple files. To utilize stream switching the streaming server will evaluate the bandwidth condition by analyzing the RTCP Receiver Reports.
When it notice a drop in bandwidth it will switch to a track with lower bandwidth.
This technique is used in Helix Mobile Streaming Server and requires the client to have support for either PSS6 or PSS5[4]. This will make the stream robust even to hand- overs between different cells in the cellular network, and thus providing a solid end-user experience. The major drawback of using Helix Mobile Streaming server is the cost, which will be discussed in the next section.
1.1. Background 4 There are more aspects then just bit-rate which can be adjusted when knowing the available bit-rate. One might choose to redirect to a file with only video and no sound - or the other way around - when the the available bit-rate is really low. There is also the possibility to choose a different codec, more suitable to the current conditions.
Another way to find the bit-rate could be achieved by implementing a client on the phone. In this way, there would most certainly be ways to access lower levels of the phones hardware and find information about the network connection. But this is not an option for Mobizoft. This would require each user whom would wish to see a video on the Internet with his or her phone, to download and install a program on their phone.
This would also increase cost for developing and maintaining this program to each of the available and upcoming platforms. C4M is intended to work with any device, anywhere and to do it seamlessly, so the user won’t even know how complicated the mobile web can be - it just works.
1.1.3 Cost
As mentioned in the previous section, the cost of a streaming server can be an issue.
Darwin is available free but exists in a premium version; QuickTime Streaming Server, which comes bundled with Mac OS X Server Leopard. Windows Media Services comes bundled with Windows Server 2003. Alternatives are Flash Media Server 2 and Helix Mobile Server.
In Table 1 we can see a price comparison made by www.networkcomputing.com (see [5]). In this table one can clearly see how much it can cost to stream, not mentioning the cost for disc space and bandwidth. There is also a ”hidden cost” in switching to a new environment: learning to configure and get to know the new platform.
These costs can be hard to motivate, especially when the gains are not immediate.
Price Comparison Darwin Stream-
ing Server 5.5.1
Flash Me- dia Server 2
Windows Media Services 9
Helix Mo-
bile Server
11.0.0.1596 Server, 100
streams
Free $4500 Free $5000
Server, 400+
streams
Free $11340
(450 streams)
Free $13000 (unlim-
ited)
Table 1: Cost comparison over streaming servers
1.2. The C4M platform 5
1.2 The C4M platform
To provide some knowledge about the system which this work is based upon and to be able to discuss the implementation, a general description will be given. In Figure 1.2.1 is an overview over how a request to C4M might look like.
1.2.1 Concept
A common misconception about C4M is that it’s an application on the device itself, but this is not the case. The idea of C4M is to provide an API which web developers can use when building mobile web sites. This API supplies important data about each device.
Requests to the API is basically done by embedding these requests in the mobile web site. These requests will then be executed when a mobile device access it, and the site will then be rendered based upon the results from these API calls.
Figure 1.1: A device request a site, this site contains a call to C4M which decides whether it’s a mobile device or a PC. Then C4M redirects the device to the correct site.
1.2. The C4M platform 6 The platform also provide a way to uniformly access URLs. This can be used by switching between a pc site and a mobile version depending on which device is requesting the URL. It can also be used by using the same URL for an image or video and returning different versions of these media files depending on which devices that access the page.
<a h r e f =”h t t p : / /www. y o u r s e r v e r . com/c4m/ P l a y M e d i a F i l e ? l i c e n c e=
y o u r l i c e n c e&u i d=movieUID”> p l a y </a>
Listing 1.1: A sample URL for unified access to a movie
1.2.2 Backbone
C4M is a server which parses requests to its API and returns an answer. An important corner-stone in C4M is its adaptability - it’s platform independent. This makes it easier for the customer to integrate with C4M in their existing environment. It’s built upon J2EE and uses JBoss as the application server.
1.2.3 Dependencies
C4M is relying on FFMpeg for transcoding of video material. Delivery of the video material is done either by Windows Media Services, Darwin Streaming server or a web server (Apache or IIS).
1.2.4 Transcoding
Transcoding of a movie to multiple formats will take more time when there are more output formats. It also depends on the codec used in the input video. An example is the H.264 codec, which is much more demanding to decode than the MPEG2 codec. If encoding a movie takes too long time, multiple movies might end up in the encoding queue while the movie is transcoded to all formats. Long transcoding times adds time to when the user who uploaded the movie will be able to watch it, and thus degrading the user experience. Multiple output formats will also use more disc space, and might also add a network cost if the encoding and streaming are not located on the same computer.
1.2.5 Streaming
C4M can already find out the capabilities of a device in real-time, including the video- specific information such as format support. Thus, it can deliver the appropriate format, such as mp4 for iPhone and asf for windows mobile. There is however another problem which C4M cannot handle: selecting a video with regards to the available bit-rate.
1.2. The C4M platform 7
1.2.6 Unique Devices
When a device access C4M a few values are combined to a unique value to distinguish this device; the chash. This hash is based upon three HTTP headers: accept, User-Agent2and the url to the User-Agent Profile. The reason why the accept header is included is that the device sends different accepts depending on what file it requests. The information in the accept can be used to determine what file types the device supports. Hence all different accepts needs to be taken into account.
C4M 4.0
It was found that these values where not enough to uniquely identify all devices. Some browsers, e.g. Opera Mini, modifies the user-agent to reflect the browser which is used, making C4M detecting every device with an Opera Mini browser as the same device.
However, these browsers also provides the original user-agent. In C4M 4.0 this original user-agent is also a part of the chash.
1.2.7 Rules
The first time a device access C4M all its headers and, if available, its User-Agent Profile are parsed. From these values a number of capabilities are generated. Capabilities can be examined and analyzed to form different rules. These rules are then used to form new capabilities or to change the value of a capability.
The details of how rules are created and used will not be covered, since this is not required to get a general understanding of the rules provided.
1.2.8 External Device Description Repositories - DDR
Since C4M don’t rely on having a huge database but instead detects capabilities in real- time, it can complement this detection with help of other Device Description Repositories (DDRs). This enables C4M to benefit from the data users has found out about devices and still detect capabilities in real-time. Currently C4M uses two DDRs - Device Atlas and WURFL. These are used as a complement to the capabilities that can be found in real-time.
1.2.9 Content Lines
With respect to the rules, decisions are made on what type of video content to deliver.
This content groups are called Content Lines. It is possible to add as many Content Lines as deemed necessary. The current selection of Content Lines can be divided into 3 groups: RTSP, MMS and iPhone. The available content lines are as follows:
2User-Agent is a string describing the browser and the device which the request is sent from.
1.3. Goal 8 3gpLow Streamed over RTSP using DSS
3gpMedium - ” - 3gpHigh - ” -
Asf (Windows) Streamed over MMS using Windows Media Services Mp4 (iPhone) Progressive Download using Apache/IIS
For a device to belong to the 3gpHigh content line it has to fulfill the following require- ments:
• Screen width ≥ 240 px
• Support for H.264 Basic Profile 1.13
This can however be manually overridden for a specific device if it’s known that it supports the 3gpHigh content line, but the values in the DDRs does not agree.
1.2.10 Toolsteps
For the various Content Lines the videos will be encoded to different formats. Some Content Lines might require multiple tools to produce a working video. This is solved by specifying multiple tools which will be executed consecutively. An example would be to encode a file with FFmpeg and afterwards execute MP4Box to hint4 the file, thus making it possible to progressively download it.
1.3 Goal
The objectives of this project is to find a solution which will find the approximated bandwidth for as many devices as possible and to integrate this solution with C4M. For the devices for which the bandwidth can’t be determined, C4M will fallback to the quality which would have been chosen without this modification.
The integration with C4M will be done with a branched version of the 4.0 version of C4M. The reason behind this is twofold. Some parts of the solution will require features only available in this version. Secondly, if it were to be implemented to the current 3.1 version of C4M it would require porting to work with the new version if it were to be implemented.
3This information is not specified in any headers nor User-Agent Profile, it’s only acquired by external DDRs
4Hinting is the process of adding a track which contains information on how to package media data for network transport.
1.4. Delimitations 9
1.4 Delimitations
The thesis itself does not mean to conclude anything regarding the codecs and encoding parameters to be used (this would be a thesis subject by itself), merely to find information that will help making decision about which pre-encoded video-file to point to. The deliverables at the end of this thesis will not provide a complete solution that will be ready to take into use, but rather an example implementation of how it might work.
C HAPTER 2 Problem
2.1 Technology Analysis
To sum up what’s been discussed in the introduction, the problem at hand is to find and implement a solution to obtaining the appropriate bit-rate for any mobile device.
2.1.1 Switching Definitions
There are a few different ways to categorize how a switch is made, these are:
Pre switching A switch is made by C4M before the streaming starts.
Stream switching The streaming server does a switch while streaming to the client.
User switching The user makes a selection about which file to play.
Client switching The client makes the switch based on the information it knows about the environment. Used by Smil and QuickTime Reference Movie.
User switching is the most common among mobile websites today. It is also quite common on the desktop web, eg. you can choose between low, medium and high quali- ty/bandwidth.
2.1.2 Decoding Capacity
As the calculation power of a mobile device is limited, it might not have the resources necessary to decode a file with a high bit-rate. This is especially the case when a cpu demanding codec, such as H.264, is used. Though H.264 increases the quality significantly compared to a movie encoded with H.263 at the same bit-rate, the preferred choice might be H.263 due to lack of cpu power. This is an aspect that also should be considered when performing the switch.
10
2.1. Technology Analysis 11
2.1.3 Delivery Method
There are a few alternatives to consider when delivering video to mobile devices, as different platforms supports different protocols.
RTSP
The protocol RTSP is the standard streaming method for mobile devices. It’s based on HTTP and thus offers a similar syntax. In contrast to HTTP it’s stateful. To make an RTSP stream available one would require a streaming server with support for RTSP.
Progressive Download
Progressive download is simply a HTTP GET request to a web server; apache, IIS etc.
The server responds by starting to push out the requested file, and if the client supports progressive download it can start playing the content while downloading the rest of the file. To be able to view the file while it’s downloaded it has to be hinted. This is how the trailers at http://trailers.apple.com are served. There are some devices which supports progressive download, the iPhone foremost but also Android devices.
RTSP vs Progressive Download
As discussed, progressive download utilize HTTP for serving files, this allows for existing cache servers around the Internet to cache these files. This may decrease the latency for the end user. However the real advantage is for major content providers using one of the major Content Delivery Networks (CDN), since cacheing might reduce costs as this minimizes the traffic.[6]
In the discussion of bandwidth utilization one can also argue in benefit of RTSP. If you would pause a file streamed through RTSP the stream will only continue buffer for a couple of seconds in contrast to when a progressive downloading is paused, then the whole file would continue to download. If the user then would stop the playback, the downloading of the complete file would have been unnecessary. From a user perspective the progressive download is however an advantage in this situation since it would enable the user to download the whole file while paused, and watch it later on even if the network access has been lost.
There is an ongoing discussion whether RTSP is preferred when it’s important to
”protect” the content. However, the logic behind this reasoning is a bit flawed. RTSP does not encode the file or apply DRM in any way. DRM can be applied to both progressive download and RTSP streaming. Protecting the data while delivering it can be done by using HTTPS instead of HTTP for progressive download. However, it is possible that the progressively downloaded file can be retrieved after watching it - it has been downloaded in it’s actual file format. RTSP however, reassembles and repackages
2.2. Approach 12 the file when it’s transferred. Which makes it harder to reassemble it to the original file format - but it is still possible [7][8].
”Since no special servers are required, HTTP streaming is seen as less expensive than traditional streaming, though in some cases it may be less secure or reliable.”[9]
An issue with RTSP is that it uses its own ports for communication between the server and client. This traffic might not be allowed to pass through a strict firewall and the users access to the content may be blocked. This is most often not the case for HTTP which is generally allowed to pass through. There are some operators which effectively blocks RTSP traffic by blocking certain ports. This is the case with Vodafone in Germany.
RTMP
RTMP is a protocol developed by Adobe and is used to stream video and audio in flash format. The support for flash in mobile devices are limited to Flash Lite which is a lightweight version of Flash. The tests which have been performed on some of the few devices which has flash support in their browser have not been satisfactory. The behavior of the flash player used to display the video has not worked as intended, e.g. displaying the video in full screen does not work.
Since Flash support are practically non-existing, RTMP nor Flash will be covered.
MMS
Microsoft’s own proprietary streaming protocol is called MMS. This protocol is depre- cated in favor of RTSP, though the prefix mms:// is still being used to increase backwards compatibility. [10]
2.2 Approach
There are several different ways to find information about a mobile device. The essential in this thesis is to find a solution which covers as many of the devices out there as possibly. To conquer this problem a combination of multiple techniques is researched.
The following sections cover the ones which were considered.
2.2.1 QuickTime Reference Movie - QRM
This is a method currently only known to work with the iPhone, but it could work with other devices which implements support for files of the type ”mov”. It will let you define a mov-file containing a set of movies, possibly encoded with different bit-rates.
Each of these movies is associated with a rule defining the bandwidth needed to view
2.2. Approach 13 it. Detecting the available bandwidth is done by the phone’s software and then it will display the appropriate movie.
2.2.2 SMIL
This is a technique which can be used in a way similar to QuickTime Reference Movie (QRM). It consists of a descriptor file, which describes a set of movies of different bit-rate.
As in QRM, each of these movies is matched with a bit-rate. The device then determines which file it’s capable of playing.
<s w i t c h >
< r e f s r c =” s l i d e s 1 . 3 gp ” s y s t e m B i t r a t e =”80000”/>
< r e f s r c =” s l i d e s 2 . 3 gp ” s y s t e m B i t r a t e =”20000”/>
</s w i t c h >
Listing 2.1: Smil example
2.2.3 Headers
The C4M platform makes its decisions from information gathered, amongst other, from the HTTP headers the device provides. There are some non-standard headers that pro- vide information regarding the available bandwidth of the device, such as the ”X-Nokia- MusicShop-Bearer ” header. This header will report whether the device in question are connected via GPRS, 3G or WIFI.
2.2.4 User-Agent Profile
The majority of mobile phones provides the X-WAP-USERAGENT header. This header contains a URL to a document. This document, the User-Agent Profile, contains technical specifications for the device in xml format.
2.2.5 Brute Force Test
A not so elegant solution would be to test the actual bandwidth available. This could be done by downloading an image and measure the time it takes for the client to download the image.
2.2.6 RTSP proxy/server
There is information about the available bandwidth in the headers sent by the RTSP protocol. To be able to use these headers there are a few different approaches.
One would be to construct a simple RTSP server which parses these headers and then redirect the device to a movie of appropriate bit-rate, on the ”real” streaming server.
2.3. Technology Discussion 14 Another approach would be to have a proxy which listens to the information sent between the client and the server. And based on the values of certain headers, it could rewrite the request to reference a different movie. The third solution would be to implement this directly in the streaming server itself.
All of these are interesting solutions. Being able to use these headers would make this one of the most interesting solutions, as it could support many of the devices which have support for RTSP - which is the vast majority. There are some exceptions though, such as the iPhone, which only supports progressive download.
2.2.7 Windows
There are many specific features which only works when streaming from a Windows Media Server to a device with the Windows Media Player. The technique chosen to investigate is Multi Bit Rate ASF (MBR ASF). This is a way of encoding a movie containing multiple versions of the same movie - but with different bit rates.
2.3 Technology Discussion
To be able to improve the quality for as many devices as possible, technologies were chosen in such way that they would complement each other. The QuickTime Reference Movie is aimed solely at the iPhone, ensuring the quality for this specific device. MBR ASF is especially for devices running Windows and the RTSP server is for all other devices. The headers and user-agent profile is not specific for a certain device group but rather it will complete the RTSP server solution, as will the brute force test.
There are of course other approaches; looking up the IP address of a device and lookup if it belongs to a address reserved for 3G connections or a publicly available Wi-Fi, or one could investigate how to work with operators in a way where they would add a header containing the network quality. However, these approaches is rather complex to maintain on a global level with new operators for each countries. It would take time to make deals with new operators as well as the additional cost for each new country.
Researching new technologies has been an ongoing process. New technologies has emerged and existing technologies which haven’t been known, has been stumbled upon.
When encountering these technologies it had to be determined whether it seemed to provide any complements to the existing technologies to be researched - or to determine that it did not. The integration with C4M also had to be taken into account, not making the solution too complex and whether it was all possible to integrate with C4M.
C HAPTER 3 Requirements
3.1 Mobile Devices
Determining the spectrum of mobile devices which will be covered by a certain technique will be done by looking up the required capabilities in Mobizofts database. Thus giving an approximation on how well a technique will cover actual devices on the market.
3.1.1 Database validity/representation
Mobizofts technique does not, in contrast to other mobile switchers, rely on having a large database with the capabilities of mobile devices. So from time-to-time the database is emptied. Thus the database represents which devices people are currently using when surfing the web. The definition of mobile device in context of the data being used, is whether the C4M platform perceives the device as such device.
The validity, in this context, is high due to the fact that the goal of this thesis is to enhance the video functionality of the C4M platform. This makes the data acquired from actual requests to the C4M platform, optimal. The dump contained data from the raw data table. This table contains the headers provided in every request that has been determined to be a mobile device.
The data used in all test cases are taken from an SQL Dump1 made 2009-08-05 from a C4M installation in Amazons EC2 Cloud. The data in this dump contains 4591 unique mobile devices, of which 4072 provided a User-Agent Profile.
A unique device in the eyes of C4M, is a unique chash. As explained, a device can generate multiple chash by altering its accepts for different requests.
To gather information about the different attributes available in the user-agent profile a parser was constructed. The source data was the above mentioned dump.
Worth noting is that the data found in this SQL dump is mainly built up from traffic
1A SQL Dump is a collection of data which has been exported from a SQL database.
15
3.2. Performance issues 16 generated in Sweden. It’s possible that operators in other countries might add proprietary headers which could further assist in finding the current bandwidth.
3.2 Performance issues
As earlier discussed, the underlying purpose of this thesis is to enhance the perceived user experience. When using a technique which, from the time the user access a link to when the device initiate the playback of the video, shall determine which video to play, performance is important.
3.3 Correctness
Since this project will affect which video is chosen, it is utterly important that the correct2 video is chosen. C4M relies on data provided by the mobile device and at second hand by external device repositories. This might lead to decisions being made based on faulty data.
To ensure that this project does not perform a switch to a video with a too high bit rate, when the data is correct, a conservative approach is taken. It’s simply better to provide a video of lower quality than a video which will not play.
2In this context, a correct video is a video which will be play on the mobile device and which will not provide any less quality than C4M would deliver without this modification
C HAPTER 4 Results
Since the solution consists of many technologies to be able to support as many devices as possible, these technologies will be presented one by one. In section 4.4.1 there is a complete explanation of how these technologies were brought together to provide a wide device coverage.
4.1 Overview
The chosen approach is based on creating one main capability namely connection and populate it with relevant values. Then this capability (and a few others) will be the foundation on which the switch will be based. The only switch that actually will be made, is when the user requests the high contentline and the connection capability has been set to a value which can cope with a higher bit-rate. If this is the case, the user will be switched from high to a new contentline, the ultra contentline. The ultra contentline has a bit-rate of 192 kbps.
4.2 Techniques Evaluated
To cover as much of the market as possible one can divide the market into chunks, supporting different technologies:
• Windows - Requires MMS streaming1
• iPhone - Progressive Downloading of mp4
• RTSP - Covering the rest
1Not all windows devices are limited to MMS/ASF. Some actually supports RTSP and the H.264 codec
17
4.2. Techniques Evaluated 18 Of course there are sub groups within these groups but these are the major groupings that can be made.
4.2.1 Multiple Bit Rate (MBR) ASF
Microsoft implemented a multi-bit-rate encoding technique in their Windows Media En- coder 9 (WME9 ). This works by encoding a single clip into a single file containing clips with different bit-rates. The server and client then determine the current available bandwidth and choose the stream with most appropriate bit-rate.
This is supported by mobile devices with Windows Mobile 6.0, since it has support for Microsoft Windows Media Video codec versions 7, 8, and 9 [11]. It is also supported by Windows Mobile 5.0, since this is the operating system which the Qtek 9000 is using, and it works on that device. Actually it also supports the Windows Mobile 2003 OS, since it has Windows Media Player 9 Series or higher. [12]
It works on all tested Windows Mobile Phones; HTC p3300, HTC s710 and Qtek 9000.
These are quite old phones (the Qtek 9000 was released in 2005[13]), so most Windows based devices that access C4M today, should be able to support this.
To maximize compatibility the v8 video codec is used [14]. The Windows Media Video 9 codec is only compatible with Windows Media Player 9 Series or higher [15], which is only supported by Windows Mobile 2003 or newer.
Since the converter used in the current environment at Mobizoft is FFmpeg, which has no support for wm3 encoding, an alternate tool such as WME9 had to be used.
Encoding via command-line in Windows Media Encoder 9 can be done in two ways:
either by specifying all parameters at once or, as was done in this case, use a predefined session and override some parameters (such as input and output). Thus, a session was created and the following command was executed to perform the transcoding:
c s c r i p t . e x e wmcmd . vbs
−wme C: \ M o b i z o f t \ e x j o b b \ windows \ m b r s e s s i o n 2 . wme
−i n p u t C: \ M o b i z o f t \ f i l m e r \ s h r e k . a v i
−output C: \ M o b i z o f t \ e x j o b b \ windows \ commandline2 .wmv Listing 4.1: Convert using command-line
One issue that has to be considered is that WME9 does not handle as many codecs and containers as FFmpeg. Thus, the input file had to be converted to a format that WME9 can decode: WMA, WMV, ASF, AVI, MPG [16]. The following config was used to create the MBR ASF video:
4.2. Techniques Evaluated 19
<r u l e name=”Use G e s t a l t ” d e s c r i p t i o n =”” o r d i n a l =”0”>
<c o n d i t i o n cap=” u s e g e s t a l t ” t y p e=” s t r i n g ” operand=”
c o n t a i n s ”> t r u e </ c o n d i t i o n >
<r e s u l t >
< c a p a b i l i t y name=” s t e p s ” s o u r c e =” d i r e c t ” t y p e
=” l i s t ” key=”ffmpegAVI ” o p e r a t i o n =”add”/>
< c a p a b i l i t y name=” s t e p s ” s o u r c e =” d i r e c t ” t y p e
=” l i s t ” key=”ASFMBR” o p e r a t i o n =”add”/>
</ r e s u l t >
</ r u l e >
Listing 4.2: MBR ASF Toolsteps
< t o o l s t e p name=”ASFMBR” o r d i n a l =”0”>
<p a r a m e t e r name=”i n p u t ”> o r i g i n a l </parameter>
<p a r a m e t e r name=” t o o l ”> c s c r i p t </parameter>
<p a r a m e t e r name=”codecparams ” key =”4:3”>
wmcmd . vbs −wme m b r s e s s i o n 4 3 . wme
</parameter>
<p a r a m e t e r name=”codecparams ” key =”16:9” >
wmcmd . vbs −wme m b r s e s s i o n 1 6 9 . wme
</parameter>
<p a r a m e t e r name=”o u t p u t”> windows . a s f </parameter>
</ t o o l s t e p >
Listing 4.3: MBR ASF Toolstep Definition
However, not every Windows based device will be switched to the MBR ASF video.
An increasing number of Windows based devices actually supports H.264 in the 3gp container. These devices will get a 3gp file instead. Of course these devices would be able to play a H.264 encoded asf as well, though since a H.264 version already is available in 3gp there is no need to encode to an additional format. Based on the data in the SQL dump, 193 out of 238 Windows based devices will get the MBR ASF video, and the other will get a 3gp file, and are thus eligible to be switched based on other values.
4.2.2 Intelligent Streaming
In addition to MBR ASF Microsoft also offers a technology dubbed Intelligent Streaming.
This feature demands the content to be encoded as MBR ASF but adds additional features:
1. As in MBR ASF the appropriate bit rate is chosen. [17]
2. During playback, the server constantly monitors the network to observe fluctuations in the bandwidth and switches to a stream with a different bit rate - if deemed necessary. [17]
4.2. Techniques Evaluated 20 3. If the bandwidth drops even lower than the lowest bit rate stream the server starts stream thinning - that is dropping of frames. If this is not enough the server stops the transmission of video and only delivers audio. [17]
When bandwidth is at its best, the server employs the first strategy. As conditions worsen, the server tries each strategy in the previous list of options one by one until the bit rate is optimized for the current bandwidth. [17]
This is enabled by default in Windows Media Services.
4.2.3 SMIL
”SMIL is typically used for ”rich media”/multimedia presentations which integrate streaming audio and video with images, text or any other media type”[18]
SMIL provides a switch tag which makes it possible to select different media files based on a specific attribute. The attribute interesting in this case is the systemBitrate [19].
The specification doesn’t specify how this value is determined, it can be a setting in the device and not dynamic.
After testing this hypothesis on a few Nokia devices with Real-Player (which claims to support SMIL 2.0) and on a few Windows terminals as well as QuickTime and Real Player on PC, a few conclusions could be made:
First of all, the mobile clients browser were not setup to handle the MIME-type ap- plication/smil thus, making it impossible to directly open the file from the browser. In the Real Player case, it is said to be solved by linking to the SMIL file within a .RAM file which in turn is pointed to within a regular href within a web page [20]. However, testing this in every possible way, the SMIL file was not able to be interpreted by any device. In the Windows devices it was discovered that those did not support SMIL per se, but rather has a SMIL based syntax in their playlists; e.g. .WSX playlists. These playlists, although based on SMIL, does not provide the same functionality. They have added a few of their own attributes[21] as well as removed a few - systemBitrate for one.
Thus, making it impossible to do a switch based on systemBitrate in any Windows based device (if it makes use of the Windows Media Player).
Since a functional solution based on SMIL was not obtained, SMIL could not be imple- mented as a complement neither for Real Player enabled devices nor Windows devices.
4.2.4 RTSP
RTSP Bandwidth header
The Bandwidth header is an approximation of the available bandwidth, measured in bits per second. According to the specification it can change according to the network conditions[22], although this has not been observed in any of the clients tested, rather it seems to be an estimated value matched to the current connection; 3G, Wi-Fi etc.
4.2. Techniques Evaluated 21 DESCRIBE r t s p : / / 2 1 3 . 8 8 . 2 4 9 . 1 2 1 : 1 1 1 1 / t e s t 3 g p l o w . 3 gp RTSP/ 1 . 0
CSeq : 2
Accept : a p p l i c a t i o n / sdp
User−Agent : RealMedia P l a y e r HelixDNAClient / 1 0 . 0 . 0 . 6 8 3 9 ( S60 HX c v s c a y s 2 1 0 2 0 0 9 0 3 3 1 : 2 2 : 0 0 : 0 0 u t c 31 Mar 2009 4 : 0 0 )
R e q u i r e : com . r e a l . r e t a i n −e n t i t y −f o r −s e t u p
x−wap− p r o f i l e : ” h t t p : / / nds1 . nds . n o k i a . com/ u a p r o f / Nokia5800d −1r100 −3G . xml ”
Bandwidth : 3999000 Language : en−US RegionData : 0
C l i e n t I D : Symbian 6 . 1 1 0 . 0 . 0 . 6 8 3 9 play32 RN01 EN ARM No−FPU GUID : 00000000 −0000 −0000 −0000 −000000000000
SupportsMaximumASMBandwidth : 1
Listing 4.4: Example of Bandwidth header from Nokia 5800
As stated in the RFC[22] this header is optional. The same approach is taken in the PSS specification:
”PSS servers and clients should implement the Bandwidth header field.” [23]
SetDeliveryBandwidth
During the testing of the RTSP Redirect Server this header was discovered, as seen in the extract below of the RTSP communication between the server and a Nokia 5800.
SET PARAMETER r t s p : / / 2 1 3 . 8 8 . 2 4 9 . 1 2 1 : 1 1 1 1 / RTSP/ 1 . 0 CSeq : 6
S e t D e l i v e r y B a n d w i d t h : Bandwidth =0; BackOff=0 S e s s i o n : 123458
Listing 4.5: The SetDeliveryBandwidth header
There is no trace of this header in the DSS source. After some research it was found that this is most probably a Real Player specific header (as used by the Nokia 5800 and almost all Nokias). It has to do with the SureStream Rate Adaption [4][24]. Since no specification could be found on how this is implemented, this was not considered in the final solution.
4.2. Techniques Evaluated 22 3GPP Link-Char
The Link-Char header contains, except for an url to a video, up to 3 parameters that reveals information about the network condition:
• GBW - the link’s guaranteed bit-rate in kilobits per second.[23]
• MBW - the link’s maximum bit-rate in kilobits per second.[23]
• MTD - the link’s maximum transfer delay in milliseconds.[23]
However, this information is only valid for the wireless link between the client and it’s base station [23]. Hence there could be network congestion between the base station and the streaming server which will not be reflected in these values.
PLAY r t s p : / / 2 1 3 . 8 8 . 2 4 9 . 1 2 1 : 1 1 1 1 / t e s t . 3 gp RTSP/ 1 . 0 CSeq : 4
S u p p o r t e d : com . pv . s e r v e r p l a y l i s t , method . e o s
User−Agent : S o n y E r i c s s o n / K850i / R1FA035 prg12004400 GENERIC SO Range : npt=now−
S e s s i o n : 123458
3GPP−Link−Char : u r l =” r t s p : / / 2 1 3 . 8 8 . 2 4 9 . 1 2 1 : 1 1 1 1 / t e s t . 3 gp ” ; MBW
=1024000
Listing 4.6: RTSP Link-Char captioned from a SonyEricsson k850i
As defined in PSS6 (not PSS5) one can find if the device supports the header in the User-Agent profile.[23]
<ThreeGPPLinkChar>Yes</ThreeGPPLinkChar> \ c i t e {PSS6}
Listing 4.7: The ThreeGPPLinkChar attribute in the User-Agent profile
Not all devices conforms to this. The SonyEricsson k850i does not have the Link-Char defined in it’s User-Agent profile, but it still sends the Link-Char header. Nokia on the other hand, has an identifier called pss6:LinkChar in their User-Agent profiles , which seems to be the same. [25]
RTSP Redirect Server
The purpose of having an additional RTSP server were to read headers from the client and then redirect the client to the real streaming server and pointing it to an appropriate file depending on the headers which were parsed. The server was built in Java and implemented the basic functions that are required by an RTSP 1.0 server [22].
The targeted headers were the ones stated above; bandwidth and Link-Char. The bandwidth header is an optional header and can be found in any request sent from the
4.2. Techniques Evaluated 23 client [22], although it were only found either in the clients DESCRIBE or it’s PLAY request. The Link-Char is specified to be included in either of SETUP, PLAY, OPTIONS, or SET PARAMETER requests[23], although it were only found in PLAY requests. So why is it important which request the header is bundled in? The answer lies in how RTSP implementations differ from each other.
”RTSP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable.” [22]
There are three ways to redirect a client to other content: send a REDIRECT request or send either a 301 Moved Permanenty or a 302 Moved Temporarily. Neither of these three are are required to be implemented by a client [22]. If the client would not be able to understand any one of these, a TEARDOWN would have to be sent, thus denying the client to see the video at all.
A problem with the REDIRECT is the ambiguous definition in which state it can be sent - as pointed out by the mmusic mailing list [26]. Since this was only a very limited implementation, a stream can not be initiated and thus the REDIRECT can’t be issued after the PLAY request has been received, thus making this implementation unable to handle the Link-Char header which was only found in the PLAY request.
Another concern regarding this implementation is the additional delay that is added.
The client has to first lookup the redirect server and communicate with it until it redirects it to the streaming server, which then has to be looked up and a new session has to be established. Tests has proven that the delay is only around 1 second. It takes a SE P1i 10,5 seconds to start the media player and begin playback with the redirect server and 9,5 seconds without it. This delay is so small that the user would not notice any different, and thus it can be disregarded.
Darwin Streaming Server Modification
When the problem with redirecting the device was encountered, a new alternative emerged: modifying the source of Darwin. The motivation behind this was how the problem defined itself; it was the redirect to DSS that was the problem - not getting the information about the device. The modification would have to look at the RTSP headers received from the client and make a decision regarding which movie to play based on the information received.
The purpose of the modification were to parse the bandwidth and the 3GPP-Link-Char headers. When this information was acquired, a decision on the bit-rate were to be made.
This decision would make Darwin deliver a movie of an appropriate bit-rate.
It was researched how to proceed and if it was possible to do anything within the time frame. Basically, the only information at hand was the source code of Darwin. It was found that Darwin already parses the required headers, so the problem came down to be able to tell Darwin to use another file based on the values of these headers, which seemed
4.2. Techniques Evaluated 24 feasible.
The solution examines the bandwidth header and changes the filename in the clients request to refer to different file. To be able to distinguish between different versions of a movie, C4M uses a naming convention which appends quality.3gp after the filename, eg. ultra.3gp for the best quality version. The modification of DSS points to the ultra version if the client requests the high version and a few requirements are fulfilled.
The 3GPP-Link-Char header, on the other hand, could not be handled in this way because of the way RTSP handles states and when these headers are sent. Since the bandwidth header is sent in the DESCRIBE request, before a session is setup, the file has not yet been opened and processed, which allowed for choosing to open another file. The 3GPP-Link-Char header can be sent as late as when the client issues a PLAY request.
When the PLAY request is received, the file and the session are already setup, and thus it became complex to tell Darwin to use another file then the one that is already setup. This could be done by opening a new file and not informing the client it’s playing another file.
This however, would have been in conflict with the RTSP specification which requires the movie to be described, by an SDP or similar, and this can’t be done after a PLAY request has been received. [22]
Three configuration parameters where added to the DSS config: the names of the ultra and high contentlines as well as the threshold value that determines which of the two contentlines are used.
Since DSS is licenced under APSL - Apple Public Source Licence[27] - these modifica- tions can be done and be deployed in the commercial domain, as long as the changes are made publicly available.
4.2.5 User-Agent Profile
The User-Agent Profiles (UAP) can be quite large, typically around 30kB, and thus can’t be sent with every HTTP request. Therefore the UAP’s are located on an external server and only a URL to this location is provided. This makes it impossible for a UAP to contain dynamic information - current available bit-rate for instance. A work around for this problem is to provide multiple UAP’s for a single device and to change the URL depending on the current conditions. This is done to be able to use different values for the CurrentBearerService attribute.
CurrentBearerService
This attribute represents the network-type the connection was setup on. Although this value is deprecated since UAProfile 2.0 [28] there are still many devices which implements it. A list of possible values can be found in Appendix B. When testing this value, it was found that not all devices abide by these values, but provide variants and in some cases, values that are not at all related to the ones specified.
As seen in Appendix G, different manufacturers reports different bearer for the same
4.2. Techniques Evaluated 25 bearer type (EDGE vs GSM EDGE IPV4 for instance), and that there are many kinds of bearers out there. As seen in Appendix G these bearer types had to be mapped against the corresponding technology generation they belong to; 2G, 3G etc.
To use the CurrentBearerService attribute, a rule had to be set up. There is no need for this rule to be dynamic to eliminate the cache behavior since the URL to the User-Agent Profile is a part of the chash, and the User-Agent Profile is a static resource - it will not change. In Appendix D are the rules that makes it possible to group devices in different groups with different network characteristics. The rules act by creating a new capability, connection, which will contain the type of network the device is currently connected to.
These rules can be described as follows:
1. The capability is first set as UNDETECTED, this will cover all devices that doesn’t have the CurrentBearerService attribute.
2. Then it will check if the value, if provided, matches either 2G, 2.75G, 3G, 3.5G, 4G or WLAN and if it does, set the capability to the matched network.
3. The last rule will set the capability to UNKNOWN if it has the CurrentBearerSer- vice attribute AND it doesn’t match any of the networks.
If a device is set to UNKNOWN it should be investigated which kind of network type it is, add this value to a network type and then reset the rules so that it will matched to the correct network next time.
The motivation behind the fine granularity in the groupings of different network con- nection - 3G, WLAN etc. - are to make it easier to add additional rules; e.g. based only on if a device is on 2.75G. In the code using these groups, it will only check whether the connection is of 3G type or faster. It does not care whether the device is connected via a 3G or 3.5G connection. It will also provide better statistics.
SupportedBearers
The SupportedBearers attribute lists all the network-types that can be setup on the device. This attribute can be useful by noticing which bearers that are not listed. If a 3G or Wi-Fi bearer is not listed, then it can be assumed that this device can not use a bit-rate equivalent of those used for those connections. On the other hand, if it contains a 3G bearer as well as a 2G bearer it can not be assumed that it is connected with the 3G bearer, it could just as likely be using the 2G bearer.
The tables found in Appendix G contain values found when parsing data from the SQL dump.
This attribute is used as a limit. If a device is found not to have support for a bearer greater than 2.75G it will not get the best video quality - even if other attributes says it should.
4.2. Techniques Evaluated 26 Names of User-Agent Profiles
As mentioned previously, a device can have multiple static User-Agent Profiles and only change which one is referenced. The SonyEricsson W880i for instance, provides two different UAP’s:
h t t p : / / wap . s o n y e r i c s s o n . com/ UAprof /W880iR201−3G. xml h t t p : / / wap . s o n y e r i c s s o n . com/ UAprof /W880iR201 . xml
Listing 4.8: SonyEricsson W880i UAP’s
What can be observed is how the ”-3G” is added and provides a hint on the type of connection of the client. These suffixes are quite common: edge/3G/gprs. The only difference between the two UAP’s provided by the SE W880i are some differences in the MMS accept and that the ”-3G” version provides the following tag:
<p r f : C u r r e n t B e a r e r S e r v i c e >3GPP WCDMA IPV4</ p r f : C u r r e n t B e a r e r S e r v i c e >
Listing 4.9: CurrentBearerService tag
Some vendors like Nokia, at least in their 5800 model, reports the same CurrentBear- erService regardless of network type but instead modifies the list with SupportedBearers and doesn’t include bearers such as 3G when a connection is made via a 2G network.
This is however not a general principle applied by Nokia, so it’s quite hard to take ad- vantage of. But the 3G User-Agent Profile for the Nokia 5800 has ”3G.” appended to their names. So even tough it don’t report a valid value for the CurrentBearerService attribute, it can be assumed they have a network connection capable of at least 3G bit rates. Additionally, SonyEricsson has recently begun to append HS to the names of User-Agent Profiles for models which has support for HSDPA. [29]
The rule which determines if a User-Agent Profile URL contains 3G or HS overrides values of 2G, 2.75G and 3G carriers found in CurrentBearerService. The rule applied for the names of the User-Agent Profile can be found in Appendix D under the 3G rule.
This rule will not set the connection capability to 3G or HS for any device which do not support 3G or HS, except for one single exception, based on the data from the cloud dump. The exception is the following device:
h t t p : / / nds1 . nds . n o k i a . com/ u a p r o f / N6630r100−VF3G . xml Listing 4.10: Nokia 6630 User-Agent Profile
This device reports 3GPP GPRS IPV4 as CurrentBearerService value, which cor- responds to gprs - only 2G. The highest possible value reported by SupportedBearers is EDGE, which corresponds to 2.75G. Although it is however capable of 3G [30]. Since this is Nokias first 3G capable device, it might explain the errors in the UAP [31].
4.2. Techniques Evaluated 27 However, this rule sets the connection capability to 3G for 7 devices, which does not report a CurrentBearerService value or reports the wrong value. These devices can be found in Appendix I.
The solution to this problem is either to add an exception to this specific device (Nokia 6630), but it’s certainly not impossible that there will be other devices which will get the wrong value from this rule. Therefore the benefits of this has to be weighted against the drawbacks. The ratio is 8:1 when comparing the number of devices that will gain from this rule against the ones which will suffer, and exceptions can be added when a device is determined to have gotten the wrong value. Since the drawback from getting a too high value will be that the device will get a higher bit-rate, which it probably will be able to play but will have to buffer for a longer time, the benefits outweighs the drawbacks, thus this rule will be kept. In addition an exception to the Nokia 6630 was added.
SupportedX
There is also a couple of attributes which provides the same information as the Supported- Bearers attribute but as a separate attribute for each; SupportedWiFi, SupportedUMTS etc. Although these are specified, they doesn’t seem to be used at all. None of the 4591 devices in the SQL Dump had any of these headers.
VideoDecodingByteRate
This attribute defines the peak decoding byte rate the client will be able to support, in bytes per second. The values found in the dump can be seen in table 1.
Byte rate in bytes per second Number of occurrences
48000 108
38400 13
16384 15
96000 5
12000 2
16000 164
0 66
8000 26
Table 1: A list of VideoDecodingByteRate attributes found in the database
According to Annex G in PSS5, 8000 is the default peak decoding byte rate for the mandatory video codec profile and level - H.263 Profile 0 Level 10 for PSS5. For PSS6 the default rate is 16000 for the new mandatory video codec profile: H.263 Profile 0 Level 45.
If the value is set to 0 it should be interpreted as the default value for the corresponding
4.2. Techniques Evaluated 28 PSS profile [23].
The capability which was added can be found in Appendix F.
This is the only capability which was handled in a non-conservative way. If the capa- bility was provided it was used, if not, it was interpeted that the device does not have a VideoDecodingByteRate limit. A more in depth description of how this capability came to use, can be found in section 4.4.1.
4.2.6 pss6:MediaAlternatives
This headers are used for signaling the support of the SDP attributes ”alt”, ”alt-default- id”, and ”altgroup”. These attributes are used to provide the user with an alternative source based on the language and the bandwidth modifiers AS and TIAS.
Only 44 phones out of 4591 had support for this attribute. Due to time constraints and limited use of this attribute, no measures were taken to use it.
4.2.7 ThreeGPFileFormat component
The ThreeGPFileFormat component lists 3GP file brand support. This is interesting because some of these profiles specifies the support for progressive download.
The brands specified by 3GPP are somewhat limited - it only specifies progressive download of .H264 files if they use AMR as audio codec, in contrast to AAC which is used by Mobizoft. Although, in some cases it may be worth another format or to use another audio codec, just to be able to offer progressive download of 3gp files. The most prominent case is when RTSP is blocked - by an operator or a firewall - then it is possible to offer the end-user a ”play” link, even if it uses progressive download instead of actual streaming.
Due to limited amount of time and that this can be regarded as not within the subject of this thesis, this was not researched any further.
4.2.8 3GPP-Adaptation-Support
The client uses this header to signal the support of bit-rate adaption. If both the client and server supports this feature additional information such as buffer size shall be re- ported continuously during playback. In DSS this is only implemented for adapting the bit-rate during the playback.
4.2.9 X-Headers
These are non-standard HTTP headers of the form ”X-headername”. They can be added at the operators gateway, when passing through a proxy on the way or by the device itself. This implies that these headers can vary from country to country and operator to
4.2. Techniques Evaluated 29 operator. The source data used are mostly gathered from connections made in Sweden, and are probably not representative for other countries.
A list of X-headers found in the SQL dump can be seen in Appendix C. Of all these headers, only a few have been found to contain any valuable information regarding the clients connection:
Header Values Found No. of devices with header
X-Nokia-MusicShop-Bearer GPRS/3G, WLAN 72
X-Nokia-BEARER CSD, GPRS 5
X-Network-info CSD, GPRS, TCP 6
X-H3G-NETWORK-QUALITY 3G 2
Table 2: The X-Headers found in the SQL Dump, their different values and number of occur- rences.
Total number of devices in the database were 4591, thus, X-Headers will not cover a huge part of the field, but anything that contributes is of value.
The most interesting header of these is the X-Nokia-MusicShop-Bearer, since it’s the most common one. Although, the drawback of that specific header is that it groups 3G and GPRS together, so one can only make a switch based on this header when the user is connected to Wi-Fi.
This brought forth the following rules:
< c a p a b i l i t y name=” n o k i a m u s i c b e a r e r ” s o u r c e =”h e a d e r ” t y p e=” s t r i n g ” key=”x−n o k i a −musicshop−b e a r e r ” o p e r a t i o n =”temporary ”/>
<r u l e name=”C u r r e n t c o n n e c t i o n WLAN” d e s c r i p t i o n =”” o r d i n a l =”1”>
<c o n d i t i o n cap=” n o k i a m u s i c b e a r e r ” t y p e=” s t r i n g ” operand=”
c o n t a i n s ”> WLAN </ c o n d i t i o n >
<r e s u l t >
< c a p a b i l i t y name=” c o n n e c t i o n ” s o u r c e =” d i r e c t ” t y p e=”
s t r i n g ” key=”WLAN”/>
</ r e s u l t >
</ r u l e >
Listing 4.11: Rule for X-Nokia-MusicShop-Bearer
4.2. Techniques Evaluated 30
< c a p a b i l i t y name=” n o k i a b e a r e r ” s o u r c e =”h e a d e r ” t y p e=” s t r i n g ” key=”X−
Nokia−BEARER” o p e r a t i o n =”temporary ”/>
<r u l e name=”C u r r e n t c o n n e c t i o n ” d e s c r i p t i o n =”” o r d i n a l =”1”>
<c o n d i t i o n cap=” n o k i a b e a r e r ” t y p e=” s t r i n g ” operand=” c o n t a i n s
”> CSD </ c o n d i t i o n >
<c o n d i t i o n cap=” n o k i a b e a r e r ” t y p e=” s t r i n g ” operand=” c o n t a i n s
”> GPRS </ c o n d i t i o n >
<r e s u l t >
< c a p a b i l i t y name=” c o n n e c t i o n ” s o u r c e =” d i r e c t ” t y p e=”
s t r i n g ” key=”2G”/>
</ r e s u l t >
</ r u l e >
Listing 4.12: Rule for X-Nokia-BEARER
< c a p a b i l i t y name=” n e t w o r k i n f o ” s o u r c e =”h e a d e r ” t y p e=” s t r i n g ” key=”X−
Network−i n f o ” o p e r a t i o n =”temporary ”/>
<r u l e name=”C u r r e n t c o n n e c t i o n ” d e s c r i p t i o n =”” o r d i n a l =”1”>
<c o n d i t i o n cap=” n e t w o r k i n f o ” t y p e=” s t r i n g ” operand=” c o n t a i n s
”> CSD </ c o n d i t i o n >
<c o n d i t i o n cap=” n e t w o r k i n f o ” t y p e=” s t r i n g ” operand=” c o n t a i n s
”> GPRS </ c o n d i t i o n >
<r e s u l t >
< c a p a b i l i t y name=” c o n n e c t i o n ” s o u r c e =” d i r e c t ” t y p e=”
s t r i n g ” key=”2G”/>
</ r e s u l t >
</ r u l e >
Listing 4.13: Rule for X-Network-info
< c a p a b i l i t y name=” h 3 g n e t w o r k q u a l i t y ” s o u r c e =”h e a d e r ” t y p e=” s t r i n g ” key=”X−H3G−NETWORK−QUALITY” o p e r a t i o n =”temporary ”/>
<r u l e name=”C u r r e n t c o n n e c t i o n ” d e s c r i p t i o n =”” o r d i n a l =”1”>
<c o n d i t i o n cap=” h 3 g n e t w o r k q u a l i t y ” t y p e=” s t r i n g ” operand=”
c o n t a i n s ”> 3G </ c o n d i t i o n >
<r e s u l t >
< c a p a b i l i t y name=” c o n n e c t i o n ” s o u r c e =” d i r e c t ” t y p e=”
s t r i n g ” key=”3G”/>
</ r e s u l t >
</ r u l e >
Listing 4.14: Rule for X-H3G-NETWORK-QUALITY
This would work in a similar way which the rules for CurrentBearerService works. It would create the capability connection, if any of the conditions are true, and set it to the corresponding value. The difference between this and the rules for CurrentBearerService
