Table of Contents

IPTV User Interfaces
The Basics
IPTV GUI Technologies
Why Web Technologies?
Why SVG?
Open IPTV Forum
SVG for TV – What’s Missing?

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.

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.

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.