³ÉÈËÂÛ̳

This new feature relies on a DVB table called the Related Content Table (RCT). This table changes dynamically as the broadcast content changes. We are using this table to transmit two kinds of links: links to programmes and links to whole series. We can transmit multiple concurrent links as the trail requires. So these links tell a recorder that we are currently broadcasting a trailer for a particular programme, for multiple programmes or for one or more series, and thus allows the viewer to decide which to book for recording. The specifications allow the broadcaster to transmit their own icon for the initial viewer alert (e.g. 'Book Me') or to use a 'default icon' already embedded in the recorder. We can also transmit a message with each link suggesting why they the viewer might like to record the programme or series.

The mechanism builds on the existing features of Freeview+ recorders that the ³ÉÈËÂÛ̳ already supports such as series linking, repeat identification and recommendations. Ìý

The whole system is reliant on an identifier called the Content Reference ID (CRID). This allows the identification of a programme rather than a timeslot in the schedule. It also allows the abstract identification of a series. This concept has been around for some years and comes from a set of specifications defined by the but the ³ÉÈËÂÛ̳ was the first to broadcast these ids over-air with the launch of Freeview Playback (now Freeview+). This separation of programme from schedule means we can promote a programme or series long before it appears in the schedule - so the viewer can book programmes and series based on those 'coming soon' trailers.

R&D have been fundamental to this complex project, which involved different ³ÉÈËÂÛ̳ departments ("Marketing, Communications & Audiences (MC&A)", Future Media & Technology, and Distribution) and our technology and metadata suppliers - we had to make the business processes work to support this and to get the right systems in place to produce the correct information at the right time. We've worked with recorder manufacturers, through the , as they add this feature into their new products.

Behind the launch of this feature by the ³ÉÈËÂÛ̳ are many years of investigation by R&D. We initially contributed to the standard (Carriage of TV-Anytime over DVB networks, ETSI 102 323) which determines the interchange between the broadcaster and receiver. Through the DTG D-Book process we profiled how the DVB tool kit would be used in the UK and defined how the recorder could and should use the information signalled by the broadcaster. This aspect required significant discussion with receiver manufacturers because although the TV-Anytime standard (TS 102 822-3-1) specifies different types of linkages (in the 'HowRelated' classification scheme) how the types should be used, e.g. what a receiver should do with a link type called 'IsTrailerOf', needed to be defined locally (i.e. in the UK). Throughout all this we had built an end-to-end test and development chain in our lab, and even built some prototype/test receivers to make sure we had the signalling right.

Within the ³ÉÈËÂÛ̳ itself we helped MC&A integrate the correct processes to support the new signalling. We had worked with MC&A before to enable trailer booking on the Sky platform. This mainly meant enabling the correct linkages in the information sent to Sky by our metadata distributor. For Freeview we needed to source extra identifiers and metadata from within the ³ÉÈËÂÛ̳ and our metadata provider in order to provide such things as the promotional text with each link, and help commission a brand new system to generate this signalling.

There were other interesting technical challenges in this project: Trailer booking relies on the in-built 'native' software of the recorder to book programmes to be recorded rather than any kind of application - trailer booking does not use MHEG. One of the reasons for this approach is that each recorder has it own way of presenting a booking to the viewer, and so trailer booking needed to be a familiar user experience. However, it is quite unusual for a broadcaster initiated action to cause something to pop-up on the native user interface - most of the time it is viewer initiated, e.g. changing channel, pressing the info button, selecting the guide (obviously broadcaster initiated pop-ups happen all the time in the MHEG application domain). Many MHEG applications run in a 'sandbox', in that the recorder can't easily tell in how the user is interacting with the MHEG application, e.g. whether the application is in full-screen mode or just an icon is showing. Also, some receiver software cannot display native graphics and MHEG graphics simultaneously. The problem this gives is that it would be an annoying user experience if the recorder put up a green 'book me' icon over an MHEG application or, even worse, tore down the MHEG application, while it is being used by a viewer, in order to put up a green icon. To solve this problem R&D and the recorder manufacturers came up with a way for MHEG and trailer booking to co-exist, whereby the MHEG application has the ultimate control of when green button icons are permitted. So, when the user starts to use MHEG, the MHEG application can choose to suppress trailer booking pop-ups.Ìý When we were reviewing this idea we built this into our prototype receiver to check this feature would behave as expected.

Being able to deliver synchronised typed metadata, which is what trailer booking is an example of, is just the start. The specifications,Ìý DTG tests and head-end are designed to allow future expandability. Now this data stream and supporting processes are in place there's much more we can add. For example, there's whole range of different link types available. So watch this space.

Look out for trailer booking on the new range of Freeview+HD PVRs - it's a standard feature.