WO2009112785A1 - Réception de metadonnees sur un terminal - Google Patents

Réception de metadonnees sur un terminal Download PDF

Info

Publication number
WO2009112785A1
WO2009112785A1 PCT/FR2009/050328 FR2009050328W WO2009112785A1 WO 2009112785 A1 WO2009112785 A1 WO 2009112785A1 FR 2009050328 W FR2009050328 W FR 2009050328W WO 2009112785 A1 WO2009112785 A1 WO 2009112785A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
stream
synchronization information
metadata
content
Prior art date
Application number
PCT/FR2009/050328
Other languages
English (en)
Inventor
Roberto Agro
Halim Bendiabdallah
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Priority to EP09719421A priority Critical patent/EP2253144A1/fr
Publication of WO2009112785A1 publication Critical patent/WO2009112785A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43074—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of additional data with content streams on the same device, e.g. of EPG data or interactive icon with a TV program
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/4722—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting additional data associated with the content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • H04N21/8133—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts specifically related to the content, e.g. biography of the actors in a movie, detailed information about an article seen in a video program
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests

Definitions

  • the present invention relates to the field of the reception of data of multimedia content, in particular digital television, via an extended network for example to the IP protocol (for "Internet Protocol").
  • IP protocol for "Internet Protocol”
  • metadata means digital data on, for example, the title of a work, the name of an artist or others (thus textual data), as well as data on the cover of a disc or the poster of a film (thus image data), or of other types of data on the multimedia contents (links url towards Internet sites, or any other type of data) .
  • the structure of an MPEG2 TS stream is simple and generic. It consists of both audio / video streams and data.
  • the stream also includes signaling tables prescribed by the MPEG2 and DVB standards (for "Digital Video Broadcast”). Among these signaling tables, a table can convey text data: the table called "EIT” (for "Event Information Table”).
  • This EIT table is used to transmit information about the current program and possibly a future program (duration, title of the program or others), but it can be used for other purposes, such as the display an advertising banner.
  • the EIT table is perfectly synchronized with the global stream broadcast and received on a terminal STB, which identifies easily and without significant delay the table EIT and treats upon receipt.
  • the audio stream from a broadcast Web site (or "Web Radio") managed by a content provider may be broadcast according to different protocols (for example "Shoutcast", “Microsoft Media Server", or “RealAudio").
  • the broadcast stream embeds more precisely, both an audio track and metadata (title of the current show, musical genre of the track being broadcast, image of the cover of the music album, or others) .
  • the stream is captured by player or player programs (such as Windows Media Player, Winamp, or others) that are capable of processing on the fly, such as an STB terminal of the aforementioned type, the audio track data and the metadata. , without complying with MPEG2 and DVB standards.
  • the EIT table is not particularly suitable, a priori, to receive and / or broadcast all types of information. Indeed, its content has a maximum length and is interpreted as a set of text data by a terminal STB. Thus, it is not intended to convey in an EIT table binary data such as metadata and in particular image data.
  • private tables by definition, have a proprietary format that can be designed for binary data transmission by a given broadcaster. As a result, the processing of these private tables involves a modification of the main software installed in memory of the terminal STB, due to the use of proprietary formats not specified by the standards.
  • the existing techniques do not allow to broadcast any type of metadata in a multimedia stream, to any terminal (and in particular a "non-proprietary" terminal).
  • the present invention improves the situation.
  • the method comprises a step in which one obtains: on the one hand, a succession of first data and, on the other hand, at least one set of second data, associated with the succession of first data, synchronization information with the succession of first data being attributed to the set of second data.
  • This synchronization information is then joined to the first data to form a stream that is adapted for communication with the decoding device, while the second data is reserved to be communicated to the decoding device separately from the adapted stream.
  • the synchronization information is then intended to be used by the decoding device, during the decoding of the aforementioned adapted stream, to formulate a request to obtain the set of second data.
  • the decoding device may be for example an STB terminal, or any other terminal that can receive multimedia data.
  • the coding can, in turn, be performed in a transcoding platform or directly downstream of a content delivery server.
  • the second content description data may typically include metadata associated with the content.
  • associated with the content means that such metadata are related to the content being broadcast and are therefore temporally associated with the content data. It can be for example text data (title of a movie, summary, etc.) accompanying the content data (video data for example). It can be "richer” data such as images (movie poster for example) or sound, or other.
  • the aforementioned synchronization information incorporated into the stream intended for the terminal, allows the latter to access metadata that are not present in this stream but which are temporally associated with the content being broadcast. Access to the metadata by the terminal can be done for example by downloading from a service portal, or by any other means of communication.
  • the aforesaid second data can be stored at least temporarily in a memory, remote from the decoding device but accessible by the latter to retrieve the second data.
  • This remote memory can be an integral part of a server from which the terminal downloads, for example, the second data via a second channel. distinct from the first channel through which the terminal receives the stream containing the content data.
  • This server can be presented as a service portal that can access a multiplicity of terminals.
  • the remote memory can then store at least one directory of game files of second data.
  • this remote memory can store a complex tree of directories containing metadata files and corresponding to a multiplicity of multimedia streams (television or radio or other) that can receive a terminal.
  • a change, by the coding device, of the synchronization information attached to the first data causes a new request to be transmitted by the decoding device, for example from this remote memory.
  • the synchronization information thus serves as a trigger signal (or "trigger" according to the English terminology) to trigger a procedure for obtaining a set of second data.
  • the present invention makes it possible, in particular, to convey metadata, whether textual and / or binary (picture, sound, or other), originating from a stream in a wide area network such as the Internet and to synchronize this metadata with the stream of content broadcast and received directly on an STB terminal, in accordance with current standards, such as MPEG2 TS and DVB.
  • current standards such as MPEG2 TS and DVB.
  • flow adapted to the terminal including the fact that the flow that receives the terminal may be in accordance with one of these standards. This avoids any modification of the main software of the terminal STB.
  • Compliance with the standards in the implementation of the invention makes its application very general and compatible with any type of terminal, including terminals simply comply with MPEG2 TS and DVB standards.
  • the flow adapted to the terminal includes event table data associated with the first data and, in particular, the aforementioned synchronization information is advantageously included in a predefined data field of an event table.
  • the synchronization information can be inserted among the data of the event tables to be joined to the first data and form the aforementioned flow, adapted to the processing by the decoding device.
  • an update by the coding device of the synchronization information is accompanied by an update of a section version number of the event table intended to convey the information. synchronization update.
  • Receiving an event table having a new event table section version number causes the decoding device to store and store new synchronization information contained in this event table, thereby , as indicated above, makes it possible to trigger a refresh by the decoding device of the metadata associated with the stream being decoded.
  • any decoding device conforming to this standard is designed to handle the information present in these tables. It is therefore sufficient to provide, in such a device, a function adapted to the processing of synchronization information. It is not necessary to modify the known, standardized functions that are implemented in such a decoding device.
  • the first and second data are present in a common initial stream.
  • the initial flow is then processed to extract: o on the one hand, the succession of first data and, o on the other hand, the set of second data, associated with the succession of first data.
  • the synchronization information is a function of a moment of extraction of the second data of the common stream.
  • the aforementioned trigger signal can be delivered by a module in charge of extracting the set of second data, as will be seen below with reference to FIG.
  • the synchronization information attached to the first data is updated when a new set of second data is available for communication with the decoding device.
  • the aforementioned trigger signal can still be delivered by a module in charge of extracting the set of second data, but the actual update of the synchronization information that the EIT tables contain is conditioned by the reception and the actual storage of the second data in the aforementioned remote memory, as will be seen below with reference to FIG. 4.
  • first data and the second data can still be derived from two distinct initial streams
  • provision can be made that the set of second data is now received by the coding device with a time association data with the first data.
  • the timing information is then defined by this time association data.
  • the present invention also relates to a method for decoding data received in a stream comprising at least first data, content.
  • an information, included in the flow, of synchronization of a set of second data, content description, associated with the first data is extracted from this stream and interpreted.
  • a request for obtaining the set of second data is formulated, this set of second data being obtained separately from the flow comprising the first data.
  • a second synchronization information extracted from the stream is compared with a first synchronization information received previously, and
  • the synchronization information includes an indication of the date of processing of the set of second data by the coding device.
  • a check is made to ensure that the second data received from the remote memory is up to date.
  • This verification is advantageously implemented with the decoding device (so as not to overload a coding device capable of delivering streams to a plurality of terminals).
  • the synchronization information extracted from the stream is compared with the instant of backup of the second data
  • the second data obtained is used as content description data associated with the content data received in the flux.
  • the decoding method can then be implemented by any decoding device of the aforementioned type (terminal STB or other media players).
  • a decoding device is simply equipped with a module comprising at least:
  • the coding method can be implemented by a data coding device intended to be transmitted to a decoding device, the data comprising:
  • the coding device comprises:
  • the present invention also relates to a computer program comprising instructions for implementing the coding method described above, when this program is executed by a processor.
  • It also relates to a computer program comprising instructions for implementing the decoding method set out above, when this program is executed by a processor.
  • FIG. 1 illustrates a first embodiment of a coding device 10, in which the synchronization information contained in the event tables is defined by a processing time of an initial stream comprising content data and metadata associated with these content data,
  • FIG. 2 illustrates the steps for recovering these metadata, implemented by a decoder device (terminal STB in the example represented), in this first embodiment,
  • FIG. 3 illustrates the initial flow comprising the content data (multimedia for example) and the associated metadata, the position of the metadata in the stream defining, in the first embodiment, a time stamp for temporally stamping the metadata,
  • FIG. 4 illustrates a second embodiment of the coding device, in which the injection of the event tables into the stream intended for the decoding device is conditioned by the provision of the metadata for a download from the memory remote above (in the example shown a directory (or "repository”) 7, accessible via a download portal 9),
  • FIG. 5 illustrates the metadata recovery steps implemented by the decoder device, in the second embodiment.
  • FIG. 6 illustrates a third embodiment of the coding device, in which at least a portion of the metadata is transmitted to the coding device separately from the initial stream of content data, and the event tables include temporal information on the coding device. moment of receiving this metadata from the coding device.
  • FIG. 1 represents a coding device 10 (or equivalently, transcoding) that can be integrated into a content distribution server or that can be implemented in the form of a transcoding platform.
  • This device 10 performs in particular the operations of processing and encoding flows and data to be transmitted to the terminal STB.
  • the device 10 will also be named afterwards “transcoding device” and the terminal STB “decoding device”.
  • the transcoding device 10 may be placed, for example, immediately downstream of a broadcast headend (not shown) and implanted thereto, or else implanted in a gateway between a wide area network (Internet type) and an IP network. (for "Internet Protocol") with dedicated specificities for the intended application.
  • FIG. 1 then represents the case where the transcoding device is implanted in a gateway between the extended network RE and an IP network, the reference C1 designating a channel of the IP network used for the transmission of the data streams in particular of content (audio and video). / or video) of the transcoding device 10 to the decoding device STB.
  • These content data called “first data” previously, are transported in packets of the multimedia stream ⁇ N (in MPEG2-TS or other format) via the channel C1.
  • a multimedia content provider (not shown in FIG. 1) is also connected to the extended network RE to send via this network RE the content data at least.
  • At least a portion of the MET metadata associated with this content data is not transported via the C1 channel. They are transported by another channel C2, established between the transcoding device 10 and the device STB, for example a channel with a higher bandwidth.
  • channel C1 for example in the context of a conventional TCP / IP transmission (for Transmission Control Protocol / Internet Protocof) .
  • the C2 and C1 channels are established independently of each other, in particular without any link between them. synchronization between them, the invention to establish on reception a synchronization link between data transmitted respectively via these two channels, from synchronization information inserted into the multimedia stream ⁇ N transmitted via the first channel.
  • Such synchronization information serves as a trigger signal (called “trigger” in the English terminology) in that, in case of a change in the value of this synchronization information, the decoding device is designed to trigger a procedure of obtaining a new set of metadata associated with the multimedia stream ⁇ N being decoded and available via the channel C2.
  • the transcoding device 10 within the meaning of the invention operating as a transcoder server for the terminal STB,
  • the decoding device represented, such as the terminal STB itself,
  • a metadata directory 7 connected to a portal 9, such as a service portal which can access the terminal STB via the channel C2 to retrieve MET metadata from the directory 7, and
  • an application module 8 managing in particular the communications with the portal 9 and being able to support, for example, the display of one or more elements defined by the metadata (title of a song or a movie, name of the or artist (s), movie poster or album cover, play time, etc.) on a human-machine interface such as a screen connected to the STB terminal.
  • the title data, artists, or other can be read by a man / machine interface such as a sound reproduction device.
  • the transcoding device 10 may comprise elements among which:
  • a demultiplexer 1 captures the stream ⁇
  • a decoder / encoder 2 of the audio / video stream ⁇ from the demultiplexer 1 converts this stream ⁇ into a stream ⁇ 'interpretable by the terminal STB;
  • the demultiplexer 1, by detecting the presence of a set of metadata at a given moment in the stream ⁇
  • this event table generator 5 EIT (or "EIT trigger"), on receipt of the time stamp signal ES, generates an event table including, as a trigger signal, the time stamp contained in the signal d ES timestamp.
  • the event tables generated in the first embodiment include, for example in a date field, a time stamp, constituting a time stamp (or "Time Stamp") corresponding to the time of reception of the metadata by the transcoding device 10, or, more precisely, at the time of processing the metadata to extract them from the initial stream).
  • this timestamp can be stored in another field of the event table.
  • an event table has several fields, such as the field indicating the content being broadcast or the field indicating the next content to be broadcast, or the respective fields indicating the times of broadcast of these contents.
  • the application module 8 of the terminal must regularly interrogate the contents of a cache memory of the terminal STB storing the last received EIT table to read the indicated time stamp and then detect a possible evolution of timestamp, which means that a new metadata set can be retrieved from directory 7.
  • an advantageous realization is to use another field of the EIT event table to insert a version number of EIT tables (a version identifier usually named "ID version"), during the generation of the tables by the module 5.
  • This implementation allows, in some terminals at least, to notify the application module 8, via a terminal mediator software (or "middleware"), a changing the table version number, so that the middleware, detecting such a change, reads and stores the contents of the received EIT table in a memory area, from which the application module 8 can read the predefined date field of the EIT tables and detect a possible evolution of the time stamp.
  • a terminal mediator software or "middleware”
  • the generator 5 creates a SEIT event table with a new version number and whose date field has a time stamp corresponding to this new set of metadata.
  • the injection module 6 then proceeds to the injection of the EIT tables thus formed on the fly by the module 5, and provides these tables in the form of PEIT data packets to the multiplexer module 3.
  • PEIT data packets whose concatenation represents the complete table in the MPEG2-TS format (the complete succession).
  • the module 5 Upon receipt of an ES timestamp signal including a timestamp different from that included in the previously received timestamp signal, the module 5 generates a new EIT table section (the term "section" complies with the MPEG2 TS standard). .
  • the generator 5 fills with the timestamp of the timestamp signal ES the appropriate part (in practice the "date" type field) of the SEIT table section, for example in the private part "Content Private Stream" of this section of table.
  • Each SEIT table section is formatted by the module 6 to be injected as a PEIT packet into the audio / video encoded stream ⁇ N.
  • each new set of metadata (extracted from the incident stream ⁇
  • the module 3 associates, in a single stream ⁇ N , the packets of PEIT tables and the stream ⁇ 'interpretable by the terminal STB. This module 3 then delivers a stream ⁇ N which complies with the usual standards for the management of the event tables EIT in a multimedia stream, for example MPEG2-TS or others.
  • the diffusion module 4 formats the normalized flow ⁇ N including the data packets of the EIT tables so that this stream ⁇ N is able to be communicated to the terminal STB (arrow 20 in FIG. 1) and interpreted by it.
  • event tables EIT for "Event Information Table”
  • Event Information Table Event Information Table
  • an advantage of the EIT table is that it is perfectly synchronized with the stream received on the terminal STB, which easily and without significant delay identifies the EIT table and processes it upon reception, since the current table is identified by a different version number of the version number of the previously processed table.
  • the following steps can advantageously be implemented by the transcoding device 10:
  • the application module 8 near the terminal STB, provides:
  • P provides in particular the metadata in a format appropriate to the terminal STB, via the service portal 9 and the channel C2 (TCP / IP type connection for example). It is described below how the terminal STB retrieves them from the portal 9.
  • the application module 8 which intervenes for the interpretation of the received data tables and for the metadata retrieval from the portal 9, is in the form of a computer program comprising instructions for implementing the following steps.
  • Each current timestamp, transmitted via at least one of the last EIT tables received, is stored in memory of the terminal STB by the application module.
  • the application module 8 (which may be in the form of a software brick cooperating with a middleware or "middleware" of the terminal STB) is notified by lower software layers of the terminal STB a change of version number ("ID version") of EIT table.
  • ID version a change of version number
  • the middleware reads and stores the contents of the received EIT table in a memory zone reserved for this purpose and accessible by the application module 8.
  • the application module 8 compares the timestamp indicated in the field date of the newly stored table in this memory area, with the current time stamp stored in memory of the terminal STB by the application module and, in case of evolution of this timestamp (timestamp of the last tables received after the stored date record), determines that new metadata must be retrieved from the directory 7 and makes a request to obtain the metadata of the directory 7, via the portal 9 (arrow 21 of Figure 1). This step will be described in detail below, with reference to FIG.
  • the fact of assigning a new version number to each EIT table associated with a new metadata set makes it possible to force the update of the metadata by the decoding device (terminal STB) for which the audio / video stream is intended ⁇ N containing this table.
  • This implementation ensures that the terminal STB, receiving an event table with a new version number, processes the table in question and, in particular, that the application module 8 reads the time stamp ES to possibly trigger a search of metadata by querying portal 9.
  • the lower software layers of some terminals may not be designed to notify new version numbers of EIT tables.
  • the application module 8 of these terminals performs a simple polling (or "polling") to check if a timestamp has changed in the EIT tables received.
  • the metadata are preferably stored in the form of an html page in the directory 7 (for example an html file named "index.html").
  • it is chosen to keep the same html file name and to overwrite the previous version of this file each time it is updated (each time new metadata are received).
  • the advantage of such an embodiment is that a terminal which has no information on a current file of metadata to be recovered (for example in the case initial commissioning or powering up of the terminal) queries the portal 9 by always requesting the same file name, a file always being available for download, under the same name, on the 9.
  • This implementation then makes it possible to always offer a metadata loading address to the terminal without the risk of generating an error message from the terminal.
  • the html file of the directory 7 stores the ES-html timestamp of the metadata recently updated.
  • the application module 8 compares the ES-html timestamp indicated in this html file with the ES-EIT timestamp indicated in FIG. the EIT tables recently received.
  • the terminal STB conventionally comprises an interpreter html ("browser") for analyzing the content of the html page from the portal 9.
  • the timestamp ES-html of the html file can simply correspond to the date of the last update of the html file (thus the date of overwriting of the previous file and creation of the new html file) .
  • a plurality of html files stored in the directory 7 may be provided and each file may be specific to a content provider (for example specific to an audio stream coming from the same radio).
  • the directory 7 then stores a plurality of files each associated with a particular stream (thus, for example, a given radio).
  • the html files can also be classified according to a directory tree in the case where, among several content providers, at least one and the same content provider broadcasts several distinct media streams.
  • the application module 8 can, again here, recover the metadata without difficulty
  • a timing routine can be triggered at the application module 8 to restart a query metadata retrieval periodically until they are obtained. Indeed, this routine can be active as long as the timestamp of the metadata available in the directory 7 remains lower than that of the EIT table and, for example, that a maximum number of repetitions of requests is not reached. If this number is reached, it can be decided that the metadata are lost or erroneous and that they will no longer be expected (so-called "Timeout" decision).
  • the architecture of the system will be optimized in the sense of the invention or the quality of the links between, for example, the directory 7, the gate 9 and the application module 8, to advantageously minimize this latency.
  • the application module 8 can be a computer program written for example in javascript language. It will be understood that the application module 8 may be a means that simply integrates into the standard hardware or software structure (in the "normalized" sense) of a conventional STB terminal.
  • the present invention makes it possible to transmit any type of metadata, textual or otherwise, to any STB terminal, whether compatible or not with a standard such as MPEG2-TS or DVB, or others.
  • a standard such as MPEG2-TS or DVB, or others.
  • the synchronization of the flow and the metadata is guaranteed while respecting the usual norms, and this on any type of terminal STB and without having recourse to any modification of the hardware or the software embarked of the terminal (or "firmware").
  • the terminal STB implements mediator software or "middleware", forming an application layer serving as a communication intermediary between different software components and / or processes implemented in the terminal STB.
  • mediator software or "middleware”
  • This "middleware” has a structure allowing interfacing with the application component 8 related to the processing of the EIT tables and synchronization information which, according to the invention, are transmitted via these tables.
  • a possible application of the invention may be within the framework of an Internet radio broadcasting service ("WebRadio" service), in particular for a content broadcaster such as "OrangeTV". Since the set of STB terminals complies with the MPEG2 DVB standard, streaming can be in MPEG1 Layer 2 format.
  • the original stream (which can be in Shoutcast MP3, MMS WMA, or other format) can not be broadcast directly on a terminal STB and requires adaptation to be addressed to the STB terminals park for this service.
  • This adaptation in particular the synchronization of the metadata on the terminal STB with the received stream, is achieved by the implementation of the invention, which allows a generic synchronization of metadata, textual or otherwise, applying to the architecture of the OrangeTV service broadcast.
  • the processing of the EIT tables at the terminal STB can be carried out as illustrated by way of example in FIG. receiving the multimedia stream ⁇ N received at a high rate (step S20), a demultiplexer of the basic software of the terminal STB (or “firmware”) processes this stream in step S21 to capture in step S22 a table of EIT event.
  • the EIT table is notified to the middleware of the terminal STB (or “middleware"), which transmits the event information associated with the EIT table to a higher software layer, application, such as the application module 8 of Figure 1.
  • the latter forms an http request (step S23), based on the content of the EIT table for the metadata associated with this table to be communicated to the terminal.
  • the terminal transmits this REQ request to the gate 9 of FIG. 1.
  • the application module 8 performs the consistency check (in particular the synchronization test described above by comparing the values of the timestamps).
  • a query timing and reformulation routine repeats step S23 a selected number of times.
  • the metadata MET can be retrieved from the directory 7 to be processed (step S25) with the STB terminal for image display or the like.
  • P in relation to the content data, defines the temporal association to be considered between a set of metadata and a portion of the content data stream.
  • P for example an audio stream, is constituted, in the first embodiment, by a succession of:
  • the metadata precedes, in the example shown, the content data, so that, on receiving a metadata set MT # n, it is possible to display the text data (title of a song, performer and / or composer) and image (disc display), during playback of DAT # n content data.
  • P it is possible to associate in the initial incident flow ⁇
  • the initial flow ⁇ IP always includes both content data and associated metadata (as shown in FIG. 3) that the terminal STB seeks to retrieve later on the portal 9.
  • the generated event tables include, as synchronization information for triggering the metadata update process, not a time stamp as is the case in the first embodiment, but a simple numerical value or counter, for example a binary digital value, inserted into one of the "date" type fields of the table.
  • the synchronization information is not immediately injected by the module 6 into the stream to be broadcast: the injection of the EIT tables carrying a new value of synchronization information is conditioned by the provision of the corresponding metadata on the directory 7.
  • the numerical value used as synchronization information changes each time a new set of metadata is available from the portal 7.
  • step S23 is formulated only once by the terminal STB of FIG. 4 and simply follows the reception of EIT tables with a new value of synchronization information in the predefined date field. It is ensured here that the available version of the metadata on the directory 7 is the one to be recovered and not an earlier version.
  • the application module 8 comprises at least: means implementing step S22 (of FIG. 2 or FIG. 5) for interpreting the synchronization information of the ES metadata carried by the event tables, and
  • step S23 means implementing step S23 to decide, based on this synchronization information, to formulate or not a REQ request for obtaining the metadata from the directory 7.
  • test T24 of FIG. 2 Since the test T24 of FIG. 2 is no longer necessary, means for implementing this test are not necessary for the application module 8 at least in this second embodiment.
  • the second embodiment consists in taking, as synchronization information for the EIT tables, the time stamp corresponding to the time of update of the metadata with the directory 7. timestamp changes each time a new set of metadata is available from the portal 7 and is thus able to trigger the execution, by the decoding device, of a process for updating the current metadata.
  • the time stamp signals ES come from the directory 7 and not from the demultiplexer 1.
  • the metadata (or at least certain metadata enriched with respect to text, such as images, sound or other) and the content data are conveyed by two distinct streams (referenced respectively ⁇ MET and ⁇
  • a module 12 which polls the SERM metadata server regularly (by polling) in order to retrieve possible new MET metadata (such as enriched metadata) and store them on the directory 7.
  • module 12 :
  • this third embodiment as in the second embodiment, it is possible to use as synchronization information not a time stamp, but a simple numerical value, for example a binary digital value, inserted in the one field predefined date of the table, as long as this numeric value changes each time a new set of metadata is available from portal 7.
  • a first implementation is to ensure that the SERM metadata servers and SERC content are synchronized with each other.
  • these two servers can for example consult the same SNTP date server (for "Simple Network Time Protocol"). So the metadata is provided by the SERM server and for the module 12 at the exact time of dissemination of the associated content data.
  • this module 12 delivers to the module 5 the information of the reception time of the metadata to form the timestamp of the EIT tables, and updates the metadata of the directory 7 without delay.
  • the metadata and the content data can be received by the terminal with an offset up to a few tens of seconds at most.
  • the metadata are available for the terminal STB before the content data.
  • Such an offset is not really penalizing nevertheless, especially for example for a piece of music that must last a few minutes: the user of the terminal may have the content description data just seconds (or less, in practice) after the beginning of the piece.
  • a variant of this implementation consists in reading, in the module 12, a scheduled broadcast date of the content associated with the metadata, this broadcasting date being able to be a data item accompanying the metadata received by the module 12 and read by this module 12 to issue the timestamp for the timestamp of the EIT tables.
  • the module 12 can receive a whole set of metadata provided for several hours of broadcast in the day (even for a whole day), with times of broadcast in the day content associated with this metadata. In this case, the module 12 regularly consults an SNTP date server for:
  • the SERM server must provide the metadata in time with respect to the broadcast times and it is preferable that the SERM server also synchronize on the same SNTP date server that the module 12 consults. On the other hand, in such a server implementation, it is not necessary for the content server SERC to consult the SNTP date server.
  • the synchronization module 11 receives from the directory 7 the metadata update information and controls, as in the second embodiment, the injection module 6 for the injection of the EIT tables with a new time stamp in the flow intended to to broadcasting.
  • this implementation is optional here and the synchronization module 11 is not necessary because the module 12 immediately communicates the metadata for their update to the directory 7.
  • the terminal STB can not be informed of an update of the metadata (by the EIT tables) only after their actual update on the directory 7.
  • the demultiplexing module 1 which now delivers only the content data and possibly simple metadata (for example text)
  • the other modules of FIG. 6 are in accordance with those of FIG. 4.
  • the demultiplexer 1 after extraction of the simple metadata, determines, in cooperation with a reader of these simple metadata, that enriched metadata can be obtained in association with the content data received from the SERM server.
  • the multiplexer 1 transmits this information to the module 12 (dashed arrow in FIG. 6) to interrogate the SERM server without delay (that is to say outside its regular polling routine).
  • the present invention is not limited to the embodiments described above as examples; it extends to other variants.
  • the coding device in the sense of the invention can be located immediately downstream of a broadcast headend, or immediately upstream of a terminal (intermediate reception module), or in cascade with a gateway (or "gateway") between two telecommunication networks.
  • the device can integrate the directory 7 and / or the portal 9, or optionally simply means for communicating the metadata to a remote memory 7, via an appropriate channel.
  • the present invention can also target a server comprising this remote memory 7, in the manner of the service portal 9 connected to the directory 7.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

La présente invention concerne une communication de données, notamment multimédias, à un terminal, les données comportant des premières données, de contenu, et des deuxièmes données, typiquement des métadonnées associées aux données de contenu. Au sens de l'invention, les données sont traitées pour séparer : d'une part, une succession de premières données et, d'autre part, au moins un jeu de deuxièmes données, associé à cette succession de premières données, en attribuant au jeu de deuxièmes données une information de synchronisation avec la succession de premières données. Cette information de synchronisation est jointe (3) aux premières données pour former un flux (ΦN) adapté pour une communication au terminal, tandis que les deuxièmes données (MET) sont réservées pour une communication séparée (C2) au terminal. L'information de synchronisation est alors utilisée, sur réception du flux adapté par le terminal, pour formuler une requête en vue d'obtenir le jeu de deuxièmes données.

Description

Réception de métadonnées sur un terminal
La présente invention concerne le domaine de la réception de données de contenu multimédia, notamment de télévision numérique, via un réseau étendu par exemple au protocole IP (pour « Internet Protocol »).
En particulier pour la transmission de métadonnées dans un flux numérique vers un terminal, par exemple un terminal STB pour « Set-Top Box », on connaît des systèmes notamment conformes à la norme MPEG2 TS ("TS" pour "transport stream").
On entend par "métadonnées" (ou "metadata" en anglais) des données numériques sur, par exemple, le titre d'une œuvre, le nom d'un artiste ou autres (donc des données textuelles), ainsi que des données sur la pochette d'un disque ou l'affiche d'un film (donc des données d'image), ou encore d'autres types de données sur le contenu multimédia (des liens url vers des sites Internet, ou tout autre type de données).
La structure d'un flux MPEG2 TS est simple et générique. Elle se compose à la fois de flux audio/vidéo et de données. Le flux comporte aussi des tables de signalisation prescrites par les normes MPEG2 et DVB (pour « Digital Video Broadcast »). Parmi ces tables de signalisation, une table permet de véhiculer des données de texte : la table dite « EIT » (pour « Event Information Table »). Cette table EIT est utilisée pour transmettre des informations sur l'émission en cours et éventuellement une émission à venir (durée, titre de l'émission ou autres), mais elle peut être utilisée à d'autres fins, comme par exemple l'affichage d'un bandeau publicitaire. La table EIT est parfaitement synchronisée avec le flux global diffusé et reçu sur un terminal STB, lequel identifie facilement et sans délai notable la table EIT et la traite dès réception.
On connaît aussi des systèmes de transmission des métadonnées dans un flux diffusé sur un réseau étendu tel que l'Internet, selon le protocole IP. A titre d'exemple, le flux audio issu d'un site WEB de radiodiffusion (ou « Web Radio ») gérée par un fournisseur de contenus peut être diffusé selon différents protocoles (par exemple « Shoutcast », « Microsoft Media Server », ou « RealAudio »). Le flux diffusé embarque plus précisément, à la fois, une piste audio et des métadonnées (titre de l'émission en cours, genre musical de la piste en cours de diffusion, image de la pochette de l'album de musique, ou autres). Le flux est capturé par des programmes lecteurs ou « players » (tels que Windows Media Player, Winamp, ou autres) qui sont capables de traiter à la volée, comme un terminal STB du type précité, les données de la piste audio et les métadonnées, sans toutefois respecter les normes MPEG2 et DVB.
On comprendra alors qu'il existe actuellement deux moyens pour transmettre les métadonnées provenant d'un flux Internet :
- une insertion des métadonnées dans des tables de type EIT,
- ou une insertion des métadonnées dans des tables privées (leur gestion n'étant pas normalisée et étant assurée par des règles "propriétaires").
Or, la table EIT, selon les spécifications de la norme DVB, n'est pas particulièrement adaptée, a priori, à recevoir et/ou diffuser tous types d'informations. En effet, son contenu a une longueur maximale et il est interprété comme étant un ensemble de données textuelles par un terminal STB. Ainsi, il n'est pas prévu de véhiculer dans une table EIT des données binaires telles que des métadonnées et notamment des données d'images. Par ailleurs, les tables privées, par définition, ont un format propriétaire qui peut être conçu pour une transmission de données binaires par un diffuseur donné. Il en résulte que le traitement de ces tables privées implique une modification du logiciel principal installé en mémoire du terminal STB, du fait de l'utilisation de formats propriétaires non spécifiés par les normes.
Ainsi, les techniques existantes ne permettent pas de diffuser tout type de métadonnées dans un flux multimédia, à destination de tout terminal (et en particulier d'un terminal "non propriétaire").
La présente invention vient améliorer la situation.
Elle propose à cet effet un procédé de codage de données destinées à être transmises à un dispositif de décodage, les données comportant :
- des premières données, de contenu, et
- des deuxièmes données, de description de contenu. Le procédé comporte une étape dans laquelle on obtient: o d'une part, une succession de premières données et, o d'autre part, au moins un jeu de deuxièmes données, associé à la succession de premières données, une information de synchronisation avec la succession de premières données étant attribuée au jeu de deuxièmes données.
Cette information de synchronisation est alors jointe aux premières données pour former un flux qui est adapté pour une communication au dispositif de décodage, tandis que les deuxièmes données sont réservées pour être communiquées au dispositif de décodage séparément du flux adapté. L'information de synchronisation est alors destinée à être utilisée par le dispositif de décodage, lors du décodage du flux adapté précité, pour formuler une requête en vue d'obtenir le jeu de deuxièmes données.
Le dispositif de décodage peut être par exemple un terminal STB, ou tout autre terminal pouvant recevoir des données multimédias. Le codage peut, quant à lui, être réalisé dans une plate-forme de transcodage ou directement en aval d'un serveur de diffusion de contenu.
Les deuxièmes données, de description de contenu, peuvent inclure typiquement des métadonnées associées au contenu. On entend par « associées au contenu » le fait que de telles métadonnées sont en relation avec le contenu en cours de diffusion et sont donc associées temporellement aux données de contenu. Il peut s'agir par exemple de données de texte (titre d'un film, résumé, etc.) accompagnant les données de contenu (données vidéo par exemple). Il peut s'agir de données « plus riches » telles que des images (affiche du film par exemple) ou du son, ou autre.
L'information de synchronisation précitée, incorporée dans le flux destiné au terminal, permet à ce dernier d'accéder à des métadonnées qui ne sont pas présente dans ce flux mais qui sont bien associées temporellement au contenu en cours de diffusion. L'accès aux métadonnées par le terminal peut s'effectuer par exemple par téléchargement auprès d'un portail de service, ou par tout autre moyen de communication. En termes plus génériques, dans une réalisation, les deuxièmes données précitées peuvent être stockées au moins temporairement dans une mémoire, distante du dispositif de décodage mais accessible par ce dernier pour récupérer les deuxièmes données.
Cette mémoire distante peut être partie intégrante d'un serveur auprès duquel le terminal télécharge par exemple les deuxièmes données via un deuxième canal distinct du premier canal par lequel le terminal reçoit le flux comportant les données de contenu. Ce serveur peut se présenter comme un portail de service auquel peuvent accéder une multiplicité de terminaux. La mémoire distante peut stocker alors au moins un répertoire de fichiers de jeux de deuxièmes données. Par exemple, cette mémoire distante peut stocker une arborescence complexe de répertoires comportant des fichiers de métadonnées et correspondant à une multiplicité de flux multimédias (de télévision ou de radio ou autre) que peut recevoir un terminal.
Dans une réalisation avantageuse, un changement, par le dispositif de codage, de l'information de synchronisation jointe aux premières données provoque une émission d'une nouvelle requête par le dispositif de décodage, par exemple auprès de cette mémoire distante. L'information de synchronisation sert donc de signal de déclenchement (ou "trigger" selon la terminologie anglo-saxonne) pour déclencher une procédure d'obtention d'un jeu de deuxième données.
Ainsi, la présente invention permet notamment de véhiculer des métadonnées, qu'elles soient textuelles et/ou binaires (d'image, de son, ou autre), provenant d'un flux dans un réseau étendu tel que l'Internet et de synchroniser ces métadonnées avec le flux de contenu diffusé et reçu directement sur un terminal STB, en étant conforme aux normes actuelles, telles que MPEG2 TS et DVB. Ainsi, on entend ci-avant par "flux adapté au terminal" notamment le fait que le flux que reçoit le terminal puisse être conforme à l'une de ces normes. On évite ainsi toute modification du logiciel principal du terminal STB. Le respect des normes dans la mise en œuvre de l'invention rend son application très générale et compatible avec tout type de terminal, notamment les terminaux simplement conformes aux normes MPEG2 TS et DVB. En particulier, il est proposé, dans un mode de réalisation, d'exploiter la technologie des tables d'événement (EIT), par exemple au sens de la norme DVB, pour y enregistrer l'information de synchronisation et transmettre ces tables EIT dans le flux comportant les données de contenu, via un premier canal, dit canal principal. En termes plus génériques, le flux adapté au terminal comporte des données de tables d'événement associées aux premières données et, en particulier, l'information de synchronisation précitée est avantageusement incluse dans un champ de donnée prédéfini d'une table d'événement. Ainsi, à chaque obtention d'un nouveau jeu de deuxièmes données, l'information de synchronisation peut être insérée parmi les données des tables d'événement pour être jointe aux premières données et former le flux précité, adapté au traitement par le dispositif de décodage.
Dans une réalisation avantageuse, une mise à jour, par le dispositif de codage, de l'information de synchronisation est accompagnée d'une mise à jour d'un numéro de version de section de la table d'événement destinée à véhiculer l'information de synchronisation mise à jour.
La réception d'une table d'événement comportant un nouveau numéro de version de section de table d'événement provoque la mémorisation et le traitement par le dispositif de décodage d'une nouvelle information de synchronisation contenue dans cette table d'événement, ce qui, comme indiqué plus haut, permet de déclencher un rafraîchissement par le dispositif de décodage des métadonnées associées au flux en cours de décodage.
Etant donné que la norme DVB stipule que les tables d'événement doivent être lues et traitées au fur et à mesure qu'un flux DVB est décodé, tout dispositif de décodage conforme à cette norme est conçu pour traiter les informations présentes dans ces tables. Il suffit donc de prévoir, dans un tel dispositif, une fonction adaptée au traitement des informations de synchronisation. Il n'est pas nécessaire de modifier les fonctions connues, normalisées, qui sont mises en œuvre dans un tel dispositif de décodage.
Dans un premier mode de réalisation, les premières et deuxièmes données sont présentes dans un flux initial commun. Le flux initial est alors traité pour extraire : o d'une part, la succession de premières données et, o d'autre part, le jeu de deuxièmes données, associé à la succession de premières données.
L'information de synchronisation est fonction d'un instant d'extraction des deuxièmes données du flux commun. Dans cette réalisation, le signal de déclenchement précité peut être délivré par un module en charge de l'extraction du jeu de deuxièmes données, comme on le verra plus loin en référence à la figure 1.
Dans un deuxième mode de réalisation où, par exemple, les premières données et les deuxièmes données peuvent être issues de deux flux initiaux distincts, l'information de synchronisation jointe aux premières données est mise à jour lorsque qu'un nouveau jeu de deuxièmes données est disponible pour une communication au dispositif de décodage. Dans cette réalisation, le signal de déclenchement précité peut encore être délivré par un module en charge de l'extraction du jeu de deuxièmes données, mais la mise à jour effective de l'information de synchronisation que comportent les tables EIT est conditionnée par la réception et le stockage effectifs des deuxièmes données dans la mémoire distante précitée, comme on le verra plus loin en référence à la figure 4.
Dans un troisième mode de réalisation où les premières données et les deuxièmes données peuvent encore être issues de deux flux initiaux distincts, on peut prévoir que le jeu de deuxièmes données soit reçu maintenant par le dispositif de codage avec une donnée d'association temporelle aux premières données. L'information de synchronisation est alors définie par cette donnée d'association temporelle. Ce mode de réalisation sera décrit en détails plus loin en référence à la figure 6.
La présente invention vise aussi un procédé de décodage de données reçues dans un flux comportant au moins des premières données, de contenu. En particulier, une information, incluse dans le flux, de synchronisation d'un jeu de deuxièmes données, de description de contenu, associées aux première données, est extraite de ce flux et interprétée. Au sens de l'invention, en fonction de l'interprétation de cette information de synchronisation, une requête d'obtention du jeu de deuxièmes données est formulée, ce jeu de deuxièmes données étant obtenues séparément du flux comportant les premières données.
Dans une réalisation, au décodage :
- on compare une deuxième information de synchronisation extraite du flux à une première information de synchronisation reçue antérieurement, et
- en cas d'évolution de l'information de synchronisation, on formule une requête pour obtenir un nouveau jeu de deuxièmes données.
Avantageusement, l'information de synchronisation comporte une indication de date de traitement du jeu de deuxièmes données par le dispositif de codage.
On entend ici par les termes génériques « date de traitement des deuxièmes données » :
- l'instant d'extraction de ces deuxièmes données, au codage, du flux initial comportant aussi les données de contenu, comme dans le premier mode de réalisation, ou - l'instant de stockage des deuxièmes données dans la mémoire distante et de leur mise à disposition pour le terminal, comme dans le deuxième mode de réalisation, ou
- la date issue de la lecture de la donnée d'association temporelle des deuxièmes données aux premières données, lorsqu'elles sont obtenues par deux flux distincts au codage, comme dans le troisième mode de réalisation.
Préférentiellement, au décodage, une vérification est menée pour s'assurer que les deuxièmes données reçues de la mémoire distante sont bien à jour. Cette vérification est avantageusement mise en œuvre auprès du dispositif de décodage (pour ne pas surcharger un dispositif de codage susceptible de délivrer des flux à une pluralité de terminaux). Ainsi, comme les deuxièmes données sont stockées au moins temporairement dans la mémoire distante et qu'un instant de sauvegarde est déterminé pour le stockage du jeu de deuxièmes données dans cette mémoire distante, sur réception du flux de données, au décodage:
- l'information de synchronisation extraite du flux est comparée à l'instant de sauvegarde des deuxièmes données, et
- au moins si l'information de synchronisation extraite du flux indique une date antérieure ou égale à l'instant de sauvegarde des deuxièmes données, les deuxièmes données obtenues sont utilisées en tant que données de description de contenu associées aux données de contenu reçues dans le flux.
Le procédé de décodage peut alors être mis en œuvre par tout dispositif de décodage du type précité (terminal STB ou autres lecteurs multimédias). Un tel dispositif de décodage est simplement équipé d'un module comportant au moins :
- des moyens pour interpréter une information de synchronisation des deuxièmes données, cette information de synchronisation étant reçue dans le flux comportant les premières données, et
- des moyens pour décider, en fonction de l'information de synchronisation, de formuler une requête d'obtention des deuxièmes données.
Le procédé de codage, quant à lui, peut être mise en œuvre par un dispositif de codage de données destinées à être transmises à un dispositif de décodage, les données comportant :
- des premières données, de contenu, et
- des deuxièmes données, de description de contenu. Le dispositif de codage comporte :
- des moyens d'obtention : o d'une part, d'une succession de premières données et, o d'autre part, au moins un jeu de deuxièmes données, associé à ladite succession de premières données,
- des moyens d'attribution au jeu de deuxièmes données d'une information de synchronisation avec la succession de premières données,
- des moyens pour joindre ladite information de synchronisation aux premières données pour former un flux adapté pour une communication audit dispositif de décodage, et
- des moyens pour communiquer ledit jeu de deuxièmes données au dispositif de décodage, séparément dudit flux adapté.
La présente invention vise aussi un programme informatique comportant des instructions pour la mise en œuvre du procédé de codage exposé ci-avant, lorsque ce programme est exécuté par un processeur.
Elle vise aussi un programme informatique comportant des instructions pour la mise en œuvre du procédé de décodage exposé ci-avant, lorsque ce programme est exécuté par un processeur.
D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels :
- la figure 1 illustre un premier mode de réalisation d'un dispositif de codage 10, dans lequel les informations de synchronisation que comportent les tables d'événement sont définies par un instant de traitement d'un flux initial comportant des données de contenu et des métadonnées associées à ces donnes de contenu,
- la figure 2 illustre les étapes pour récupérer ces métadonnées, mises en œuvre par un dispositif décodeur (terminal STB dans l'exemple représenté), dans ce premier mode de réalisation,
- la figure 3 illustre le flux initial comportant les données de contenu (multimédia par exemple) et les métadonnées associées, la position des métadonnées dans le flux définissant, dans le premier mode de réalisation, un horodatage pour estampiller temporellement les métadonnées,
- la figure 4 illustre un deuxième mode de réalisation du dispositif de codage, dans lequel l'injection des tables d'événement dans le flux destiné au dispositif de décodage est conditionnée par la mise à disposition des métadonnées pour un téléchargement à partir de la mémoire distante précitée (dans l'exemple représenté un répertoire (ou « repository ») 7, accessible via un portail de téléchargement 9),
- la figure 5 illustre les étapes de récupération de métadonnées mises en œuvre par le dispositif décodeur, dans le deuxième mode de réalisation, et
- la figure 6 illustre un troisième mode de réalisation du dispositif de codage, dans lequel une partie au moins des métadonnées est transmise au dispositif de codage séparément du flux initial de données de contenu et les tables d'événement comportent une information temporelle sur l'instant de réception de ces métadonnées auprès du dispositif de codage.
La figure 1 représente un dispositif de codage 10 (ou de façon équivalente, de transcodage) qui peut être intégré à un serveur de diffusion de contenu ou qui peut être réalisé sous la forme d'une plate-forme de transcodage. Ce dispositif 10 réalise en particulier les opérations de traitement et d'encodage des flux et des données destinés à être transmis au terminal STB. Dans cette optique, le dispositif 10 sera également nommé par la suite "dispositif de transcodage" et le terminal STB "dispositif de décodage".
Le dispositif de transcodage 10 peut être placé par exemple immédiatement en aval d'une tête de réseau de diffusion (non représentée) et implanté à celle-ci, ou encore implanté dans une passerelle entre un réseau étendu (type Internet) et un réseau IP (pour « Internet Protocol ») à spécificités dédiées pour l'application visée. La figure 1 représente alors le cas où le dispositif de transcodage est implanté dans une passerelle entre le réseau étendu RE et un réseau IP, la référence C1 désignant un canal du réseau IP utilisé pour la transmission des flux de données notamment de contenu (audio et/ou vidéo) du dispositif de transcodage 10 au dispositif de décodage STB. Ces données de contenu, appelées « premières données » précédemment, sont transportées par paquets du flux multimédia ΦN (au format MPEG2-TS ou autre) via le canal C1. Un fournisseur de contenus multimédias (non représenté sur la figure 1 ) est relié aussi au réseau étendu RE pour envoyer via ce réseau RE les données de contenu au moins.
Une partie au moins des métadonnées MET associées à ces données de contenu (appelées « deuxièmes données » précédemment) ne sont pas transportées via le canal C1. Elles sont transportées par un autre canal C2, établi entre le dispositif de transcodage 10 et le dispositif STB, par exemple un canal à bande passante plus réduite que le canal C1 , par exemple dans le cadre d'une transmission TCP/IP classique (pour "Transmission Control Protocol/Internet Protocof). Les canaux C2 et C1 sont établis indépendamment l'un de l'autre, notamment sans lien de synchronisation entre eux, l'invention visant à établir à la réception un lien de synchronisation entre des données transmises respectivement via ces deux canaux, à partir d'informations de synchronisation insérées dans le flux multimédia ΦN transmis via le premier canal.
Une telle information de synchronisation sert de signal de déclenchement (appelé "trigger" dans la terminologie anglo-saxonne) en ce que, en cas de changement de valeur de cette information de synchronisation, le dispositif de décodage est conçu pour déclencher une procédure d'obtention d'un nouveau jeu de métadonnées, associées au flux multimédia ΦN en cours de décodage et disponibles via le canal C2.
En référence à la figure 1 , correspondant au premier mode de réalisation, on a représenté en particulier :
- le dispositif de transcodage 10 au sens de l'invention opérant comme un serveur transcodeur pour le terminal STB,
- le dispositif de décodage représenté tel le terminal STB lui-même,
- un répertoire de métadonnées 7 relié à un portail 9, tel qu'un portail de service auquel peut accéder le terminal STB via le canal C2 pour récupérer des métadonnées MET du répertoire 7, et
- un module applicatif 8 gérant notamment les communications avec le portail 9 et pouvant être en charge, par exemple, de l'affichage d'un ou plusieurs éléments définis par les métadonnées (titre d'une chanson ou d'un film, nom du ou des artiste(s), affiche du film ou pochette du disque, instant de lecture, etc.) sur une interface homme/machine telle qu'un écran relié au terminal STB. En variante, les données de titres, artistes, ou autres peuvent être lues par une interface homme/machine telle qu'un dispositif de restitution sonore.
Dans le premier mode de réalisation, le dispositif de transcodage 10 peut comporter des éléments parmi lesquels :
- un démultiplexeur 1 capture le flux Φ|P issu du réseau étendu RE et dissocie ce flux Φ|P pour en extraire les métadonnées MET, d'une part, et le flux Φ de données de contenu (audio et/ou vidéo), d'autre part ;
- un décodeur/encodeur 2 du flux audio/vidéo Φ issu du démultiplexeur 1 transforme ce flux Φ en un flux Φ' interprétable par le terminal STB ;
- en outre, le démultiplexeur 1 , en détectant la présence d'un jeu de métadonnées à un instant donné dans le flux Φ|P, transmet un signal d'horodatage ES de cet instant donné à un générateur 5 de table d'événement ;
- ce générateur 5 de table d'événement EIT (ou "EIT trigger"), sur réception du signal d'horodatage ES, génère une table d'événement incluant, en tant que signal de déclenchement, l'horodate que comporte le signal d'horodatage ES.
En pratique, il peut être prévu d'insérer cette donnée dans un champ prédéfini, de type "date" d'une table d'événement EIT (pour « Event Information Table »). Ainsi, les tables d'événement générées dans le premier mode de réalisation comportent, par exemple dans un champ de date, une horodate, constituant une estampille temporelle (ou « Time Stamp »), correspondant à l'instant de réception des métadonnées par le dispositif de transcodage 10, ou, plus précisément, à l'instant de traitement des métadonnées pour les extraire du flux initial). Bien entendu, cette horodate peut être stockée dans un autre champ de la table d'événement. On rappelle en effet qu'une table d'événement comporte plusieurs champs, tels que le champ indiquant le contenu en cours de diffusion ou le champ indiquant le prochain contenu à diffuser, ou encore les champs respectifs indiquant les instants de diffusion de ces contenus.
En principe, le module applicatif 8 du terminal doit interroger régulièrement le contenu d'une mémoire cache du terminal STB stockant la dernière table EIT reçue pour lire l'horodate indiquée et détecter alors une éventuelle évolution d'horodate, ce qui signifie qu'un nouveau jeu de métadonnées peut être récupéré du répertoire 7. Pour éviter ces interrogations répétées, une réalisation avantageuse consiste à utiliser un autre champ de la table d'événement EIT servant à insérer un numéro de version de tables EIT (un identifiant de version nommé habituellement « version ID »), lors de la génération des tables par le module 5. Cette mise en œuvre permet, dans certains terminaux au moins, de notifier au module applicatif 8, via un logiciel médiateur du terminal (ou « middleware »), un changement de numéro de version de table, de sorte que le middleware, détectant un tel changement, lit et stocke le contenu de la table EIT reçue dans une zone mémoire, à partir de laquelle le module applicatif 8 pourra lire le champ de date prédéfini des tables EIT et détecter une éventuelle évolution de l'horodate. Cette mise en œuvre sera détaillée plus loin.
A chaque présence d'un nouveau jeu de métadonnées dans le flux initial Φ|P, le générateur 5 crée une table d'événement SEIT avec un nouveau numéro de version et dont le champ date comporte une horodate correspondant à ce nouveau jeu de métadonnées. Le module 6 d'injection procède ensuite à l'injection des tables EIT ainsi formées à la volée par le module 5, et fournit ces tables sous forme de paquets de données PEIT au module multiplexeur 3. On distingue :
- la « section de table » SEIT comprenant des données définissant la structure de la table complète (succession de bits) et donnant des informations sur cette table,
- des « paquets de données » PEIT dont la concaténation représente la table complète au format MPEG2-TS (la succession complète).
A réception d'un signal d'horodatage ES comprenant une horodate différente de celle incluse dans le signal d'horodatage reçu précédemment, le module 5 génère une nouvelle section de table EIT (le terme « section » étant conforme à la norme MPEG2 TS). En particulier, le générateur 5 remplit avec l'horodate du signal d'horodatage ES la partie adéquate (en pratique le champ de type « date ») de la section de table SEIT, par exemple dans la partie privée « Content Private Stream » de cette section de table.
Chaque section de table SEIT est mise en forme par le module 6 pour être injectée sous forme de paquet PEIT dans le flux encodé audio/vidéo ΦN. En particulier, à chaque nouveau jeu de métadonnées (extraites du flux incident Φ|P dans le premier mode de réalisation) correspond à la fois une nouvelle version de table EIT marquée (ou "taguée") et une nouvelle horodate.
Le module 3 associe, dans un même flux ΦN, les paquets de tables PEIT et le flux Φ' interprétable par le terminal STB. Ce module 3 délivre alors un flux ΦN qui respecte les normes habituelles pour la gestion des tables d'événement EIT dans un flux multimédia, par exemple MPEG2-TS ou autres. Le module de diffusion 4 met en forme le flux normalisé ΦN incluant les paquets de données des tables EIT afin que ce flux ΦN soit apte à être communiqué au terminal STB (flèche 20 de la figure 1 ) et interprété par celui-ci.
On rappelle que les tables d'événement EIT (pour « Event Information Table ») sont couramment utilisées (notamment selon les normes classiques telles que MPEG2 TS ou DVB, ou autres) pour transmettre des informations sur un flux multimédia en cours de réception (durée, titre de l'émission ou autres). En particulier, un avantage de la table EIT est qu'elle est parfaitement synchronisée avec le flux reçu sur le terminal STB, lequel identifie facilement et sans délai notable la table EIT et la traite dès réception, dès lors que la table courante est identifiée par un numéro de version différent du numéro de version de la table traitée précédemment.
Ainsi, parallèlement à la diffusion d'un flux audio/vidéo sur le terminal STB, les étapes suivantes peuvent avantageusement être mises en œuvre par le dispositif de transcodage 10 :
- après la capture du flux Φ|P, démultiplexage et extraction à la volée des métadonnées (module 1 en particulier),
- obtention, à partir du flux Φ|P, des horodates, extraites des signaux d'horodatage ES, associées aux métadonnées extraites (module 5 en particulier),
- création des tables d'événement EIT, contenant ces horodates, et multiplexage de ces tables avec le flux audio/vidéo, conformément aux normes habituelles,
- parallèlement, stockage régulier des métadonnées extraites du flux dans le répertoire 7, pour récupération par ailleurs par le terminal STB via le portail 9.
En particulier, le module applicatif 8, auprès du terminal STB, assure :
- le traitement des tables EIT présentes dans le flux ΦN reçu via le canal à relativement haut débit C1 (par rapport au canal C2),
- la récupération, auprès du portail de service 9, de nouvelles métadonnées MET indiquées par une nouvelle horodate dans les tables EIT reçues dans le flux ΦN, et
- la gestion de l'interface homme/machine précitée pour afficher ou jouer ces métadonnées.
Le répertoire 7 contenant les métadonnées MET qui sont tirées du flux initial Φ|P fournit en particulier les métadonnées dans un format approprié au terminal STB, via le portail de service 9 et le canal C2 (liaison de type TCP/IP par exemple). Il est décrit ci-après comment le terminal STB les récupère du portail 9.
Le module applicatif 8, qui intervient pour l'interprétation des tables de données reçues et pour la récupération des métadonnées auprès du portail 9, se présente sous la forme d'un programme informatique comportant des instructions pour mettre en œuvre les étapes suivantes.
Chaque horodate courante, transmise via l'une au moins des dernières tables EIT reçues, est stockée en mémoire du terminal STB par le module applicatif. Le module applicatif 8 (qui se peut se présenter sous la forme d'une brique logicielle coopérant avec un logiciel médiateur ou « middleware » du terminal STB) est notifié par des couches logicielles plus basses du terminal STB d'un changement de numéro de version (« version ID ») de table EIT. En cas de changement de numéro de version, le middleware lit et stocke le contenu de la table EIT reçue dans une zone mémoire réservée à cet effet et accessible par le module applicatif 8. Le module applicatif 8 compare alors l'horodate indiquée dans le champ date de la table nouvellement mémorisée dans cette zone mémoire, avec l'horodate courante stockée en mémoire du terminal STB par le module applicatif et, en cas d'évolution de cette horodate (horodate des dernières tables reçues postérieure à l'horodate stockée), détermine que de nouvelles métadonnées doivent être récupérées du répertoire 7 et formule une requête d'obtention des métadonnées du répertoire 7, via le portail 9 (flèche 21 de la figure 1 ). Cette étape sera décrite en détail plus loin, en référence à la figure 2.
Ainsi, le fait d'attribuer un nouveau numéro de version à chaque table EIT associée à un nouveau jeu de métadonnées permet de forcer la mise à jour des métadonnées par le dispositif de décodage (terminal STB) auquel est destiné le flux audio/vidéo ΦN contenant cette table. Cette mise en œuvre assure que le terminal STB, recevant une table d'événement avec un nouveau numéro de version, traite la table en question et, en particulier, que le module applicatif 8 y lise l'horodate ES pour déclencher éventuellement une recherche des métadonnées en interrogeant le portail 9.
Toutefois, les couches logicielles basses de certains terminaux peuvent ne pas être conçues pour notifier les nouveaux numéros de version de tables EIT. Dans ce cas, le module applicatif 8 de ces terminaux effectue une simple interrogation régulière (ou "polling") pour vérifier si une horodate a changé dans les tables EIT reçues.
Les métadonnées sont préférentiellement stockées sous la forme d'une page html auprès du répertoire 7 (par exemple un fichier html nommé « index.html »). Il est choisi, dans un exemple de réalisation, de conserver un même nom de fichier html et d'écraser la version précédente de ce fichier à chaque mise à jour (à chaque réception de nouvelles métadonnées). L'avantage d'une telle réalisation (stocker un seul fichier de même nom mais susceptible de mises à jour) est qu'un terminal qui n'a pas d'information sur un fichier courant de métadonnées à récupérer (par exemple dans le cas d'une première mise en service ou de mise sous tension du terminal) interroge le portail 9 en requérant toujours le même nom de fichier, un fichier étant toujours disponible pour un téléchargement, sous le même nom, sur le portail 9. Cette mise en œuvre permet alors d'offrir toujours une adresse de chargement de métadonnées au terminal sans risque de générer un message d'erreur auprès du terminal.
En outre, on stocke dans le fichier html du répertoire 7 l'horodate ES-html des métadonnées dernièrement mises à jour. Ainsi, lorsque le terminal STB récupère le fichier html comportant les métadonnées du répertoire 7 (flèche 22 de la figure 1 ), le module applicatif 8 compare l'horodate ES-html indiquée dans ce fichier html à l'horodate ES-EIT indiquée dans les tables EIT dernièrement reçues. De manière générale, le terminal STB comporte classiquement un interpréteur html ("browser") permettant d'analyser le contenu de la page html issue du portail 9.
Plus particulièrement, dans un exemple de réalisation, l'horodate ES-html du fichier html peut simplement correspondre à la date de dernière mise à jour du fichier html (donc la date d'écrasement du fichier précédent et de création du nouveau fichier html).
En outre, on peut prévoir une pluralité de fichiers html stockés dans le répertoire 7 et que chaque fichier soit propre à un fournisseur de contenu (par exemple propre à un flux audio issu d'une même radio). Le répertoire 7 stocke alors une pluralité de fichiers associés chacun à un flux particulier (donc, par exemple, à une radio donnée). On peut classer aussi les fichiers html selon une arborescence de répertoires dans le cas où, parmi plusieurs fournisseurs de contenu, au moins un même fournisseur de contenu diffuse plusieurs flux multimédias distincts.
En fonction de la comparaison des horodates ES-html et ES-EIT, contenues dans une table d'événement, d'une part, et dans un fichier html, d'autre part, menée par le module applicatif 8, trois cas peuvent se présenter : - si les horodates correspondent entre elles, les métadonnées sont valables et peuvent être associées au contenu en cours de diffusion,
- si l'horodate ES-html du fichier html indique une date postérieure à celle qu'indique l'horodate ES-EIT de la table EIT, ce qui signifie que les métadonnées correspondant à l'horodate ES-EIT ont été mises à jour avant que la notification ait été transmise via la table EIT (et donc que la version des métadonnées disponibles couramment sur le portail est issue d'une mise à jour plus récente que ce qu'indique la table EIT), le module applicatif 8 peut, encore ici, récupérer les métadonnées sans difficulté ;
- si l'horodate ES-EIT de la table EIT indique une date postérieure à celle qu'indique l'horodate ES-html du fichier html, ce qui signifie que la notification au moyen de la table EIT est arrivée au terminal STB avant même que les métadonnées associées ne soient mises à jour auprès du portail 9, une routine de temporisation peut être déclenchée au niveau du module applicatif 8 afin de relancer une requête de récupération de métadonnées périodiquement jusqu'à leur obtention. En effet, cette routine peut être active tant que l'horodate des métadonnées disponibles dans le répertoire 7 reste inférieure à celle de la table EIT et, par exemple, qu'un nombre maximum de répétitions de requêtes n'est pas atteint. Si ce nombre est atteint, il peut être décidé que les métadonnées sont perdues ou erronées et qu'elles ne seront plus attendues (décision dite de « Timeout »).
Cette méthode de comparaison suppose que les horodates ES-EIT et ES-html utilisées soient croissantes en fonction du temps. Toute autre grandeur croissante en fonction du temps est donc utilisable en lieu et place d'une horodate, par exemple un simple compteur incrémenté à chaque nouveau jeu de métadonnées.
Il convient de noter qu'il peut être introduit un temps de latence dans le traitement des données, pour la synchronisation des métadonnées avec le flux, du fait :
- de l'adaptation au terminal STB à faire éventuellement sur les métadonnées,
- du stockage des métadonnées dans le répertoire 7, et
- du téléchargement des métadonnées par le composant applicatif 8.
On optimisera l'architecture du système au sens de l'invention ou la qualité des liaisons entre, par exemple, le répertoire 7, le portail 9 et le module application 8, pour minimiser avantageusement ce temps de latence.
Le module applicatif 8 peut être un programme informatique écrit par exemple en langage javascript. On comprendra que le module applicatif 8 peut être un moyen s'intégrant simplement dans la structure matérielle ou logicielle standard (dans le sens « normalisée ») d'un terminal STB classique.
Ainsi, la présente invention permet de transmettre tout type de métadonnées, textuelles ou non, à un terminal STB quelconque, qu'il soit compatible ou non avec une norme telle que MPEG2-TS ou DVB, ou autres. La synchronisation du flux et des métadonnées est garantie tout en respectant les normes usuelles, et ce sur tout type de terminal STB et sans avoir recours à une modification quelconque du hardware ou du logiciel embarqué du terminal (ou « firmware »).
Par ailleurs, le terminal STB met en œuvre un logiciel médiateur ou "middleware", formant une couche applicative servant d'intermédiaire de communication entre différents composants logiciels et/ou processus mis en œuvre dans le terminal STB. Un tel middleware existe sur tout terminal STB classique décodant des flux DVB ou MPEG2-TS. Ce "middleware" présente une structure permettant un interfaçage avec le composant applicatif 8 lié au traitement des tables EIT et des informations de synchronisation qui, selon l'invention, sont transmises via ces tables. . Une application possible de l'invention peut se situer dans le cadre d'un service de diffusion de radio sur réseau Internet (service "WebRadio"), notamment pour un diffuseur de contenu tel que "OrangeTV". Etant donné que le parc des terminaux STB est conforme à la norme MPEG2 DVB, la diffusion des flux peut être au format MPEG1 Layer 2. Par conséquent, le flux original (qui peut être au format Shoutcast MP3, MMS WMA, ou autre) ne peut pas être diffusé directement sur un terminal STB et nécessite une adaptation pour être adressé au parc des terminaux STB pour ce service. Cette adaptation, en particulier la synchronisation des métadonnées sur le terminal STB avec le flux reçu, est réalisée par la mise en œuvre de l'invention, laquelle permet une synchronisation générique de métadonnées, textuelles ou non, s'appliquant à l'architecture de diffusion du service OrangeTV.
Le traitement des tables EIT, auprès du terminal STB, dans le cadre de ce service comme au sens général d'une mise en œuvre de l'invention, peut être réalisé ainsi qu'illustré à titre d'exemple sur la figure 2. Sur réception du flux multimédia ΦN reçu à haut débit (étape S20), un démultiplexeur du logiciel de base du terminal STB (ou "firmware") traite ce flux à l'étape S21 pour y capturer à l'étape S22 une table d'événement EIT. La table EIT est notifiée au logiciel médiateur du terminal STB (ou "middleware"), lequel transmet l'information d'événement associée à la table EIT à une couche logicielle supérieure, applicative, telle que le module applicatif 8 de la figure 1. En particulier, ce dernier forme une requête http (étape S23), sur la base du contenu de la table EIT pour que les métadonnées associées à cette table soient communiquées au terminal. Le terminal transmet alors cette requête REQ au portail 9 de la figure 1. Au test T24, le module applicatif 8 effectue la vérification de cohérence (en particulier le test de synchronisation décrit ci-avant par comparaison des valeurs d'horodates). Typiquement, tant que l'horodate de la table EIT est strictement supérieure à celle des métadonnées du répertoire 7 (flèche N en sortie de test), une routine de temporisation et de reformulation de requête réitère l'étape S23 un nombre choisi de fois. Si, en revanche, l'horodate de la table EIT est inférieure ou égale à celle des métadonnées du répertoire 7 (flèche O en sortie de test), alors les métadonnées MET peuvent être récupérées du répertoire 7 pour être traitées (étape S25) auprès du terminal STB pour un affichage d'image ou autre.
On décrit maintenant comment est assurée la synchronisation entre la récupération des métadonnées et la réception du flux audio/vidéo auprès du terminal STB, dans différents modes de réalisation.
Dans le premier mode de réalisation de la figure 1 , la position des métadonnées dans le flux initial Φ|P, relativement aux données de contenu, définit l'association temporelle à considérer entre un jeu de métadonnées et une partie du flux de données de contenu. En effet, en référence à la figure 3, le flux initial Φ|P, par exemple un flux audio, est constitué, dans le premier mode de réalisation, d'une succession de :
- données de contenu DAT#1 , DAT#2, ... , DAT#n-1 , DAT#n,
- et de données descriptives de ce contenu, telles des métadonnées MT#1 , MT#2, MT#3, ... , MT#n.
Les métadonnées précèdent, dans l'exemple représenté, les données de contenu, de sorte que, sur réception d'un jeu de métadonnées MT#n, il est possible d'afficher les données textuelles (titre d'une chanson, artiste interprète et/ou compositeur) et d'image (affiche du disque), pendant la lecture des données de contenu DAT#n. On relèvera alors qu'il est possible d'associer dans le flux initial incident Φ|P un signal d'horodatage ES#1 , ES#2, ES#3, ... , ES#n à chaque jeu de métadonnées MT#1 , MT#2, MT#3, ... , MT#n, suivant leur ordre d'apparition dans le flux. C'est ainsi qu'une horodate est obtenue à partir d'un signal d'horodatage à l'extraction de chaque jeu de métadonnées du flux initial incident Φ|P, par le module 1 de la figure 1 , et qu'un jeu de métadonnées MT#n est stocké en correspondance de cette horodate ES#n, dans le répertoire 7.
On se réfère maintenant à la figure 4 pour décrire un deuxième mode de réalisation.
Pour s'affranchir avantageusement de la routine de temporisation déclenchée par le module applicatif 8 et éviter ainsi de relancer une requête de récupération périodique des métadonnées jusqu'à leur obtention (comme décrit ci-avant en référence à la figure 2), il est proposé, dans un deuxième mode de réalisation, d'inclure un module de synchronisation 11 (figure 4) au dispositif de transcodage 10 de l'invention. Dans ce deuxième mode de réalisation, le flux initial ΦIP comporte toujours, à la fois, des données de contenu et des métadonnées associées (comme représenté sur la figure 3) que le terminal STB cherche à récupérer ultérieurement sur le portail 9. Toutefois, les tables d'événement générées comportent, en tant qu'information de synchronisation pour le déclenchement du processus de mise à jour des métadonnées, non pas une horodate comme c'est le cas dans le premier mode de réalisation, mais une simple valeur numérique ou compteur, par exemple une valeur numérique binaire, insérée dans un des champs de type "date" de la table. En effet, dans ce deuxième mode de réalisation, l'information de synchronisation n'est pas immédiatement injectée par le module 6 dans le flux à diffuser : l'injection des tables EIT portant une nouvelle valeur d'information de synchronisation est conditionnée par la mise à disposition des métadonnées correspondantes sur le répertoire 7. Dans ce deuxième mode de réalisation, la valeur numérique utilisée comme information de synchronisation change à chaque fois qu'un nouveau jeu de métadonnées est disponible auprès du portail 7. En cas d'utilisation d'une valeur numérique binaire comme information de synchronisation, celle-ci peut prendre successivement, par exemple, les valeurs "0" puis "1", à nouveau "0" puis "1 ", etc., chacune de ces deux valeurs étant interprétable - conformément au système de codage de date utilisé pour le champ date - comme une représentation d'une date particulière.
En pratique, lors de la réception de nouvelles métadonnées par le répertoire 7, une nouvelle version de fichier html est créée et l'information de création de nouvelle version est envoyée au module de synchronisation 11 , lequel autorise alors l'injection des tables EIT portant la nouvelle valeur d'information de synchronisation, dans le flux à diffuser. On rappelle que la génération et la diffusion des tables d'événement sont régulières (cycliques). Ici, tant que le module d'injection 6 n'a pas reçu du module de synchronisation 11 l'autorisation d'injecter des tables avec une nouvelle valeur d'information de synchronisation, le module 6 fournit au multiplexeur 3 les mêmes tables avec une ancienne valeur d'information de synchronisation.
Les autres modules de la figure 4 portant les mêmes références que ceux de la figure 1 ont sensiblement les mêmes fonctions dans le dispositif.
Il s'en suit, en référence maintenant à la figure 5, que, dans ce deuxième mode de réalisation, le test répété T24 de la figure 2 peut avantageusement être supprimé. La requête de l'étape S23 n'est formulée qu'une fois par le terminal STB de la figure 4 et fait simplement suite à la réception de tables EIT avec une nouvelle valeur d'information de synchronisation dans le champ date prédéfini. On est assuré ici que la version disponible des métadonnées sur le répertoire 7 est bien celle à récupérer et non pas une version antérieure.
On relèvera ainsi que le module applicatif 8 comporte a minima : - des moyens mettant en œuvre l'étape S22 (de la figure 2 ou de la figure 5) pour interpréter l'information de synchronisation des métadonnées ES que portent les tables d'événement, et
- des moyens mettant en œuvre l'étape S23 pour décider, en fonction de cette information de synchronisation, de formuler ou non une requête REQ d'obtention des métadonnées auprès du répertoire 7.
Comme le test T24 de la figure 2 n'est plus nécessaire, des moyens pour mettre en œuvre ce test ne sont pas nécessaires au module applicatif 8 au moins dans ce deuxième mode de réalisation.
On indique qu'une autre variante possible du deuxième mode de réalisation consiste à prendre, comme information de synchronisation pour les tables EIT, l'horodate correspondant à l'instant de mise à jour des métadonnées auprès du répertoire 7. En effet, une telle horodate change à chaque fois qu'un nouveau jeu de métadonnées est disponible auprès du portail 7 et est ainsi apte à déclencher l'exécution, par le dispositif de décodage, d'un processus de mise à jour des métadonnées courantes. Ainsi, dans cette variante, les signaux d'horodatage ES proviennent du répertoire 7 et non pas du démultiplexeur 1.
On comprendra alors que le traitement du flux commun initial des figures 1 et 4 et l'extraction à la volée des métadonnées pour remplir les tables EIT en fonction de l'instant de cette extraction n'est pas une réalisation nécessaire pour la mise en œuvre de l'invention.
Ainsi, dans un troisième mode de réalisation, en référence maintenant à la figure 6, les métadonnées (ou au moins certaines métadonnées enrichies par rapport à du texte, comme notamment des images, du son ou autres) et les données de contenu sont véhiculées par deux flux distincts (référencés respectivement ΦMET et Φ|P et issus par exemple de serveurs distincts SERM et SERC). En particulier, on prévoit un module 12 qui interroge régulièrement (par « polling ») le serveur de métadonnées SERM pour récupérer d'éventuelles nouvelles métadonnées MET (telles que des métadonnées enrichies) et les stocker sur le répertoire 7. Ainsi, en cas de réception de nouvelles métadonnées, le module 12 :
- transmet ces nouvelles métadonnées au répertoire 7 pour leur mise à disposition via le portail 9 et une mise à jour du fichier html correspondant, et
- fournit au générateur 5 un signal d'horodatage correspondant à l'instant de réception des nouvelles métadonnées afin que le générateur 5 crée une table d'événement comportant cette horodate.
Toutefois, dans ce troisième mode de réalisation comme dans le deuxième mode de réalisation, il est possible d'utiliser comme information de synchronisation non pas une horodate, mais une simple valeur numérique, par exemple une valeur numérique binaire, insérée dans l'un champ date prédéfini de la table, du moment que cette valeur numérique change à chaque fois qu'un nouveau jeu de métadonnées est disponible auprès du portail 7.
Il reste toutefois à s'assurer d'une correspondance temporelle effective entre un jeu de métadonnées et un contenu associé à diffuser. Cette correspondance était assurée, dans les premier et deuxième modes de réalisation ci-avant, par la position des métadonnées dans le flux initial (comme décrit ci-avant en référence à la figure 3). Dans le troisième mode de réalisation, plusieurs mises en œuvre sont possibles pour assurer cette correspondance temporelle.
Une première mise en œuvre consiste à faire en sorte que les serveurs de métadonnées SERM et de contenu SERC soient synchronisés entre eux. A cet effet, ces deux serveurs peuvent par exemple consulter un même serveur de date SNTP (pour « Simple Network Time Protocol »). Ainsi, les métadonnées sont mises à disposition par le serveur SERM et pour le module 12 à l'heure exacte de diffusion prévue des données de contenu associées. Dès réception, ce module 12 délivre au module 5 l'information de l'instant de réception des métadonnées pour former l'horodate des tables EIT, et met à jour les métadonnées du répertoire 7, sans délai.
Certes, de légers décalages temporels liés à des voies différentes de traitement peuvent intervenir entre les données de contenu et les métadonnées. Toutefois, les métadonnées et les données de contenu peuvent être reçues par le terminal avec un décalage jusqu'à quelques dizaines de secondes au plus. Dans ce troisième mode de réalisation, il peut être advenir en particulier que les métadonnées soient disponibles pour le terminal STB avant les données de contenu. Un tel décalage n'est pas réellement pénalisant néanmoins, notamment par exemple pour un morceau musical qui doit durer quelques minutes : l'utilisateur du terminal pourra avoir les données de description de contenu quelques secondes à peine (voire moins, en pratique) après le début du morceau.
Une variante de cette mise en œuvre consiste à lire, dans le module 12, une date de diffusion prévue, du contenu associé aux métadonnées, cette date de diffusion pouvant être une donnée accompagnant les métadonnées reçues par le module 12 et lue par ce module 12 pour délivrer l'horodate pour l'estampille temporelle des tables EIT. Dans une telle mise en œuvre, le module 12 peut recevoir tout un ensemble de métadonnées prévues pour plusieurs heures de diffusion dans la journée (voire pour toute une journée), avec des instants de diffusion dans la journée des contenus associés à ces métadonnées. Dans ce cas, le module 12 consulte régulièrement un serveur de date SNTP pour :
- tenir à jour une horloge,
- se référer à cette horloge pour surveiller les instants de diffusion indiqués, et - au moment de chaque instant de diffusion indiqué, délivrer un signal d'horodatage au module 5 pour l'estampille temporelle des tables EIT. Par ailleurs, le serveur SERM doit fournir à temps les métadonnées par rapport aux instants de diffusion et il est préférable que le serveur SERM se synchronise aussi sur le même serveur de date SNTP que celui que consulte le module 12. En revanche, dans une telle mise en œuvre, il n'est pas nécessaire que le serveur de contenu SERC consulte le serveur de date SNTP.
Le module de synchronisation 11 reçoit du répertoire 7 l'information de mise à jour des métadonnées et pilote, comme dans le deuxième mode de réalisation, le module d'injection 6 pour l'injection des tables EIT avec une nouvelle horodate dans le flux destiné à la diffusion. Toutefois, cette mise en œuvre est optionnelle ici et le module de synchronisation 11 n'est pas nécessaire car le module 12 communique sans délai les métadonnées pour leur mise à jour auprès du répertoire 7. Ainsi, le terminal STB ne peut être informé d'une mise à jour des métadonnées (par les tables EIT) qu'après leur mise à jour effective sur le répertoire 7.
Hormis le module de démultiplexage 1 qui ne délivre maintenant que les données de contenu et éventuellement des métadonnées simples (par exemple du texte), les autres modules de la figure 6 sont conformes à ceux de la figure 4.
On précise ci-après dans quel contexte il peut être avantageux de prévoir, comme indiqué précédemment, le transport de métadonnées « enrichies » dans un flux ΦMET séparé du flux Φ|P véhiculant les autres métadonnées et les données de contenu. Cette situation se présente lorsqu'un fournisseur de contenu communique à partir du serveur SERC des métadonnées simples, accompagnant les données de contenu, et ces métadonnées simples indiquent que des métadonnées enrichies (mais qui sont associées aux mêmes données de contenu) peuvent être récupérées en outre d'un autre serveur SERM. Dans une telle réalisation, le démultiplexeur 1 , après extraction des métadonnées simples, détermine, en coopération avec un lecteur de ces métadonnées simples, que des métadonnées enrichies peuvent être obtenues en association des données de contenu reçues auprès du serveur SERM. Le multiplexeur 1 transmet cette information au module 12 (flèche en traits pointillés de la figure 6) pour interroger le serveur SERM sans délai (c'est-à-dire en dehors de sa routine de polling régulier).
Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemples ; elle s'étend à d'autres variantes. Par exemple, le dispositif de codage au sens de l'invention peut se situer immédiatement en aval d'une tête de réseau de diffusion, ou immédiatement en amont d'un terminal (module de réception intermédiaire), ou encore en cascade avec une passerelle (ou "gateway") entre deux réseaux de télécommunication.
Le dispositif peut intégrer le répertoire 7 et/ou le portail 9, ou optionnellement, simplement des moyens de communication des métadonnées à destination d'une mémoire distante 7, via un canal approprié.
La présente invention peut viser aussi un serveur comportant cette mémoire distante 7, à la manière du portail de service 9 relié au répertoire 7.

Claims

REVENDICATIONS
1. Procédé de codage de données destinées à être transmises à un dispositif de décodage, les données comportant :
- des premières données (DAT#n), de contenu, et
- des deuxièmes données (MT#n, MET), de description de contenu, caractérisé en ce qu'il comporte une étape dans laquelle on obtient : o d'une part, une succession de premières données et, o d'autre part, au moins un jeu de deuxièmes données, associé à ladite succession de premières données, une information de synchronisation avec la succession de premières données étant attribuée au jeu de deuxièmes données, et en ce que ladite information de synchronisation est jointe (3) aux premières données pour former un flux (ΦN) adapté pour une communication audit dispositif de décodage, tandis que les deuxièmes données (MET) sont réservées pour être communiquées au dispositif de décodage séparément dudit flux adapté (ΦN), ladite information de synchronisation étant destinée à être utilisée par ledit dispositif de décodage, lors du décodage dudit flux adapté, pour formuler une requête pour obtenir ledit jeu de deuxièmes données.
2. Procédé de codage selon la revendication 1 , caractérisé en ce qu'un changement par le dispositif de codage de l'information de synchronisation jointe aux premières données provoque une émission d'une nouvelle requête par le dispositif de décodage.
3. Procédé de codage selon l'une des revendications 1 et 2, dans lequel les premières et deuxièmes données sont présentes dans un flux initial commun (Φip), caractérisé en ce que le flux initial est traité (1 ), pour extraire : o d'une part, la succession de premières données et, o d'autre part, le jeu de deuxièmes données, associé à ladite succession de premières données, et en ce que l'information de synchronisation est fonction d'un instant d'extraction des deuxièmes données du flux commun.
4. Procédé de codage selon l'une des revendications 1 et 2, caractérisé en ce que l'information de synchronisation jointe aux premières données est mise à jour lorsque qu'un nouveau jeu de deuxièmes données (MET) est disponible pour une communication au dispositif de décodage.
5. Procédé de codage selon l'une des revendications précédentes, dans lequel le flux adapté au terminal comporte des données de table d'événement (PEIT) associées aux premières données, caractérisé en ce que l'information de synchronisation est incluse (5) dans un champ de donnée prédéfini d'une dite table d'événement.
6. Procédé de codage selon la revendication 5, caractérisé en ce qu'une mise à jour, par le dispositif de codage, de l'information de synchronisation est accompagnée d'une mise à jour d'un numéro de version de section de la table d'événement destinée à véhiculer ladite information de synchronisation.
7. Procédé de codage selon l'une des revendications précédentes, caractérisé en ce que les deuxièmes données réservées sont stockées au moins temporairement dans une mémoire (7) distante du dispositif de décodage et accessible par ledit dispositif de décodage pour obtenir le jeu de deuxièmes données.
8. Procédé de décodage de données reçues dans un flux (ΦN) comportant au moins des premières données (DAT#n), de contenu, caractérisé en ce qu'une information, incluse dans le flux (ΦN), de synchronisation d'un jeu de deuxièmes données (MT#n), de description de contenu, associées aux première données, est extraite dudit flux (ΦN) et interprétée, et en ce que, en fonction de l'interprétation de ladite information de synchronisation, une requête d'obtention dudit jeu de deuxièmes données (MET) est formulée, lesdites deuxièmes données étant obtenues séparément du flux (ΦN) comportant les premières données.
9. Procédé de décodage selon la revendication 8, caractérisé en ce que :
- on compare (S22) une deuxième information de synchronisation extraite du flux (S21 ) à une première information de synchronisation reçue antérieurement, et
- en cas d'évolution de l'information de synchronisation, on formule (S23) une requête pour obtenir un nouveau jeu de deuxièmes données.
10. Procédé de décodage selon la revendication 9, dans lequel l'information de synchronisation comporte une indication de date de traitement des deuxièmes données par le dispositif de codage.
11. Procédé de décodage selon la revendication 10, caractérisé en ce que, les deuxièmes données étant stockées au moins temporairement dans une mémoire distante (7) et un instant de sauvegarde étant déterminé pour le stockage des deuxièmes données, sur réception du flux de données :
- l'information de synchronisation extraite du flux est comparée à l'instant de sauvegarde des deuxièmes données, et
- au moins si (T24) l'information de synchronisation extraite du flux indique une date antérieure ou égale à l'instant de sauvegarde des deuxièmes données, les deuxièmes données obtenues sont utilisées en tant que données de description de contenu associées aux données de contenu reçues dans le flux.
12. Procédé de décodage selon la revendication 11 , caractérisé en ce que si (T24) l'information de synchronisation extraite du flux indique une date postérieure à l'instant de sauvegarde des deuxièmes données, une temporisation (S23) est appliquée pour requérir un nombre de fois choisi des deuxièmes données auprès de la mémoire distante, jusqu'à obtenir des deuxièmes données dont l'instant de sauvegarde est antérieur ou égal à la date qu'indique l'information de synchronisation extraite du flux.
13. Dispositif de codage de données destinées à être transmises à un dispositif de décodage, les données comportant :
- des premières données (DAT#n), de contenu, et
- des deuxièmes données (MT#n, MET), de description de contenu, caractérisé en ce qu'il comporte :
- des moyens (1 ) d'obtention : o d'une part, d'une succession de premières données et, o d'autre part, au moins un jeu de deuxièmes données, associé à ladite succession de premières données,
- des moyens (1 ; 12) d'attribution au jeu de deuxièmes données d'une information de synchronisation avec la succession de premières données,
- des moyens (5, 6, 3) pour joindre ladite information de synchronisation aux premières données pour former un flux (ΦN) adapté pour une communication audit dispositif de décodage,
- des moyens (9, 7) pour communiquer ledit jeu de deuxièmes données (MET) au dispositif de décodage, séparément dudit flux adapté (ΦN), ladite information de synchronisation étant destinée à être utilisée par ledit dispositif de décodage, lors du décodage dudit flux adapté, pour formuler une requête pour obtenir ledit jeu de deuxièmes données.
14. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de codage selon l'une des revendications 1 à 8, lorsque ce programme est exécuté par un processeur.
15. Programme d'ordinateur (8) comportant des instructions pour la mise en œuvre du procédé de décodage selon l'une des revendications 9 à 12, lorsque ce programme est exécuté par un processeur.
16. Module (8) d'un dispositif de décodage de données reçues dans un flux (ΦN) comportant au moins des premières données (DAT#n), de contenu, caractérisé en ce qu'il comporte au moins :
- des moyens pour interpréter une information de synchronisation de deuxièmes données (MT#n), de description de contenu, associées aux première données, ladite information de synchronisation étant reçue dans ledit flux (ΦN) comportant les premières données, et
- des moyens pour décider, en fonction de ladite information de synchronisation, de formuler une requête d'obtention desdites deuxièmes données (MET), lesdites deuxièmes données étant obtenues séparément du flux (ΦN).
PCT/FR2009/050328 2008-02-27 2009-02-27 Réception de metadonnees sur un terminal WO2009112785A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP09719421A EP2253144A1 (fr) 2008-02-27 2009-02-27 Réception de metadonnees sur un terminal

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0851264 2008-02-27
FR0851264A FR2928065A1 (fr) 2008-02-27 2008-02-27 Reception de metadonnees sur un terminal.

Publications (1)

Publication Number Publication Date
WO2009112785A1 true WO2009112785A1 (fr) 2009-09-17

Family

ID=39743723

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/050328 WO2009112785A1 (fr) 2008-02-27 2009-02-27 Réception de metadonnees sur un terminal

Country Status (3)

Country Link
EP (1) EP2253144A1 (fr)
FR (1) FR2928065A1 (fr)
WO (1) WO2009112785A1 (fr)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999020049A1 (fr) * 1997-10-14 1999-04-22 Thomson Licensing S.A. Systeme permettant de formater et de traiter des donnees de programme multimedia et des informations de programme
EP1003304A1 (fr) * 1998-05-13 2000-05-24 Sony Corporation Systeme con u pour produire le contenu
JP2000197018A (ja) * 1998-12-25 2000-07-14 Toshiba Corp デジタル映像コンテンツにおける番組関連情報のｍｐｅｇトランスポ―トストリ―ムへの挿入方法、番組関連情報に対応するアプリケ―ションソフトウェアの起動方法及びデジタル映像コンテンツ送受信システム
US20020035726A1 (en) * 2000-04-17 2002-03-21 Corl Mark T. Information descriptor and extended information descriptor data structures for digital television signals
US20020188959A1 (en) * 2001-06-12 2002-12-12 Koninklijke Philips Electronics N.V. Parallel and synchronized display of augmented multimedia information
WO2003056828A1 (fr) * 2001-12-28 2003-07-10 Koninklijke Philips Electronics N.V. Acces transparent d'un intergiciel de television numerique de plate-forme locale multimedia de decodeur a un contenu video ip
WO2003092274A1 (fr) * 2002-04-24 2003-11-06 Thomson Licensing S.A. Synchronisation de signal auxiliaire pour l'insertion de sous-titrages codes
EP1443773A1 (fr) * 2003-01-31 2004-08-04 Thomson Licensing S.A. Dispositif et méthode de synchronisation en lecture de données vidéo et de données annexes
DE102006026316A1 (de) * 2006-06-02 2007-12-06 Deutsche Thomson Ohg Verfahren zur Vervollständigung einer elektronischen Programmzeitschrift

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999020049A1 (fr) * 1997-10-14 1999-04-22 Thomson Licensing S.A. Systeme permettant de formater et de traiter des donnees de programme multimedia et des informations de programme
EP1003304A1 (fr) * 1998-05-13 2000-05-24 Sony Corporation Systeme con u pour produire le contenu
JP2000197018A (ja) * 1998-12-25 2000-07-14 Toshiba Corp デジタル映像コンテンツにおける番組関連情報のｍｐｅｇトランスポ―トストリ―ムへの挿入方法、番組関連情報に対応するアプリケ―ションソフトウェアの起動方法及びデジタル映像コンテンツ送受信システム
US20020035726A1 (en) * 2000-04-17 2002-03-21 Corl Mark T. Information descriptor and extended information descriptor data structures for digital television signals
US20020188959A1 (en) * 2001-06-12 2002-12-12 Koninklijke Philips Electronics N.V. Parallel and synchronized display of augmented multimedia information
WO2003056828A1 (fr) * 2001-12-28 2003-07-10 Koninklijke Philips Electronics N.V. Acces transparent d'un intergiciel de television numerique de plate-forme locale multimedia de decodeur a un contenu video ip
WO2003092274A1 (fr) * 2002-04-24 2003-11-06 Thomson Licensing S.A. Synchronisation de signal auxiliaire pour l'insertion de sous-titrages codes
EP1443773A1 (fr) * 2003-01-31 2004-08-04 Thomson Licensing S.A. Dispositif et méthode de synchronisation en lecture de données vidéo et de données annexes
DE102006026316A1 (de) * 2006-06-02 2007-12-06 Deutsche Thomson Ohg Verfahren zur Vervollständigung einer elektronischen Programmzeitschrift

Also Published As

Publication number Publication date
EP2253144A1 (fr) 2010-11-24
FR2928065A1 (fr) 2009-08-28

Similar Documents

Publication Publication Date Title
US20230319229A1 (en) System and method for modifying media streams using metadata
EP2015587B1 (fr) Procédé de mémorisation d'un objet multimédia, structure de donnée et terminal associé
EP3381196B1 (fr) Procédé de synchronisation d'un flux audio alternatif
EP1695554B1 (fr) Procede et module de reception de signaux de television
FR2874472A1 (fr) Procede, article de fabrication et dispositif destines a mettre a jour un logiciel dans un dispositif individuel
FR2845555A1 (fr) Procedes de reception et de diffusion de television interactive et dispositifs associes
EP2692134A1 (fr) Procede d'acces a un service, notamment un portail web, par un terminal de restitution d'un flux multimedia
EP2979461A1 (fr) Generation et restitution d'un flux representatif d'un contenu audiovisuel
WO2020188219A1 (fr) Procédé de gestion de distribution de contenus multimédia et dispositif pour la mise en oeuvre du procédé
EP1579319A2 (fr) DISPOSITIFS ET PROCÉDÉS DE DÉCISION CONDITIONNELLE D'EXÉCUTION DE SERVICES REçUS ET DE CONSTITUTION DE MESSAGES D'INFORMATIONS ASSOCIÉS, DES SERVICES, ET PRODUITS ASSOCIÉS
EP1537747B1 (fr) Systeme et procede de synchronisation pour programmes audiovisuels, dispositifs et procedes associes
EP3942837A1 (fr) Procédé de gestion de contenus multimédia et dispositif pour la mise en oeuvre du procédé
WO2009112785A1 (fr) Réception de metadonnees sur un terminal
FR3069123A1 (fr) Procede de signalisation d'une substitution a un terminal, procede de substitution par un terminal, produits programme d'ordinateur, systeme et terminal correspondants.
WO2001091462A1 (fr) Dispositif et procede de synchronisation de programmes audiovisuels diffuses et d'informations complementaires
EP2451163B1 (fr) Procédé de mémorisation d'un objet multimédia, structure de donnée et terminal associé
FR3093885A1 (fr) procédé de gestion du téléchargement d’images associées à des sauts d’images susceptibles d’être réalisés lors d’une lecture accélérée d’un contenu multimédia.
FR2871639A1 (fr) Procede de gestion de programmes auxiliaires et recepteur et systeme correspondants
WO2019158837A1 (fr) Réception de flux représentatif d'un contenu multimédia
FR2930098A1 (fr) Procede de transmission simplifie d'un flux de signaux entre un emetteur et un appareil electronique
FR3036908A1 (fr) Procedes de diffusion d'un flux multimedia
FR2961999A1 (fr) Procede de lecture de donnees relatives a un contenu principal et dispositif de lecture associe
FR3041852A1 (fr) Procede et dispositif d'enrichissement d'une fonction pause de la lecture d'une sequence d'images

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09719421

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2009719421

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2009719421

Country of ref document: EP