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)

Applications Claiming Priority (2)

Publications (1)

Family

ID=39743723

Family Applications (1)

Country Status (3)

Family Cites Families (9)

• 2008
  • 2008-02-27 FR FR0851264A patent/FR2928065A1/fr not_active Withdrawn
• 2009
  • 2009-02-27 WO PCT/FR2009/050328 patent/WO2009112785A1/fr active Application Filing
  • 2009-02-27 EP EP09719421A patent/EP2253144A1/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events