Abstract
Within the IP Television industry the interest for using solutions based on web technology is strongly increasing. SVG is currently a top requirement from most IPTV operators that want to deliver a rich user experience with a technology that allows customizability and is future proof.
This paper gives a brief introduction to IPTV. It explains the rationale behind using web technologies for IPTV and in particular why SVG is an important part of many IPTV solutions. It describes the ongoing IPTV standardization effort in the OIPF (Open IPTV Forum), and how OIPF include SVG as part of their work.
Finally it addresses some of the missing parts within SVG that are needed to make SVG really useful for IPTV and mentions how Ericsson are working with defining these missing parts.
Table of Contents
IPTV, Internet Protocol Television, is defined as TV (and other multimedia) services delivered over IP based networks. Compared to other methods for delivering TV to the consumers (cable, satellite and traditional radio frequency broadcast) IPTV is still a young technology but it is constantly gaining momentum from TV providers around the world.
There are a number of advantages with IPTV compared to other delivery mechanisms, the main one probably being the possibility of lowering the infrastructure cost; the vast majority of consumers in the developed world have good broadband connectivity today. By reusing the broadband network for TV there are less need to support additional infrastructures, like a cable network. This also has the advantage of letting other players, like traditional telco operators, enter the TV market. Hopefully this increased competition will lead to higher quality in future TV services. Another important advantage with IPTV, compared to some of the other delivery mechanisms, is the availability of a back-channel. This means that in parallel with the TV data going from the provider to the consumer other data may go from the consumer to the provider. This opens up for new types of services where the consumer is more involved in the TV experience than traditionally has been the case.
So how does IPTV work? Leaving all the server side and networking parts aside, which is where it can be complicated, and just focusing on the client side (where SVG plays a role) it’s all quite simple. For the consumer IPTV is presented with a normal TV in conjunction with a set-top box (STB). The STB is connected with the IP network on one side and with the TV on the other side. The STB is responsible for decoding the video streams as well as rendering the user interface (GUI) on the TV. The user controls the GUI with a remote control that is paired with the STB. Since the TV normally also have a remote control and its own native GUI, many features are duplicated between the TV GUI and the STB GUI. The look and feel of these duplicated features can be completely different from each other since the STB GUI normally is provided by the operator (service provider) and the TV GUI is provided by the TV manufacturer, this is clearly not ideal but it is the current typical situation. The STB GUI is what the service provider use to give the user an operator branded TV experience, and to provide additional services not available on the standard TV set, e.g. connection to an operator provided movie on demand service. The TV GUI follows the TV provider’s usability guidelines and is normally tightly integrated into the TV set.
The user has two different remote controls, one for the TV and one for the STB. Both have controls for volume up/down. When the user changes the volume on the TV remote control the native TV GUI will display a volume indicator and the TV volume will be changed. When the user changes the volume on the STB remote control the STB GUI will display a volume indicator and the TV volume will be changed.
A number of different technologies are used for graphics rendering on IPTV STBs. All from native, thick client solutions in c/c++, through java, to thin client solutions like Flash, HTML or SVG. A number of different arguments exist for the choice of a specific technology on a specific platform, but in general one can say that the evolution is going from thick towards thin client solutions. Historically STBs are very low in performance and thick client solutions has been the only way to get acceptable performance, with the drawback of offering very little flexibility to the service provider. Lately the performance of STBs have increased sufficiently to allow for thin client solutions, this gives the service provider more flexibility when it comes to branding and other customizations of the GUI, which is a very important requirement for most, if not all, service providers.
When it comes to thin client solutions one can generalize it into two tracks; proprietary and standards based. In the proprietary track Flash is the main player while HTML and SVG are the main standards based alternatives. A very high-level listing of the status and advantages/disadvantages of these three thin client solutions are given in the tables below.
| Technology | HTML4 |
|---|---|
| Status | The mainly used thin client technology for IPTV. |
| Pros |
|
| Cons |
|
Table 1. HTML 4
| Technology | SVG Tiny 1.2 |
|---|---|
| Status | Multiple SVG engines with good performance now available for STBs which has increased the demand for SVG within the IPTV industry. |
| Pros |
|
| Cons |
|
Table 2. SVG Tiny 1.2
| Technology | Flash |
|---|---|
| Status | Not too much used yet but popularity is increasing. |
| Pros |
|
| Cons |
|
Table 3. Flash
| Technology | HTML5 |
|---|---|
| Status | Still not used but a lot of interest in the industry around HTML5. Essentially this interest can be split in two parts, one for the general web APIs developed as part of, or initiated, by the HTML5 WG, like WebStorage, WebWorkers etc. This part applies likewise to SVG. The other part is the interest in the HTML specific improvements between HTML4 and HTML5, especially the video support and CSS transitions/transformations. |
| Pros |
|
| Cons |
|
Table 4. HTML 5
So, why are service providers eager to use web based technologies for IPTV? The first and foremost reason is the service provider’s need to be able to customize the GUI for the user. Different users may be exposed to different services; GUIs may be branded/customized based on the user’s geographical location and so forth. A second reason is the need for the service provider to be able to aggregate and mash-up data and services on the server side. For example inject advertisements into the IPTV GUI or blend in web-TV services. Since most, if not all, relevant data and services are XML based it is very convenient to also use XML as the base for IPTV services. A third reason is the fact that web based technologies are standardized, this means that it is possible to have multiple implementations of the same technology, which is good for the service provider from both pricing and scalability reasons.
For IPTV solutions built on web technologies HTML has traditionally been the most common alternative. HTML, as a presentation format mainly focused on text and layout, is quite a good choice for IPTV GUIs which often are quite text intense. Program guides for broadcasted content as well as content on demand data are the most central IPTV services and both these are text rich.
With the better performing STBs that are available nowadays the demand for more attractive, graphics-rich GUIs have increased. Consumers are getting used to dynamic GUIs with smooth transition effects and direct feedback on interaction. HTML, at least HTML5 with the newer CSS features, can provide quite nice animation/transition effects but it’s nevertheless a presentation format mainly designed for text data. The advantage with using SVG instead of HTML for dynamic, graphics rich GUIs are, in Ericsson’s opinion, the following:
Designed for graphics – SVG is tailor-made to be a graphics format, so it is very well optimized for building graphics rich UIs.
Better performance – Easier to get good performance out of an SVG renderer compared to an equivalent HTML ditto. This largely depends on the content executed in the renderer but for graphically rich content SVG renderers are, based on Ericsson experience, better performing than HTML renderers. Most likely this again is because SVG is designed for graphics.
Scalability – TV devices for multiple resolutions (HD, SD, etc.) requires scalable GUIs.
It should be noted that the points above just list Ericsson’s opinion to why SVG is better suited than HTML for graphically rich GUIs. It does not mean Ericsson consider SVG to be better than HTML in general. We do not believe such a comparison can, or should, be made. SVG and HTML are two different presentation formats, designed for two different purposes. For graphically rich GUIs SVG is to prefer, for text and dynamically laid-out GUIs HTML is to prefer. What we believe would be unfortunate though is if SVG would be extended to also cover HTML use cases, or vice versa. This would just turn them into formats not optimized for anything. Rather effort should be spent on making SVG and HTML co-exist nicely.
The Open IPTV Forum (OIPF) was created in March 2007, to provide an IPTV solution enabling a "plug and play" experience for the end-users and filling an industry gap making it independent from the technology behind it. It consists of a long list of members who are organized in working groups and task forces (sub working groups) working with a large spectra of IPTV related subjects; codecs, metadata, protocols, client environments and content protection.
One of the task forces is called Declarative Application Environment (DAE) and is specifying a client side application environment. Essentially a set of JavaScript APIs for TV related features which is used together with CE-HTML to provide a common environment for IPTV enabled web applications. The features defined are for getting EPG information, metadata information for broadcast as well as content on demand data, recording, timeshift and parental control features, just to mention a few. DAE also include SVG but only as an image format, where HTML must be the root document.
There was quite some interest around CE-HTML some years ago but today it might not be the most asked for presentation format. The fact that DAE was tightly designed around CE-HTML must be considered a mistake. This has been acknowledged by the OIPF lately and work is ongoing to decouple DAE from CE-HTML, giving implementers the choice of choosing other presentation formats, e.g. HTML 5 and SVG.
In parallel, both to fast-track this work in the OIPF DAE task force and to satisfy our existing customers, Ericsson has been working on a set of web APIs for IPTV. Largely inspired by the previous DAE work but without the coupling to CE-HTML and with APIs more suited to function together with modern web formats like SVG or HTML5. These APIs, grouped (for now) under the name Ericsson TV Web Environment, is currently being implemented by multiple SVG engines for real customer deployments. Ericsson’s intention is to contribute these specifications to suitable standardization foras, e.g. OIPF and/or W3C.
Most IPTV specific features, e.g. getting TV related metadata, as mentioned above doesn’t have anything specific to do with SVG and shouldn’t be considered for SVG inclusion but some features do make sense for SVG addition in order to make SVG more suitable for TV and related media/video services. The list below gives a few examples of such features that Ericsson has found necessary to add to SVG.
The ability to seek in time and speed (fast forward/rewind) in a video element’s time container
SVGT 1.2 has multiple elements who define their own, independent, time containers (‘svg’, ‘animation’, ‘audio’ and ‘video’) but only the ‘SVGSVGElement’ interface (corresponding to the ‘svg’ element) has methods related to time containers, the same methods needs to be provided on the other time containers. Additional methods for seek and speed are also needed.
More granularity in media related events (buffering info etc.)
Currently only begin, end and repeat events are triggered for video. These events only indicate the state of the video time container in the SMIL model, they don’t indicate the actual video playback state, which most of the time is what the user is actually interested in.
Priority rules for video elements
STBs and TVs normally have a very limited number of encoders that can run in parallel, for example a STB typically allows one full-screen video playback together with one part-screen playback (picture in picture). Since SVG can contain any number of videos played in parallel it would be very useful to have a mechanism to prioritize them.
Control of subtitles, audio and teletext within a media stream
Since a media stream normally contains a number of different alternatives for subtitles, audio and teletext a standardized mechanism to select between them is needed.
Clipping
Clipping can be an expensive operation which probably was the reason it wasn’t included in the SVG Tiny 1.2 specification. It is however a very important feature in order to create compelling content and most, if not all, SVG Tiny implementations have included clipping although it isn’t part of the specification.
TV key identifiers
The SVG Tiny 1.2 specification (or DOM Level 3 Events) does not specify all key identifiers necessary for TV, many of the common keys on a remote control are missing and need to be added.
This paper has given a brief introduction to IPTV and how and why SVG is used for IPTV. It has compared SVG against similar technologies from an IPTV perspective and described the ongoing standardization efforts within the IPTV industry that relates to SVG. Finally it has touched on the ongoing work within Ericsson to extend SVG to cater for IPTV use cases and listed a few examples of needed extensions.