EP2149261A1

EP2149261A1 - Control of receivers by broadcast data

Info

Publication number: EP2149261A1
Application number: EP08737031A
Authority: EP
Inventors: Christopher Rowlands Wass; David John Cutts
Original assignee: Strategy and Technology Ltd
Current assignee: Strategy and Technology Ltd
Priority date: 2007-04-18
Filing date: 2008-04-18
Publication date: 2010-02-03
Also published as: GB0707510D0; WO2008129269A1

Abstract

A method for controlling a device (113) used with a broadcast receiver in which two broadcast data streams (107) are used in conjunction. The method comprises receiving a first data stream comprising compressed data appropriate for producing an electronic program guide and receiving a second data stream comprising uncompressed data appropriate for controlling time critical events. The device (113) is controlled using a link provided between the first data stream and the second data stream provided by an identifier included within the first data stream and the second data stream. In this way, the device (113) is controlled using less bandwidth than that required to support a device that relies on all data to be delivered uncompressed via the second data stream only.

Description

CONTROL OF RECEIVERS BY BROADCAST DATA

FIELD OF THE INVENTION

The present invention relates to control of devices used with broadcast receivers, in particular the control of recording devices for recording broadcast television signals referred to as Personal Digital Recorders (PDR). A PDR may be incorporated in the same physical box as a receiver or implemented as a separate linked device and in either case is used with a broadcast receiver.

BACKGROUND OF THE INVENTION

Various standards for the broadcast of data via cable, satellite, terrestrial or other route are well known to those skilled in the art. These standards include MHEG-5 and DSM-CC Object Carousel which together enable, amongst other functions, the delivery and publishing of text data including Electronic Program (Programme) Guide (EPG) information in an MPEG broadcast stream. This provides a means to display guide information to users. We have appreciated, though, a need for an improved method and system for controlling devices such as Personal Digital Recorders, particularly when using an EPG provided using MHEG-5 (an MHEG EPG) (MHEG is Multimedia and Hypermedia Experts Group). In particular, we have appreciated that existing standards could be improved to assist control of PDR devices.

The existing open standards based mechanisms for the control of PVRs (personal video recorders) are based on systems that use service information, DVB (digital video broadcasting) service information or SI for the carriage of accurate timing information for the purpose of triggering recordings in a timely manner. The delivery of timing information via this method works well and can make use of existing broadcast SI structures. However, these systems also require that all viewer-facing data for the purposes of populating an EPG shall also be delivered via SI tables. The delivery of viewer-facing EPG data via this method is inefficient for a number of reasons, as described: The data may not be compressed using existing mechanisms and is therefore expensive in terms of bitrate usage.

The bitrate usage may vary throughout the day according to the size and shape of EPG data that is to be delivered to the EPG at each moment. This variation makes it difficult for a broadcaster or platform operator to plan a bitrate budget.

The broadcaster is limited to supplying EPG data in the format defined by the currently available DVB or ATSC tables and descriptors. It is not possible to change easily the manner in which existing information is used or additional information defined. If a requirement exists to deliver custom data to the receiver for the purpose of populating an EPG it must be achieved using private descriptors. The format of all private data must be agreed by broadcasters and receiver manufacturers as this has impact on receiver design.

In a horizontal market it is not easily possible to ensure that an EPG as implemented by a number of different receiver manufacturers maintains a common look and feel and behaviour as defined by the network operator or broadcaster.

SUMMARY OF THE INVENTION

The invention is defined in the independent claims below to which reference should now be made. Advantageous features are set forth in the dependent claims.

A preferred embodiment of the invention is described in more detail below and takes the form of a method for controlling a device used with a broadcast receiver in which two broadcast data streams are used in conjunction. The method comprises receiving a first data stream comprising compressed data appropriate for producing an electronic program guide and receiving a second data stream comprising uncompressed data appropriate for controlling time critical events. The device is controlled using a link provided between the first data stream and the second data stream provided by an identifier included within the first data stream and the second data stream. In this way, the device is controlled using less bandwidth than that required to support a device that relies on all data to be delivered uncompressed via the second data stream only.

In broad terms the invention provides a method and system for controlling a device used with a broadcast receiver in which two broadcast data streams are used in conjunction. A first data stream comprises data appropriate for producing an Electronic Program Guide, preferably an MHEG EPG. A second data stream comprises data appropriate for controlling time critical events, preferably in the form of DVB EIT tables. A link is provided between the two streams by an ID, preferably a Content Reference ID (CRID) included within the first and second data streams.

An embodiment of the invention can make effective use of both MHEG EPG data and EIT tables as a mechanism to both display information to a user and to control a PDR. The MHEG EPG data is compressed and so is an appropriate method for broadcasting the content rich data needed for presentation to a user. In contrast, the EIT tables are not compressed and so are an inefficient way of broadcasting textual data for presentation to a user but can provide time accurate data for control of recording. The embodiment therefore proposes reducing the information transmitted in the EIT tables and instead providing a link between the EIT tables and EPG data using identifier in the form of the CRID. This allows the MHEG EPG data to be used for presentation and the EIT tables to be used for control.

It is possible that the invention could be used with other standards involving compressed program guide data and uncompressed event data other than MHEG and EIT, but these are preferred.

The invention may be embodied in a method of broadcasting, method of receiving, broadcast device, receiver, recording device or a system including both broadcast and receiver devices. In the device embodiments, the method steps described above and in the description of the embodiment may be implemented by appropriate means such as processors, memory and other hardware. The inventors of the present application are the first to appreciate that to combat the above described inefficiencies all or most of the viewer-facing data may be removed from the SI stream and instead be carried using DSMCC sections. The EPG application that decodes and displays this data may optionally also be delivered to the receiver via DSMCC sections.

SI may continue to be used for the delivery of accurate timing information to the PVR. Each piece of programme content in the broadcast schedule may be associated with a Unique Content Identifier (UCI). It may not be necessary for UCIs to be human readable since they are used at the system level only and would not normally be presented to the viewer. An example of such an identifier, which has been defined as the UCI in TVAnytime derived systems is called a Content Reference Identifier (CRID). The CRID is used as the example UCI in this document as the CRID format enables efficiencies to be made in the delivery of such UCI data. However, any UCI format may be used to uniquely identify programme content for the purpose of managing PVR functions.

One or more UCIs may be delivered within UCI descriptors to identify individual Programmes, Series of programmes and Recommendations. By this method it is possible to provide accurate timing information for each UCI representing a piece of programme content in a broadcast schedule.

The UCI value for each SI event or series of events may also be associated with the viewer-facing EPG data delivered via DSMCC. The UCI may form the primary key used to associate DSMCC bound viewer-facing EPG data with SI bound accurate timing and schedule information.

An Application Programming Interface (API) may be defined to provide a communications link between the core PVR Engine and the Broadcast API Engine on which the EPG is executed. The EPG application may use this API to manage the booking of recording of programme content and to manage content from previous successful recordings stored on PVR local storage. By separating the viewer-facing and system data and through implementation of an API between the engines that make use of these data, the SI and DSMCC streams may each be used to their best advantage as described:

All viewer-facing EPG data may be compressible using standard ZLib compression available to DSMCC sections.

A constant bitrate DSMCC stream may be defined, the bitrate of which is independent of the size and shape of data carried within it. Where appropriate and available, opportunistic data may also be used to further improve efficiencies of the DSMCC stream.

The EPG may be presented to the viewer using a standard Broadcast API rather than via an application native to the receiver. This enables a consistent look and feel and EPG behaviour to be maintained, even in a horizontal market that may include multiple receiver manufacturers.

The EPG and EPG data delivered via DSMCC files or modules may be formatted according to the requirements of the EPG application and to take best advantage of the method of delivery. This enables easy extension of EPG features as new requirements emerge. The receiver manufacturer does not need to be consulted about changes to the EPG data format.

The accurate recording of programme content may be maintained using current receiver mechanisms through reference to SI tables. SI may be used to deliver the minimum data required to uniquely identify Programmes, Series and Recommendations. UCIs are not viewer-facing information so may be encoded using strings of only a few bytes in length thus reducing SI bitrate requirements to a minimum.

The SI stream may be delivered at near constant bitrate thus enabling network operator and broadcaster bitrate budgets to be planned more easily. This PVR functionality may be achieved with minimal changes to existing core receiver functionality. This reduces the barrier-to-entry for receiver manufacturers and broadcasters alike whilst enabling more customisable PVR functionality.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described in more detail by way of example with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram illustrating a known system, and in particular data flow for a non-PDR STB;

Figure 2 is a schematic diagram illustrating an example of the present invention, and in particular data flows for a PDR; and

Figure 3 is a schematic diagram illustrating an example of the present invention, and in particular the process by which Sl, DSMCC sections and AV programme content are encoded on a server and subsequently decoded by a client.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

A method and system embodying the invention are described below.

1 INTRODUCTION

Some basic mechanisms for implementing a Personal Digital Recorder (PDR) using MHEG as a Ul (user interface) presentation system are described. The mechanisms are based on the use of a Content Reference ID (CRID) as the means of event identification.

Part 2 describes the basic metadata required for a PDR system and shows how this enables functions such as: event recording, conflict resolution, "time accurate" recording, split events series linking, and recommendations.

Part 3 describes the current Set Top Box (STB) platform where EPG data is presented by an application broadcast in the service. In part 4 we show how this EPG application can be extended to book recording events with the resident

Recording Engine of a PDR. Part 5 demonstrates a possible extension that would allow the playback and library management functions of the PDR to be controlled by an MHEG application, this time resident in the PDR platform itself.

2 BASIC METADATA FOR PDR OPERATION

All items to be recorded and viewed are termed "events". Events can be a single programme, a series of episodes or programmes or a set of programmes linked by a common theme, so-called recommendation events (for example, a series of films with a specific star actor). There is duplication here - both series and recommendation events link together a number of individual programmes, so all members of these events must be single programme events in their own right too. Each event is identified by a Content Reference ID, or CRID.

2.1 CRID

A CRID consists of a Scheme, an Authority, a Unique Part and optionally an instance identifier. The Scheme describes the format of the CRID; the Authority identifies who is publishing the identifier. The Unique Part identifies the event uniquely to the Authority. Given the following:

CRID://bbc.co.uk/012dfa#blah1

CRID://bbc.co.uk is the Scheme + Authority (referred to as the Authority throughout this document).

/012dfa is the Unique Part of the CRID, which is used to identify a single event, a group of events or a recommendation.

#blah1 is the Instance Metadata Identifier and is used to identify a number of different things depending on the state of the rest of the CRID.

The Instance Metadata Identifier is used primarily to signal programmes that are split into parts, for example a film split by a News programme. In this case the two events on either side of the News will have the same CRID and the same Instance Identifier. Both parts of the event will be recorded as a single programme if the distance between the events is within a fixed timeframe, usually an hour or less. Without the Instance Identifier the PDR would "see" 2 copies of the same event and so record only one half of the complete programme. Series and recommendation CRIDs cannot include Instance Identifiers.

The Unique Part is in fact only pseudo-unique for group CRIDs. Group Identifiers can be recycled by the Authority after a period over which it is unlikely for the PVR to remember unused groupings. Event CRIDs shall not be reused to represent different content and shall therefore be unique. If the same CRID is being broadcast twice without an Instance Metadata Identifier this is considered a repeat. The PDR shall attempt to record the first instance that does not conflict with other recordings.

2.2 EVENT METADATA

Broadcast events are published using standard DVB EIT tables. To map a CRID to an EIT event each EIT event, in both EITpf (event information present/following) and EITs (event information table schedule) , contains a Content ID descriptor encapsulating the CRID.

As shown above, every CRID includes an Authority part (as described above both Scheme and Authority part are considered together). This is the same for nearly all CRIDs within a certain service (or group of Broadcaster's services). To reduce the bandwidth usage a Default Authority Descriptor (DAD) is located in the service loop of the SDT or the Transport Stream loop of the NIT. The DAD describes a default Authority that can be assigned to all events in the service or network. The EIT events contain only the Unique Part and Instance Identifier (if present) parts of the CRID. This is called a "short-form CRID" for the duration of this document. The receiver can rebuild the full CRID from these sources.

Traditionally EIT provides descriptive event metadata: event name, short description, long description, in addition to timing information. This is expensive in terms of bandwidth, as the name and the descriptions are uncompressed. In this document we deprecate this functionality in favour of a more efficient system.

However, EIT is still a sensible method for publishing scheduled time information.

EITpf is used for "time accurate" recording control as it is often derived directly from the broadcast play-out system.

3 MHEG PROVISION OF AN EPG

The current MHEG EPG is used for a non-PDR STB (set top box) as a means for the user to browse information on the available services over a period of time. There is no means to tag events, but if an event is active then the user can select it and have the STB tune to the required service.

The metadata for the service is broadcast alongside the EPG application in the broadcast file system. The metadata transmitted consists of: Event name,

Billed time and duration, Synopsis, Classification, Availability of Captioning

Placing metadata delivery in the application domain allows more flexibility in changing the dataset and the encoding method as requirements change, compared to a system where the data receiver is coded into the box: the broadcast EPG acts as a "transient OAD" of part of the receiver system.

Figure 1 shows this system and in particular data flow for a non-PDR STB. In Figure 1 , the reference numerals correspond to the following features. 1 is Metadata, 2 is Broadcaster, 3 is EPG application + descriptive metadata via DSMCC, 4 is Receiver, and 5 is EPG.

4 MHEG CONTROL OF EVENT BOOKING

A Personal Digital Recorder (PDR) contains a Recording Engine and a Playback Engine, with a shared Schedule Library. The Library lists all events that are to be recorded and that have been recorded, and ones that failed to be recorded. The Recording Engine manages the list of scheduled recordings, looking out for them to be broadcast and controlling their storage. The Playback engine controls presentation of stored events.

In order to relate events in the EPG to events for the PDR to record we need to provide a key. To do this we extend the EPG data to include one or more CRIDs for each event. For efficiency the CRIDs are split into Authority and short-form in a similar manner to the EIT delivery. Events can have multiple CRIDs, for series linking and recommendation linking. To schedule a recording the PDR makes use of EIT tables. These are transmitted alongside the MHEG-bound descriptive metadata. Although both EITpf and EITs are transmitted, the EITs tables are stripped of their descriptive metadata and contain only CRID and schedule information. It should be noted that the bit rate requirement of CRID-only EITs is much more consistent over time than a full descriptive data-based service. Furthermore, initial bandwidth tests show EITs containing short-form CRIDs need only a fraction of the bit rate required by a full EIT system; combined with DSM-CC delivery of descriptive metadata this provides valuable gains in bandwidth compared to an EIT-only solution.

Alongside the required Start-Time and Period, EITpf maintains its event name and short description as this may be used by the PDR for populating its recording library and for instant access to "Now/Next" info on channel change. This may be extended to include Now/Next+ using standard EITs though at a premium since this data cannot be compressed. Using EIT for schedule control of recording is very common and is implemented in many PDR platforms.

Figure 2 provides an outline of the system, and in particular data flows for a PDR. The reference numerals in Figure 2 correspond to the following features. 1 is Metadata, 2 is Broadcaster, 3 is EPG application + descriptive metadata via DSM-CC, 4 is Receiver, 5 is EPG, 6 is Schedule metadata via EITs and descriptive metadata via EITpf, 7 is Metadata missing events, 8 is Control + ID, 9 is Descriptive metadata, and 10 is PVR recording engine.

As described above the EIT carries each CRID in short-form, with DAD entries in the SDT (or NIT if required) to allow the PDR to expand these to full format.

The MHEG EPG application is loaded and running "silently" in the background whenever the viewer is watching a channel connected to the EPG service. This means that the parts of the EPG that might send or receive data to or from the PDR Engine would be running even if the viewer orientated parts (The EPG grid and viewer events) are not.

4.1 RECORDING A SINGLE PROGRAMME The viewer selects a programme to be recorded from the EPG. The full Event CRID of the programme is constructed and, through a Resident Program call the PDR Recording Engine is told to add the CRID to its list of scheduled events. The call may include event information such as name and short description, or these may be provided at a later point. There may be an additional "what information are you able to store" Resident Program which would be used to format the data according to requirements of the PDR implementation.

The PDR uses the DAD and EITs to search for the scheduled time for this event, ideally for multiple occasions if this is possible. It then checks that this does not produce a conflict with other scheduled recordings. Assuming there is no problem it schedules the recording and returns.

Handling conflicts can be performed at 2 levels: Either the PDR can put up a prompt describing the conflict (showing the other events involved) or it can provide details of the conflict to the EPG and have it prompt the viewer to decide what not to record.

The scheduled event is recorded by the PDR in the normal manner, using EITs to track scheduled time and EITpf for accurate start and duration.

4.2 RECORDING A SERIES OR RECOMMENDED SET

The data delivered to the EPG application contains all the CRIDs for a programme event. At the least this means a single event, but it may also include a series CRID and a recommendation CRID. The EPG application may be written to be aware of these additional CRIDs and allow the viewer to use them.

As an example, the EPG recognises that a programme is part of a series. It indicates this on the Ul, perhaps by adding a button to "record this and the rest of the series". When the viewer chooses this the EPG communicates the series CRID to the PDR instead of the programme CRID. The PDR handles the schedule in a similar way to the single programme example, except that it recognises that the CRID selects multiple programmes. Whenever an event in the series becomes visible in the EIT it is added to the list of scheduled events. In this instance the group CRID is used only as a handle to obtain the event CRID - the unique CRID for that programme in the group. The event CRID is used to record the actual event.

There may be need for some timeout of group CRIDs, for example if a group CRID has not been seen in the schedule for 90 days or more it shall be removed from the record list. In the case where a recommended event also includes recommendations these shall not be followed. Only the first level of recommendations shall be scheduled for recording.

Recommendations to single events may be made to events that are present in the current schedule only. If a recommendation is made to a series then at least one event of the series must be present in the current schedule.

When events are scheduled automatically it may be possible that the EPG data is not available to the PDR. This means that events may be listed as due for recording, but no name or description is available. There are a few possible solutions to this problem:

1. If the viewer is watching a programme then the EPG is available. The PDR can signal to the EPG that it has unfilled slots in its schedule information and request that the EPG provide the data for it. The mechanism for doing this at an MHEG level could be based on an Engine Event raised by the PDR when it becomes aware that the EPG is active. The EPG application would then ask which CRID is unknown, look it up in the EPG data and return the information to the PDR.

2. If the information has not been obtained from the EPG by the time the scheduled event is transmitted then the PDR can retrieve it from the EITpf table when it is recorded. The EIT event would contain the name and short description; the long description and other descriptors may be optionally be transmitted at the expense of higher bandwidth usage.

3. For series linked events the PDR can "guess" the name of event by assuming all events in the series have the same name. No description data can be obtained that relates to the particular episode however. If process 1 or 2 above are available then these will provide the required data.

5 MHEG CONTROL OF PDR PRESENTATION

The system above shows how MHEG can be used to schedule recordings from the EPG, even for selecting series linking or recommendations. Playback of events from the PDR planner would be controlled by the middleware. The following is an alternative implementation, using MHEG also as an interface to the PDR Playback Engine.

Through the use of MHEG Stream objects full playback control is possible with trick mode support already built into the language, albeit not implemented in broadcast-only systems. The advantages of an MHEG-based solution would be the same as currently seen in EPG applications - consistent presentation and the option for branding and perhaps advertising.

When the viewer wishes to watch a recording the MHEG application obtains a list of scheduled events. The data provided could be:

CRID to reference the object for playback, Name,

Description,

State (recording, recorded, pending, failed, reason for failure)

The application might process this data to display only events available for watching. The viewer is able to browse the list, selecting to view descriptions in a similar manner to the broadcast EPG.

Selecting an event to watch the application would create a Stream object referencing the event by CRID and start play-back. Full control of playback speed and the ability to jump to a certain time point is available through MHEG elementary actions. These elementary actions are defined in the MHEG ISO standard, but are not implemented in broadcast-orientated versions.

As an extension the PDR Library could be managed: events deleted or flagged to prevent deletion etc. This functionality would be best supported when the control application is available when the receiver is not connected to the broadcast system - i.e. it is resident in the receiver. Without this the PDR would become inoperative for instance when the broadcast service is unavailable due to poor weather - perhaps just the time when the viewer would want to watch a recorded show. With a PDR there is an abundant supply of local storage and it makes sense to provide a means of caching broadcast applications to disk. Special care may be needed to cache only application files and not the EPG data. For this the DVB introduced the caching priority descriptor.

This allows the broadcast to signal at a DSM-CC module level which modules can be statically cached (even to disk). Careful control of the layout of DSM-CC modules would allow the static application to be cached (but updated if the application broadcast is changed) whilst EPG data is always obtained from the broadcast only.

6 CONCLUSION

The advantages of MHEG and DSM-CC as a means to deliver and present EPG data for a Set Top Box have been demonstrated, these include:

Bandwidth efficiency for metadata delivery, Ease of customization of the EPG presentation.

This paper has described how that technology can be easily extended to allow the viewer to book events, either one off or connected by series or genre, whilst maintaining the advantages already gained.

MHEG is a flexible presentation system, which is capable of implementing all of the Ul requirements of a PDR, even controlling playback of recorded events with trick mode support. For full flexibility this requires extending the current model of broadcast applications to having them resident on the PDR, the technology to do this is well understood. A method by which Personal Video Recorder (PVR) functionality may be obtained using a combination of the minimum of strictly defined signalling carried within standard Digital Video Broadcasting (DVB) or Advanced Television Systems Committee (ATSC) Service Information (Sl) tables and loosely defined Electronic Programme Guide (EPG) data carried within Digital Storage Media Command & Control (DSMCC) sections. The basis of this separation of data is to enable accurate event recording as signalled via standard SI mechanisms with the ability to provide compressed and freely customisable EPG data delivered to an EPG via a constant bitrate DSMCC stream. A communications link between the PVR engine and EPG presentation sub-systems enables the management of prerecorded programme content and the booking of new recordings using the EPG as the primary user interface.

SERVICE INFORMATION The UCI is a unique identifier that shall be used to identify Programmes, Series or Recommendations. If the CRID is used as the UCI this shall be defined in the Content Identifier Descriptor (CID), which shall be carried in the Event Loop of the Event Information Table Present/Following (EIT P/F) and Event Information Table Schedule (EIT Schedule) in DVB systems and in equivalent tables in ATSC based systems. If non-CRID based UCIs are used these shall instead be defined within private descriptors carried within EIT P/F and EIT Schedule or equivalent ATSC table structures. A private descriptor defined for the purpose of carriage of UCI data shall be referred to as a UCI descriptor throughout this document.

The CRID may be defined as one of three types that are used to identify an individual Programme (content), a Series of programmes or a series of Recommendations. CRIDs that identify programme content are referred to as Programme CRIDs and those that identify Series and Recommendations are called Group CRIDs. Similar methods of identifying Programmes and Groups of programmes may also be defined using non-CRID based UCIs. These shall be defined as Programme UCIs and Group UCIs throughout this document.

A Programme UCI is unique to a complete piece of programme content and may not be used to represent other programme content. In CRID based systems a registered domain is used as a suffix to the UCI thus enabling UCIs to be defined by more than one body without the need for a central (to all bodies) UCI management system. Similar centrally managed or decentralised methods may be adopted by non-CRID based UCI systems to ensure that Programme UCIs are unique to the content they represent.

Group UCIs define arbitrarily linked Programmes with relationships defined by the individual body. Group UCIs may be re-used to represent different content after an appropriate amount of time has elapsed since last use, three months for example. This time is the period after which the PVR will remove an unused Group UCI from the PVR list of bookings to record. This period may therefore be altered, with consultation from receiver manufacturers, according to the requirements of the platform.

In DVB systems each Programme described within the EIT P/F and EIT Schedule shall carry in the Event Loop at least one UCI descriptor that shall contain one UCI of type Programme. Additional UCI descriptors may also be carried in the same Event Loop to describe Groups. These Programme and Group structures may also be carried in equivalent tables in ATSC based systems.

A UCI descriptor that describes a Series may contain multiple UCIs; therefore a Programme may be part of more than one Series. A UCI descriptor that describes a Recommendation may contain multiple UCIs; therefore a Programme may be part of more than one Recommendation. A single piece of programme content may be signalled to be part of multiple Series and multiple Recommendations.

In DVB systems UCI descriptors shall be carried within EIT Schedule to provide a schedule of UCIs and EIT P/F to provide a means of obtaining accurate timing information for the Present and Following events. Additionally Short Event Descriptors and other informative descriptors may be carried within EIT P/F to enable instant access to "Now/Next" information when the viewer performs a channel change. In ATSC systems UCI descriptors and other informative descriptors may instead be carried in ATSC equivalent tables. To further reduce bandwidth usage within SI in CRID based UCI systems a Default Authority Descriptor (DAD) may be defined that describes the registered domain for any number of CRIDs that share a domain. The domain in this instance describes a common suffix shared by a group CRIDs. By this method, the registered domain does not need to be defined in the CRID for events that share that domain. Similar methods of describing common parts of large groups of UCI values may also be used in non-CRID based systems thus eliminating the need to encode the complete UCI for every event.

DSMCC DATA

All data to be presented to the viewer by the EPG application shall be delivered via a DSMCC stream. This data may be carried as files within a DSMCC object carousel or as modules within a DSMCC data carousel. The format of this data shall be defined by the requirements of the broadcaster, the limitations of the Broadcast API used to present the EPG and its suitability to the method of delivery.

The UCI for each Programme, Series and Recommendation in the scope of the current schedule shall be carried within the DSMCC stream alongside any viewer-facing data that describes the content. The UCI shall be treated as the primary key that shall be used to make the connection between a description of an event in the EPG and the accurate timing information described in Sl. Further efficiencies may be made within the DSMCC data by encoding UCI values that share a common suffix or other property so that the common part is encoded and carried once only.

THE BOOKING PROCESS

To book the recording of an event the viewer shall have the means to select from the EPG the content they wish to be booked for recording. This content may be an individual Programme, a Series or a Recommendation.

An API call shall be made to send from the Broadcast API Engine to the PVR Engine the UCI and UCI Type that represents the requested booking. Viewer facing data shall also be sent from the Broadcast API Engine to the PVR Engine at this time. This data may be used to aid management of recorded content by the viewer after a successful recording has been made. A return code shall be returned to the Broadcast API Engine from the PVR Engine, the value of which indicates the success or failure of the booking request including details of the failure where appropriate.

When a booking is made using a Programme UCI a look-up within the UCIs delivered via SI shall be performed to query the existence of the selected Programme UCI. If a successful booking request is made the Programme UCI and the viewer-facing data sent from the Broadcast API Engine to the PVR Engine shall be stored on the PVR local storage. The UCI schedule broadcast in SI will be continually monitored for the booked Programme UCI.

When a booking is made using a Group UCI this will be resolved via an SI lookup into a list of Programme UCIs at the time of booking. The list of Programme UCIs represents the actual programmes to be recorded by the PVR Engine. For a booking request to be successful at least one Programme event of the Group must exist within the scope of the current schedule. If a successful booking request is made the Group UCI and the viewer-facing data sent from the Broadcast API Engine to the PVR Engine shall be stored on the PVR local storage. The Group UCI provided by the Broadcast API Engine remains the primary key for the recording of any events within that Group. By this method it shall be possible to book for recording Programme events that are not yet in scope of the EPG.

By the method described it shall be possible to check at the time of booking, which individual Programmes within a Group should be booked for subsequent recording. The actual list of Programmes to record will be determined by Programme UCIs carried in SI and on the list of Programme UCIs representing Programme content previously recorded and stored on the PVR.

THE RECORDING PROCESS

PROGRAMMES

The PVR Engine shall on a continuous basis check SI for the existence of the booked Programme UCI. When the schedule is such that booked Programme UCI is described as the currently active event the PVR Engine shall start the recording process on the service indicated by the location of the UCI within Sl. In DVB systems this may achieved through continuous monitoring of the Present event within EIT P/F sections and may be achieved by equivalent means in ATSC systems. The PVR Engine shall take into account any resource management latencies in order to start the recording in a timely manner.

The recorded content shall be stored alongside the pre-stored Programme UCI and viewer-facing data in a format defined by the receiver manufacturer. The viewer-facing data shall be obtained from data sent from the Broadcast API Engine to the PVR Engine at the time of booking and the UCI shall be obtained from Sl.

The recording process for the current event shall continue until the booked UCI is no longer the current active event as signalled within Sl. If the UCI does not indicate that the Programme has been split for broadcast into a number of parts the recording shall be marked as complete and the Programme UCI shall be removed from the PVR list of UCIs to monitor for recording.

If the UCI indicates that the Programme shall be broadcast in multiple parts the SI shall be continued to be monitored for additional instances of the booked UCI. Any new instances to be recorded must start within in a pre-defined period since the end of the previous instance, three hours for example. This period may be altered, with consultation from receiver manufacturers, according to the requirements of the platform. At the point at which no further instances of the UCI are scheduled in the defined window the recording shall be marked as complete and the Programme UCI shall be removed from the PVR list of UCIs to monitor for recording.

SERIES AND RECOMMENDATIONS

To record Programme content booked via a Group UCI this UCI shall be continually resolved into a list of Programme UCIs via a look-up of UCIs delivered by Sl. If a Group UCI has been requested to be booked for recording this Group UCI shall be used as the primary key when monitoring Sl. The Programme UCI shall be used for the actual recording only if the PVR logic states that the Programme shall be recorded. The actual list of Programmes to record will be determined by Programme UCIs carried in SI and on the list of Programme UCIs representing content previously stored on the PVR local storage.

At the point at which a Programme within a Group is recorded it is treated as a single Programme event since the recording is based on the now resolved Programme UCI. The individual Programme may be referenced by a Programme UCI that indicates that it will be broadcast in multiple parts. Group UCIs shall however not directly indicate that Programmes within the Group are broadcast in multiple parts.

The recorded Programme content shall be stored alongside any pre-stored Programme UCI and viewer-facing data in a format defined by the receiver manufacturer. The viewer-facing data shall be obtained from data sent from the Broadcast API Engine to the PVR Engine at the time of booking. The Programme UCI shall be obtained from Sl. It may not always be possible to obtain data that describes individual Programmes within a Group when booked for recording via a Group UCI. Viewer-facing data may also therefore optionally be obtained at the time of recording from informative descriptors carried Sl. In DVB systems this data may be obtained through Short Event Descriptors and other informative descriptors carried within EIT P/F sections and may be obtained from equivalent SI descriptors in ATSC systems.

Each Programme recorded as part of a Group shall be marked as complete using the same logic as that described for Programme events. The Group UCI shall continue to be monitored for additional events in the same Group. The Group CRID shall be removed from the PVR list of monitored UCIs only if the UCI is not seen in the broadcast schedule for a defined period, three months for example. This period may be altered, with consultation from receiver manufacturers, according to the requirements of the platform. Recommendations may be made to Programmes that are present in scope of the current schedule only. If a Recommendation is made to a Series then at least one Programme in that Series shall be present in the current schedule.

If a Recommendation event booked for recording also includes

Recommendations these shall not be followed. Only the first level of Recommendations shall be booked for recording. If a Series event also includes other Series only the first level of Series shall be booked for recording.

Figure 3 illustrates the process by which Sl, DSMCC sections and AV programme content (and other structures necessary for the purpose of creating a valid Transport Stream and optional Out Of Band signalling) are encoded on the server and how this data is subsequently decoded on one of many clients. In this instance the server may be a broadcast head-end and the client may be a digital television receiver. The broadcast may be made from one broadcast device or from a plurality of broadcast devices. A detailed description of Figure 3 follows, which illustrates a system for controlling a device used with a broadcast receiver in which two broadcast streams (a first broadcast stream and a second broadcast stream) are used in conjunction. The reference numerals correspond to the reference numerals of Figure 3.

201 The server side, broadcast device or devices (Broadcaster or Network operator, or a computer comprising a computer program).

202 The Client side (A receiver and, in particular, a Digital Television Receiver; a recording device, such as a PDR or PVR; or a computer comprising a computer program).

101 Broadcast Automation, Scheduling & Management System.

102 EPG Application and Data Preparation process.

103 DSMCC Encoder & Player. This forms part of a process for providing compressed data appropriate for producing an electronic program guide in the first data stream including an identifier, which identifies a time critical event such as the broadcast start and end times of a programme. Typically, the identifier consists only of a unique part and an instance identifier. 104 SI Encoder & Player. This forms part of a processor for providing uncompressed data appropriate for controlling time critical events including the identifier and for providing the second data stream.

105 AV / Other Encoders & Players. 106 Multiplexor.

107 Broadcast Transport Stream, which has two data streams, a first data stream and a second data stream. The first data stream, which has a constant bit rate, comprises compressed data appropriate for producing an electronic program guide, such as an MHEG EPG. The second data stream comprises uncompressed data appropriate for controlling time critical events, for example, in the form of event information tables. As mentioned above, the first data stream and the second data stream include an identifier, for example, a Content Reference Identifier (CRID), which provides a link between the first data stream and the second data stream. In this example, the first data stream also comprises an EPG application and EPG information.

108 Optional Out-Of-Band channel.

109 Receiver Front End(s) and De-multiplexor.

110 AV / Other Decoders.

111 SI Decoder. 112 DSMCC Decoder.

113 PVR Engine

114 Broadcast API Engine.

115 EPG Application.

116 PVR Local Storage.

1. The interface between the Broadcast Scheduling System and the SI Encoder for the provision of broadcast schedule and UCI data to encode in Sl. Default Authority or equivalent data to be encoded in other SI sections may also be provided through this interface. 2. The interface between the Broadcast Scheduling and/or Automation Systems and the SI Encoder for the provision of accurate timing information and Present and Following UCI information.

3. The Interface between the Broadcast Scheduling System and the EPG Application & Data Preparation process for the provision of a complete list of UCIs and a complete list of viewer-facing EPG data.

4. The interface between the output of the EPG Application & Data Preparation process and the input of the DSMCC Encoder Player.

5. EPG application data and optionally the EPG application itself encoded into DSMCC sections and played in a continuous cycle using DSMCC data carousels or object carousels. Updates to data and/or EPG applications scheduled by the Broadcast Scheduling and Automation Systems flow through the system thus ensuring the latest EPG data is provided to the client.

6. SI sections containing a schedule of UCIs and accurate timing information for the Present and Following Programme UCIs. Other SI sections containing informational descriptors and SI sections necessary for the provision of a valid Transport Stream may also be output. Updates to the schedule from the Broadcast Scheduling and Automation Systems flow through the system thus ensuring the latest schedule and UCI data is provided to the client. 7. The Programme content consisting of Audio and/or Video and/or supplementary data and signalling streams for the purpose of delivering a valid Transport Stream.

8. The EPG data and optionally the EPG Application itself decoded from DSMCC sections. Normally, the EPG application and data are carried together in the broadcast stream, but they might get played back from disk or from flash memory.

9. UCIs and supplementary data are continually decoded and updated on the PVR local store to build a locally cached schedule of UCIs to mirror the schedule of Programmes and Groups in scope of the current EPG. 10. The interface over which Programme AV and supplementary content is passed during the recording process.

11. A bi-directional interface between the Broadcast API Engine and the PVR Engine used to request the booking of recordings and for the management of content stored on the PVR local storage. 12. A bi-directional interface between the EPG Application and the Broadcast API Engine used to request the booking of recordings and for the management of content stored on the PVR local storage. Requests made by the EPG application are passed onto the PVR Engine by the Broadcast API Engine. Similarly return codes passed back from the PVR Engine to the Broadcast API are passed back to the EPG application using this interface.

13. The bi-directional interface between the PVR Engine and local storage used for the storage and retrieval of data and AV programme content.

Data that describes the schedule of programmes, viewer facing EPG data and programme unique identifiers (CRIDs) are collated and stored centrally by the network operator.

The process that collates this data is connected to the input of a DSMCC encoder

103 and to the input of an SI encoder 104 either directly or via intermediate processes that process the data to best suit the individual encoders.

The output of each of the encoding processes is connected to inputs of a multiplexor 106 and optionally to a process that enables part of the stream to be carried out-of-band.

Additional encoders 105 are connected between the output of the central collator/control system and multiplexor inputs for the purpose of encoding and multiplexing audio, video and supplementary data streams into one or more

Transport Streams 107.

The output of the multiplexor 106 and out-of-band encoder are connected via broadcast 107 or out-of-band transmission channels 108 to a de-multiplexor 109 in the receiver, where the Transport Stream and optional out-of-band stream are de-multiplexed back into DSMCC, Sl₁ audio, video and supplementary data components.

The de-multiplexor 109 is connected to the input of a DSMCC decoder 112 and to the input of an SI decoder 111. The DSMCC decoder 112 is connected to the input of a Broadcast API Engine

114 where the decoded application and data are executed in order to produce an on-screen EPG 115.

The SI decoder 111 is connected to an input of a PVR Engine 113.

The PVR Engine 113 is connected via a bi-directional link to a storage device 116. Additional inputs 110 to the PVR engine 113 enable audio, video and supplementary data to be routed to the storage device 116. These connections enable the PVR Engine 113 to monitor and query the SI stream to check the booking of recordings, to trigger the recording of programme content and for the management of previously recorded content stored on the storage device 116. The Broadcast API Engine 114 and the PVR Engine 113 are connected by a bidirectional link. This link enables the recording, playback and management of programme content, as managed by the PVR engine 113 to be controlled from within an EPG application 115 running on the Broadcast API Engine 114.

REFERENCES Reference Reference ETSI EN 300 468 V1.7.1 Digital Video Broadcasting (DVB) Digital Broadcasting Systems for Television, Sound, and Data Services. Specification for service information (Sl) in Digital Video Broadcasting (DVB) Europeε Telecommunication Standards Institute ETSI.

ETSI TS 102 323 V1.2.1 Digital Video Broadcasting (DVB); Carriage and signalling of TV-Anytime information in DVB transport streams European Telecommunication Standards Institute ETSI.

ETSI EN 301 192 v1.4.1 Digital Video Broadcasting (DVB); DVB specification for data broadcasting. European Telecommunication Standards Institute ETSI.

ANSI/SCTE 65 2002 Service Information Delivered Out-Of-Band For Digital Cable Television.

Examples of the present invention have been described. It will be appreciated that variations and modifications may be made to the examples described within the scope of the present invention.

Claims

1. A method for controlling a device used with a broadcast receiver in which two broadcast data streams are used in conjunction; the method comprising: receiving a first data stream comprising compressed data appropriate for producing an electronic program guide; receiving a second data stream comprising uncompressed data appropriate for controlling time critical events; and controlling the device using a link provided between the first data stream and the second data stream provided by an identifier included within the first data stream and the second data stream.

2. A method according to claim 1 , wherein the electronic program guide is an MHEG electronic program guide.

3. A method according to claim 1 or 2, wherein the data appropriate for controlling time critical events is in the form of event information tables.

4. A method according to claim any of claims 1 , 2 or 3, wherein the identifier is a Content Reference Identifier.

5. A method according to any preceding claim, wherein the first data stream has a bit rate that is substantially constant.

6. A method according to any preceding claim, wherein the first data stream is a Digital Storage Media Command and Control Data Stream.

7. A method according to any preceding claim, wherein the second data stream is a service information data stream.

8. A method according to any preceding claim, wherein the identifier identifies a time critical event.

9. A method according to claim 8, wherein the time critical event includes a broadcast time of a programme.

10. A method according to claim 8 or 9, wherein the time critical event includes a start time and an end time of a programme.

11. A method according to any preceding claim, wherein the device is a recording device.

12. A method according to claim 11, further comprising setting the record time of the recording device based on information in the identifier.

13. A method according to any preceding claim, wherein the identifier consists only of a unique part or pseudo unique part and an instance identifier.

14. A method according to any preceding claim, wherein the first data stream comprises an electronic program guide application.

15. A method according to any preceding claim, wherein the first data stream comprises electronic program guide information.

16. A computer program for implementing the method of any preceding claim.

17. A computer comprising a computer program for implementing the method of any preceding claim

18. A broadcast device for broadcasting two broadcast data streams used in conjunction for controlling a device; the broadcast device broadcasting: a first data stream comprising compressed data appropriate for producing an electronic program guide; and a second data stream comprising uncompressed data appropriate for controlling time critical events; wherein the first data stream and the second data stream include an identifier providing a link between the first data stream and the second data stream to control the device.

19. A receiver for receiving two broadcast data streams used in conjunction for controlling a device; the receiver receiving: a first data stream comprising compressed data appropriate for producing an electronic program guide; and a second data stream comprising uncompressed data appropriate for controlling time critical events; wherein the first data stream and the second data stream include an identifier providing a link between the first data stream and the second data stream to control the device.

20. A system for controlling a device used with a broadcast receiver in which two broadcast data streams are used in conjunction; the system comprising a broadcast device and a receiver: the broadcast device broadcasting: a first data stream comprising compressed data appropriate for producing an electronic program guide; and a second data stream comprising uncompressed data appropriate for controlling time critical events; the receiver receiving the first data stream; and the second data stream; wherein the first data stream and the second data stream include an identifier providing a link between the first data stream and the second data stream to control the device.

21. A processor for processing two broadcast data streams used in conjunction; the processor comprising: a first decoder for decoding a first data stream comprising compressed data appropriate for producing an electronic program guide; a second decoder for decoding a second data stream comprising uncompressed data appropriate for controlling time critical events; and a controller for controlling a device using a link provided between the first data stream and the second data stream provided by an identifier included within the first data stream and the second data stream.

22. A recording device comprising the processor of claim 23.

23. A processor for processing two broadcast data streams used in conjunction; the processor comprising: a first encoder for encoding a first data stream comprising compressed data appropriate for producing an electronic program guide; and a second encoder for encoding a second data stream comprising uncompressed data appropriate for controlling time critical events; wherein a link is provided between the first data stream and the second data stream provided by an identifier included within the first data stream and the second data stream.

24. A method of broadcasting two broadcast data streams used in conjunction for controlling a device; the method comprising: broadcasting a first data stream comprising compressed data appropriate for producing an electronic program guide; and broadcasting a second data stream comprising uncompressed data appropriate for controlling time critical events; wherein the first data stream and the second data stream include an identifier providing a link between the first data stream and the second data stream to control the device.