FR2752351A1 - METHOD FOR INDEXING DATA IN A DIGITAL TELEVISION TRANSMISSION SYSTEM - Google Patents

Abstract

Method for indexing data in a digital television transmission system, in particular DVB. The transmission system comprises at least one receiver, which performs the following steps: extracting from a transmitted digital data stream hierarchically organized lists of networks, channels, services, events or descriptors of the same type; creating for each extracted list an array comprising an address pointer for each element of said extracted list, each address pointer pointing towards a memory area of said receiver in which additional information concerning each element is stored; referring to a given element in a list using a logic key composed of the juxtaposition of the index of said given element in the array to which it belongs and indexes of elements above said given element in said hierarchy. The invention can be used in the field of digital television (DVB, DSS...)

Description

Method of indexing data in a system of
digital television transmission
The invention relates to a method for indexing data, in particular service data, in a digital television transmission system. The invention applies to the receiver of such transmissions.

 Some digital television systems such as DVB (for Direct Video Broadcasting in English) provide for the transmission of data called multiplex services with video and audio data. these service data ('SI' data) comprise, for example, information on the hierarchical organization of the received digital stream or of another stream. This hierarchy can comprise several transmission networks, each network comprising several channels, each channel comprising various services, etc.

 A digital television receiver and decoder must be able to know this hierarchy in order to be able to access the transmitted data. However, the management of this hierarchy is problematic because it is on the one hand evolutionary by nature, on the other hand subject to standardization constraints that may not be adapted to the constraints of consumer products. For example, each element of the hierarchy (networks, channels, services, etc.) is identified using an identifier whose standardized length is relatively large, which can pose problems of storage and processing of these identifiers. . For example, to uniquely identify a service, eight bytes would be theoretically needed. These eight octets should be used for each reference to the service and should be stored many times by the receiver applications.

The subject of the invention is a data indexing method in a hierarchical digital television transmission system comprising at least one receiver, characterized in that it comprises, at the level of the receiver, the steps
extracting the digital data stream transmitted from at least one list of elements from the lists of networks, channels for a given network, services for a given channel or events for a given service,
storing a table comprising an address pointer for each particular element of the list, this pointer pointing to a memory zone of the receiver comprising additional information relating to said particular element,
- Use, by an application of said receiver, the index of a particular element in said table to designate said particular element.

 The receiver thus constitutes an image of at least a part of the hierarchy of the data to which it can have access. Lists of networks, channels, services, events, or other elements (bouquets, etc.) are stored and indexed by the receiver. Indexing significantly reduces the amount of memory needed to store identifiers. Once the relationship between an index and an element (or the data structure with information about that element) is established, the indexes will be used to refer to an element. The hierarchical nature of the data makes it possible to uniquely reference an element, for example a service, by juxtaposing the network, channel and service indexes.

 The use of the "logical key" constituted by the indexes decreases the execution time by avoiding the copying of the "physical key" into the processor stack at each function call and reducing the comparisons necessary during the route of the internal database during a data search.

 According to a particular embodiment, a list of elements is distributed over several tables of the same dimension, the last address pointer of a table pointing to the following table.

 The lists of elements are spread over several tables to facilitate management. The tables are linked by address pointers pointing to a possible following table.

 According to a particular embodiment, a table comprises a number of address pointers relating to a list item equal to a power of two.

 The use of a power of two makes it easy to obtain the array containing the pointer of a searched element by masking the number of appropriate bits in the index of this element.

Other features and advantages of the invention will become apparent through the description of a particular nonlimiting exemplary embodiment, illustrated by the attached figures forming an integral part of the present description.
FIG. 1 is a block diagram of a television receiver embodying the present exemplary embodiment,
FIGS. 2a to 2c are time diagrams of the exchanges taking place between an application, the data management module and the data source, in accordance with the present example,
FIG. 3a and 3b respectively is a state diagram illustrating the operation of a single, respectively permanent request,
FIG. 4 is a diagram of a screen of an application, namely an electronic program guide according to the present exemplary embodiment,
- Figure 5 is a diagram of the database maintained by the management module.

Note that for further information on the format and content of service data, MPEG and DVB sections and tables, refer to the following three documents:
(a) ETS 300 468 - Specification for Service Information (SI) in Digital Video Broadcast (DVB) Systems - January 23, 1996,
(b) ISO / IEC 13818-1 (1994) Generic Coding of Moving
Pictures and Associated Audio - Recommendation H.220, also known as "MPEG II Systems", and
(c) ETR 211 - Digital Broadcasting Systems for Television:
Implementation guidelines for the use of MPEG-2 systems; Guidelines on implementation and use of service information.

 FIG. 1 is a block diagram of an integrated DVB digital video broadcasting decoder-receiver.

 It is obvious that the invention is not limited to this physical environment, but can be easily adapted to another type of service data transmission.

 The decoder of FIG. 1 is connected to an antenna 1, itself connected to a tuner 2 of the decoder. The signal supplied by the tuner is demodulated by a demodulator 3. The demodulated data are corrected by a corrector circuit 4 and transmitted to a demultiplexer 5.

 The latter is for example a demultiplexer similar to that described in the French patent application 95 15767 filed December 29, 1995 in the name of THOMSON multimedia. The demultiplexer 5 comprises a certain number of filters programmed by a microprocessor 23 according to the various applications supported by the decoder. For the sake of clarity, only the most important connections of the microprocessor 23 are illustrated.

 The audio or video sections or packets filtered by the demultiplexer are stored in predefined areas of a buffer memory 6 for the attention of these applications. If necessary, the information is first decrypted by a decryption circuit 7 according to the rights of the user, before being stored in this buffer memory 6.

According to the present example, the applications are five in number: an audio decoder 16, a video decoder 17, a decoder
Teletext 18, an access control assembly (comprising the decryptor 7, a microcontroller tester 8 and a microprocessor card interface 9 connected in normal operating mode to a microprocessor card 10), as well as a management module service data.

 The decoder also comprises an infrared interface of a remote control 24, said interface being also connected to the microprocessor 23. The latter is connected to a memory 1 2 comprising the operating system as well as the resident or downloaded programs for implementing the applications. .

 A modem 1 3 connected to the switched telephone network 1 4 is also controlled by the microprocessor.

 A character generator 1 5 allows the generation of control menus or graphics relating to the parameters of the decoder or a particular application. The video signal generated by this character generator is multiplexed with one of the video signals from the video decoder 1 7 or the teletext decoder 1 8 to a first SCART socket (SCART socket in English) connected to a television 22 or a second Scart socket connected to a video recorder 21. The multiplexing circuit 20 is managed by the microprocessor 23.

 The invention relates more particularly to the operation of the service data management module. In the present case, this module is physically a microprocessor-managed program, although conceptually it is an application processing data packets, just like an audio or video decoder, for which circuits dedicated are used.

 The module is an interface between service data (MPEG and DVB sections and tables) and client applications (program guide, teleshopping, interactive games, etc.). It manages requests from client applications and maintains an internal database from the received service data.

 According to the present exemplary embodiment, the client application is a program guide also managed by the microprocessor.

 The management module provides client applications with a number of functions to formulate requests for information that applications require.

 Query functions have asynchronous operation.

The response to a request, if any, is notified to an application by the management module when this response is available. This requires the implementation of a mechanism for identifying a request function. For this purpose, an identifier is chosen by the application for each request sent and transmitted with this request. This identifier is linked to the response notification by the management module.

 FIGS. 2a to 2c illustrate the three cases of exchanges, following a request, between the client application, the service data management module and the source of these data, namely the demultiplexer-buffer-microprocessor assembly .

 Figure 2a is for the case where the internal database ("cache") contains the information required by the client application. The request of the latter is followed by a notification of the provision of this information. The information being in this case present in the database, the response notification is almost immediate. In this case, no data has to be transferred to or from the source.

 Figure 2b illustrates the case where the requested information does not appear in the internal database. In this case, the request of the client application is also followed by a notification by the management module to the application to inform it of the temporary unavailability of the information, and then an order sent by the client. management module at the data source. When the section or sections corresponding to the information sought are found in the data stream, demultiplexed and stored in the buffer memory, the source notifies the SI module that these sections are available. After reading and reformatting the section data, the management module in turn notifies the client application that the information sought is available. The module writes the information sought (which may be only part of the data of the section) into a buffer allocated during its initial request by the client application. This notification therefore arrives in this case less quickly than in the case 2a.

 According to one variant, the management module does not notify the unavailability of the information, but simply acknowledges receipt of the request.

 Figure 2c illustrates the case where the initial request such as that of Figure 2a specifies that changes in the information sought should be reported. In this case, the filters of the source which made it possible to extract from the data stream the data packet containing this information are maintained at the previous values instead of being deactivated. This type of request, called permanent request, will be described in more detail below.

According to the present exemplary embodiment, there are four types of request
(a) Single request
When such a request is addressed by the application to the management module, the latter makes available its resources (filter and memory) only until the transfer of the required data. Resources are immediately released.

(b) Single anticipated request
This query has the characteristics of the single query, but has a lower priority. The management module maintains two FIFO type memories, one for advance requests, the other for unanticipated requests. Expected pending requests are always processed after unanticipated requests.

(c) Standing request
The resources of the management module are maintained even after demultiplexing and transferring the required data. Whenever a change occurs in this data, a notification is sent to the application. The management module therefore performs systematic monitoring, until the application sends an interrupt command for this monitoring.

(d) Advance permanent application
This request is similar to the permanent query, but with a lower priority level.

 The priorities set out in the requests do not of course prejudge the actual order of reception of the data relating to these requests. This order also depends on factors such as the periodicity of each datum and the time at which the request is made in relation to that period.

 Figure 3a is a state diagram of a single request, while Figure 3b is a state diagram of a permanent request.

 Whenever an application makes a request, a request type must be associated with it.

 In the case of a permanent request, the data recovered in the stream are also stored in the internal database of the management module. This is not the case for the data extracted following a single request, for which no copy of the data is kept. When a new version of a table containing data relating to a permanent query is detected (that is, when the version ~ id parameter of the table changes), the appropriate data in this table are compared to the data in the database. of data. An update notification is only sent if at least one of these data has been modified.

The version identifier of the table is indeed modified whatever the modification occurred in the table, even if it concerns only data not requested by an application. This mechanism avoids redundant data transfer between the application and the management module.

 The choice of the type of request is left to the application. As an example of a decision criterion of an application as to the type of request, FIG. 4 is a diagram of a program guide screen.

The screen has two parts: a lower part 40 giving access to control functions by means of a remote control, and an upper part 41, comprising a list of events selected by said commands. For each event, the program guide displays the title, the name of the corresponding service, the start and end time.

The upper part 40 can display only part of the list of events. To access other events,
The user uses scrolling arrows on the remote control.

 When the program guide application sends the requests relating to the information of the events of the list to the management module, the requests concerning the events displayed first will be of the non-anticipated type, that is to say priority.

 This is indeed information that must necessarily be displayed. The requests relating to the other events of the list will be of anticipated type, and processed by the management module after the non-anticipated requests. It is indeed not sure that the application needs the corresponding information, because it is not certain that the user actually scrolls events if the information he seeks is among the events displayed initially. In order to speed up the display of these data in case they are required, they are preloaded. When the data in response to an advance request has been demultiplexed, the management module notifies this fact to the application that launched the request.

The transfer of data to a buffer made available by the application, however, does not take place until the application requests this transfer.

 One of the roles of the service data management module is to program the demultiplexer filters. To fulfill this function and to allow rapid access to the desired data, it maintains in accordance with the present example embodiment an image of the physical structure of the network (networks in English) to which it has access.

 Documents a and b define ten tables giving information on the configuration of the network or networks, bundles, services and events transmitted. The tables are identified by particular values of PID (Packet Identification Data in English) and table identifiers (table ~ id), whose values are defined by said documents. Each table contains a version identifier, to determine if a transmission from one table to another, the contents of this table has changed.

The table that interests us here is the table called NIT (for
Network Information Table). The NIT table includes information on a given transmission network, including the list of available services by transmission channel.

 The data management module builds internal indexing of available networks, channels, and services. When the decoder is turned on or when the NIT table is updated, a logical key is assigned to each of the available services. This key is the index of this service in the database maintained by the module.

In a DVB system, a service is uniquely locatable by the path including the following variables
- network ~ id (network identifier),
- couple (transport ~ stream ~ id; original ~ network ~ id),
- service ~ id (service identifier itself).

 The three variables are natural numbers encoded on 1 6 bits.

 Three types of lists are created: a list for networks, a list of channels for each network and a list of services for each channel.

 An item in the network list is created each time an NIT table with a new network is demultiplexed.

To do this, the transport packets whose PID is equal to Ox0010 are filtered. These packets indeed contain the NIT tables, further identified by a table variable ~ id. A 4-bit code is associated with each network, in the order of demultiplexing the corresponding tables. The code is the index of the address pointer of the structure containing the information relating to this network.

 The NIT table contains the list of channels for this network, as well as for each channel the list of available services.

 For each network in the network list, a channel list is created. Each element of a channel list is indexed using 5 bits. The list contains the address pointers of the structures containing the data specific to each channel. The logical key to identify a channel in the database consists of the 4 index bits of the network, followed by the 5 bits of the channel's index of that network.

 For each channel, a list of services is created, including the service identifiers described by the NIT table.

Each service in a list is indexed on 7 bits. The logical key of a service in the database thus comprises in all 16 bits: 4 network index bits, 5 channel and 7 service.

 An event of a service will be identified using the 16 bits designating this event (event_id variable of the table), to which will be added the 16 logical key bits of the associated service.

The structure of the database (excluding events) is organized according to the following structures

<tb><SEP> f3zlse <SEP> of <SEP> Data
<tb> AddressListNetworks
<tb><SEP> NetworkList
<tb> O <SEP> NetworkAddress
<tb> 1 <SEP> NetworkAddress
<tb> 2 <SEP> NetworkAddress
<tb> 3 <SEP> NetworkAddress
<tb> 4 <SEP> NetworkAddress
<tb> 5 <SEP> NetworkAddress
<tb> 6 <SEP> NetworkAddress
<tb> 7 <SEP> NetworkAddress
<tb><SEP> AddressNextTableNetworks <SEP>
<tb><SEP> Network
<tb> NetworkID <SEP>("network<SEP>id")
<tb> NetworkName <SEP>("network<SEP>name")
<tb> ChannelListAddress
<tb><SEP> 77 <SEP> List (: anal <SEP>
<Tb>

<tb> O <SEP> ChannelAddress
<tb> i <SEP> ChannelAddress <SEP>
<tb> 2 <SEP> ChannelAddress
<tb> 3 <SEP> ChannelAddress
<tb> 4 <SEP> ChannelAddress
<tb> 5 <SEP> ChannelAddress
<tb> 6 <SEP> ChannelAddress
<tb> 7 <SEP> ChannelAddress
<tb><SEP> AddressNextChannelsCanal <SEP>
<tb><SEP> Channel
<tb> ChannelID <SEP>("TranportStream ~ id")
<tb> IdentifierNetworkOrigine
<tb> (11OnginalNetwork <SEP> Id) <SEP>
<tb> AddressListServices
<tb><SEP> ServiceList <SEP>
<tb> O <SEP> ServiceAddress <SEP>
<tb> 1 <SEP> ServiceAddress
<tb> 2 <SEP> ServiceAddress
<tb> 3 <SEP> ServiceAddress
<tb> 4 <SEP> ServiceAddress
<tb> 5 <SEP> ServiceAddress
<tb> 6 <SEP> ServiceAddress
<tb> 7 <SEP> ServiceAddress
<tb><SEP> AddressNextTableServices <SEP>
<tb><SEP> Service
<tb> ServiceIdentifier <SEP>("service ~ id")
<tb> ServiceName <SEP>("service<SEP>name")
<tb> Status <SEP>("running ~ status") ...
<Tb>

 Variables whose name contains the term "Address" are pointers to memory areas corresponding to the beginning of a data structure.

 The other variables correspond to information extracted from the data stream. For ease of understanding, these variables are followed in parentheses and quotation marks of the denomination used in document (a).

 It should be noted that the lists of networks, channels and services are each organized in tables, each table being composed of, on the one hand, eight pointers to data structures of the network, channel or service type, and on the other hand, a pointer to a possible table with the rest of the list. This last pointer is null when there is no other table, that is to say when a table contains the last elements of a list. This last pointer is not indexed.

 The tables have eight elements, which corresponds to a power of two. This makes it possible to determine the array comprising a desired pointer by masking, in this case, the last three bits of the channel index.

 The Database table contains a pointer to the table containing the first part of the network list.

 The NetworkList array has pointers to the top eight networks. According to the present exemplary embodiment, there are at most two tables List Networks, containing the complete list of networks.

 The Network table includes information about a given network, as well as a pointer to the first table in the list of channels associated with that network.

 The structure of the other tables is similar to what has just been said. On the other hand, it is easy to extend it to events and other types of data.

 According to an alternative embodiment, queries relating to the data concerning the structure of the network, channels and services are queries of permanent type, with the aim of constantly updating the image of the network in the database.

 In their exchanges with the management module, the applications use only the logical keys. These are translated by the module into a memory address corresponding to the place where the information is stored.

 FIG. 5 is a diagram of the database of the management module in the case of the existence of a network, comprising two channels, each channel comprising itself two services.

 The application request table gives a list of the current requests made by the applications. According to the present example, the only current request is a permanent type request to retrieve the list of services present on a network.

 The request table of the management module comprises the primitive requests corresponding to the application requests. In the present context, a primitive request is a query that can be translated into a single filter at the level of the demultiplexer. In the present case, since two channels exist in the network, two primitive requests are necessary to translate the application request: a primary request by list of services or by channel. It is the management module that separates application requests into primitive requests.

 In the figure, the filters corresponding to each primitive request are to the left of the request table of the management module.

 It is assumed that at the instant shown in Figure 5, the service lists were acquired a first time. Given the permanent nature of the application request, the corresponding filters, as well as the contents of the database concerning this request are maintained.

 The numbers identifying the branches connecting a list and an item in this list correspond to the index (logical key) of this element in the list.

 The application is now looking for a list of current events in the network. There is one event in progress per service; this requires filtering the corresponding table 'EIT Present / Following' ("Event Information Table").

The request sent by the application includes, for a given service, the following parameters:
- a request identifier,
- the type of the request,
- the logical key of the service concerned,
a set of flags indicating which data of the event descriptors will be stored in the database,
a data structure intended to contain, on the one hand, the start time of the event, its duration, information on the access control and the name of the event, and on the other hand a pointer of address to the address from which the data identified by the flags will be stored.

 According to the present example, it is assumed that the requests relating to the current events of the first channel (TS id = 7) are not anticipated, whereas the queries relating to the current events of the second channel (TS id = 9) are anticipated. . This can for example be the case when only two events can be displayed at the same time, and the events of services 1 (Service ~ id = 1) and 3 (Service ~ id = 3) are displayed first on the screen.

 For information on current events, the application must launch four separate queries, which are already primitive queries. It will be assumed in the following that these requests are not permanent. Event data will therefore not be stored in the internal database once transferred to the client application.

 The management module reviews primitive requests and prioritizes non-anticipated requests.

The logical keys transmitted by the application will respectively
0.0.0
0.0.1 010
0.1.1
where the first digit represents the network, the second the pair (channel, home network) and the third the service.

Thanks to the lists maintained by the management module, the real identifiers can be sent to the demultiplexer, giving priority to the first two requests. The PID value of the EIT table (PlD = 0x0012) as well as the identifier of the table
ElT ~ present ~ following (table ~ id = 0x4E) are defined by the document (a) and are accessible via a correspondence table indexed by the query function.

 Using this information, one of the demultiplexer filters can be programmed.

 According to an alternative embodiment, in the case of insufficient memory, at least a portion of the stored data corresponding to the permanent advance requests is erased.

 According to an alternative embodiment, the type of a request in progress can be changed. A particular example envisaged consists in changing an unanticipated permanent type request into an anticipated permanent type request. A specific function for such a change is available for the client application.

 According to one variant, the management module itself generates certain requests relating to the network structure (in particular the list of networks and the associated channel lists) and maintains them permanently.

 It should be noted that the invention is not limited to the only transmission of data by satellite, terrestrial or cable, but can be implemented in any system where data or data packets periodically appear in the data stream. . This is particularly the case for recorded and replayed data streams.

Claims (3)

 A method of indexing data in a digital television transmission system with hierarchical organization comprising at least one receiver characterized in that it comprises, at the receiver, the steps  extracting the digital data stream transmitted from at least one list of elements from the lists of networks, channels for a given network, services for a given channel or events for a given service,  storing a table comprising an address pointer for each particular element of the list, this pointer pointing to a memory zone of the receiver comprising additional information relating to said particular element,  - Use, by an application of said receiver, the index of a particular element in said table to designate said particular element.  2. Method according to claim 1, characterized in that a list of elements is distributed over several tables of the same dimension, the last address pointer of a table pointing to the following table.  3. Method according to claim 2, characterized in that a table comprises a number of address pointers relating to a list item equal to a power of two.