WO2009007600A1 - Décodeur de flux dvb - Google Patents

Décodeur de flux dvb Download PDF

Info

Publication number
WO2009007600A1
WO2009007600A1 PCT/FR2008/051159 FR2008051159W WO2009007600A1 WO 2009007600 A1 WO2009007600 A1 WO 2009007600A1 FR 2008051159 W FR2008051159 W FR 2008051159W WO 2009007600 A1 WO2009007600 A1 WO 2009007600A1
Authority
WO
WIPO (PCT)
Prior art keywords
stream
data
dvb
decoder
video
Prior art date
Application number
PCT/FR2008/051159
Other languages
English (en)
Inventor
Thomas Serval
Olivier Giroud
Original Assignee
Baracoda
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 Baracoda filed Critical Baracoda
Publication of WO2009007600A1 publication Critical patent/WO2009007600A1/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/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
    • 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/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4126—The peripheral being portable, e.g. PDAs or mobile phones
    • H04N21/41265—The peripheral being portable, e.g. PDAs or mobile phones having a remote control device for bidirectional communication between the remote control device and client device
    • 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/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
    • 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/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H04N21/43637—Adapting the video stream to a specific local network, e.g. a Bluetooth® network involving a wireless protocol, e.g. Bluetooth, RF or wireless LAN [IEEE 802.11]
    • 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/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4385—Multiplex stream processing, e.g. multiplex stream decrypting
    • 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440218—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by transcoding between formats or standards, e.g. from MPEG-2 to MPEG-4
    • 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440263—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by altering the spatial resolution, e.g. for displaying on a connected PDA
    • 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/64315—DVB-H

Definitions

  • the present invention relates to digital television DVB (for "Digital Video BroadCasting"), whether it is the digital terrestrial television defined by the DVB-T standard (for "Terrestrial") or the mobile digital television defined by the DVB standard. -H (for "Handheld”).
  • DVB-H for "Handheld”
  • the DVB-H standard version V1.2.1 of November 2005, is presented in ETSI-TR-102377 available online on the ETSI INTERNET website.
  • the symbols and abbreviations used in this text, if not explicit, are defined in this standard.
  • the invention will be more specifically presented in the context of DVB-H mobile digital television, but the invention may be implemented in another context, for example that of DVB-T digital terrestrial television.
  • a mobile television service is intended to allow the visualization of the content of a video channel on a stand-alone, portable device comprising a screen, hereinafter referred to as a reader.
  • the reader can be a mobile phone, a personal assistant, a television, etc.
  • the purpose of the mobile television service is to allow the broadcasting of video content during the user's journey. This is to broadcast a video signal with a sufficient rate to ensure a picture of satisfactory quality on a screen whose size does not exceed 7 inches diagonally according to one of the current constraints of the DVB standard.
  • the reader is provided with a smart card identification, equivalent to a SIM card currently widely used in GSM phones, so as to manage access to video content by a reader and / or a identified user.
  • the smart card allows the distributor of the video content to control the access rights and possibly to decrypt the video stream.
  • DVB-H The general principle of DVB-H over DVB-T is to issue data packets periodically for an extremely short transmission time, while DVB-T transmits data in a substantially uniform and continuous manner. In this way, a portable player, synchronized with the transmitter and knowing the transmission period of the DVB-H packets, only works for a very short time corresponding to the reception of a data packet. Between receiving two successive packets, the reader is turned off. Its power consumption is reduced thus meeting the criterion of autonomy of the reader.
  • the DVB standard is a communication protocol and therefore relates to the physical layer of data transmission.
  • the data layer for its part, can comprise, for example, video data in MPEG2 format or IP datagrams encapsulating in turn video information that can be encoded in the MPEG4 format.
  • the reader must be able to be moved from one transmission network cell to another and the DVB-H data layer includes transmission error correction data to obtain a quality video image, even in areas of low coverage.
  • the present invention therefore relates more particularly to a decoder for audio / video streams in DVB format as well as adapted methods that allows local management, especially within an individual dwelling, or even a collective, or within a common audio stream.
  • the methods and the decoder are implemented in / in the form of a device receiving audio / video data over a DVB radio link as well as, preferably, audio / video data or other types (images, texts, instructions, computer programs ...) coming from the web (INTERNET) by radio or wire link.
  • This data is processed in the device where it is decoded and then re-encoded with data compression for local radio transmission (Wl-Fl or BLUETOOTH preferably) between the device and a terminal (or several) of a user (or several terminals a user or several users) where the received re-encoded data are decompressed to be restored visually and / or as sounds as appropriate.
  • the device is therefore similar to a transcoder (also called transcoder device or device transcoding) that manages the redistribution of audio / video streams locally.
  • the re-encoding may include encryption especially in the case of data to be protected (by copyright for example) and only an authorized terminal can decrypt.
  • the compression for diffusion over a local radio link is done according to an MPEG-4 AVC method.
  • the local / final radio link (Wl-Fl, WI-MAX, BLUETOOTH) between the transcoder device and the terminal (s) has a limited bit rate with respect to the initial streams upstream of the device (in particular DVB), a selection of flow (choice of a video / audio channel among those possible arriving on the device, in particular among the DVB channels) as well as a bandwidth management on the local / final radio link of the video / audio data channels is implemented.
  • implemented in the transcoder device in particular in the form of a real-time or near-real-time adaptation of the compression to the quality of the local / final radio link between the device and the terminal.
  • the compression is adapted to said current resolution of the terminal concerned.
  • the device can impose on its own initiative a reduction of the resolution to a given terminal.
  • the device In addition to its broadcasting capabilities to the user's terminal (s), video / audio (or other) DVB data and / or from the web, the device (and the methods of the invention) allows a recovery of information from the user to the web (in particular to a dedicated service platform or any other ad hoc site) via the transcoding device.
  • This source can be direct, in particular via a remote control operated by the user and communicating with the transcoder device (the remote control can be a dedicated device - conventional or advanced remote control - or a telephone - via BLUETOOTH for example- or a portable personal computer or any other tool that can communicate with the transcoder device).
  • This source may be indirect, in particular by taking information on what the user is seeing and / or listening, information on its absolute or relative position (in practice its terminal, or even its remote control or other), sensors specific to the terminal ...
  • DVB video / audio content and / or canvas is generally associated with information in the format -Electronic Program Guide-, EPG (or other format for those from the web: file name for example) concerning their identity (source, title for example) and this information can be returned to the canvas by the transcoding device. It is thus possible to follow the current and past choices of a user and to propose to him for the future of various audio / video contents adapted to these.
  • the invention consists of a DVB-format audio / video stream decoder, which comprises: means for receiving a primary data stream according to the DVB communication protocol having content data corresponding to a plurality of channels; means for retrieving, separating and processing the content data of said primary stream to produce a plurality of data sets, each data set corresponding to a channel of said primary stream; and, means for retransmitting a set of said data sets as content data from a secondary data stream in a local secondary radio communication protocol to a user terminal for restitution of the stream, the protocol secondary communication constituting a constraint on the flow rate of the secondary data stream with respect to that of the primary stream, said decoder comprising means for compressing the retrieved data set, said compression means being adaptive as a function of at least one criterion of quality of transmission of the local secondary radio communication.
  • At least one transmission quality criterion of the local secondary radio communication is chosen from: latency time between a restitution request and the restitution on the terminal,
  • Said compression means are adaptive as a function of at least one criterion for solving the restitution of the flow of the user terminal.
  • the communication protocol of the secondary stream is based on a wireless communication protocol, preferably WIFI or BLUETOOTH.
  • the communication protocol of the secondary stream is based on a wired communication protocol, preferably of the type Online Carrier Currents. It comprises DVB intra-stream navigation means making it possible to select the set of data actually retransmitted by said transmission means, from among said plurality of data sets.
  • Said navigation means comprise a remote part of the decoder box, preferably on a remote control or on a reader adapted to operate with said decoder.
  • the content data of said primary stream being encrypted, it comprises means for decrypting the data of the primary stream, so that the content of said re-transmitted secondary stream is decrypted.
  • Said transmission means allow the retransmission of a secure secondary stream.
  • the secondary communication protocol constitutes a constraint on the bit rate of the secondary data stream with respect to that of the primary stream, said decoder then comprising means for compressing the re-transmitted data set.
  • the invention also relates to a method for decoding a DVB data stream, comprising the steps of: sensing a primary data stream in the DVB format; extracting, separating and processing the content data of said primary stream so as to produce a plurality of individual streams of decoded data each corresponding to one of the channels of said primary stream; retransmitting one of said individual streams corresponding to a video channel by means of a local communication secondary protocol.
  • Said secondary protocol is based on a wireless secondary communication link of the WIFI or BLUETOOTH type.
  • the method further comprises decrypting said data.
  • Said decryption step is carried out before said retransmission step, and in that the method comprises an initial step of establishing a secure secondary communication link for the retransmission of said decrypted secondary stream.
  • It comprises a step of compressing said individual data streams before said secondary retransmission step.
  • the invention therefore relates to a device and a method for decoupling the decoding function of the DVB data stream and the display function. For this, all or part of the decoded video data is re-transmitted by means of a secondary link to the player displaying this video content.
  • DVB-T in particular because of problems of UHF band antenna integration and penetration losses in homes or apartments, the reception area for acceptable operation inside buildings is limited.
  • the regulatory body In the case of Digital Terrestrial Television, French TNT, the regulatory body has favored a maximum number of channels per Multiplex by specifying a sophisticated modulation (64 QAM 2/3) offering the maximum bit rate (-24 Mbit / s per second).
  • MUX in return for a very low reception sensitivity.
  • the announced TNT coverage concerns a fixed reception with an antenna on the roof at a height of 10m.
  • the coverage radius is limited to approximately 15% (with a single antenna) or at best 20% (with two diversity antennas) of the radius.
  • Wl-Fl or BLUETOOTH of the audio / video signal received in TNT at a window would eliminate the losses caused by the walls and partitions and thus achieve a radius of coverage inside buildings larger and closer to the fixed coverage radius announced. It should be noted that this problem is identical for DVB-H transmissions.
  • FIG. 1 represents in the form of a block diagram, the general architecture implemented according to the invention
  • FIG. 2 represents in the form of a block diagram, the general architecture of the implementation of the invention in the case of a DVB-T WI-FI transcoder device,
  • FIG. 3 represents in the form of a block diagram, the architecture implemented of the invention in the case of a DVB-H BLUETOOTH transcoder device,
  • FIG. 4 represents in the form of a block diagram, the general architecture of the implementation of the invention in the case of a DVB-T transcoder device Wl-Fl for broadcasting to a computer (PC),
  • PC computer
  • FIG. 5 represents in the form of a block diagram, an architecture equivalent to that of FIG. 4, but in the case where encrypted streams / channels must also be broadcast to one or more user terminals,
  • FIG. 6 shows a block diagram of the detailed architecture of an exemplary embodiment of a transcoder device according to the invention
  • FIG. 7 shows a sequence diagram of the channel discovery phase
  • FIG. 8 shows a sequence diagram of an initial connection request
  • FIG. 9 shows a sequence diagram of an end of connection request
  • FIG. 10 shows a sequence diagram of a request for change of channel
  • Figure 1 1 shows a sequence diagram of the client-server dialogue. These figures are for the most part flow charts consisting of block diagrams whose function is specified within the corresponding frame.
  • the example of implementation shown in Figure 1 allows the reception in a decoder 1 of a DVB radio upstream stream by an antenna 3 and an audio / video channel is redistributed by a wireless local radio connection type WIFI or BLUETOOTH to 20.
  • the decoder 1 distributes a secondary data stream in a coverage area "lit" by the local radio signal of about 300 meters around the decoder in the case of the Wl-Fl.
  • the decoder is preferably connected to the mains by a power cable 2.
  • a remote control 30 remote control of the decoder 1. The other elements implemented will be described in more detail later.
  • the transcoder device may be in the form of a dedicated box or be integrated with an audio / video broadcasting apparatus such as a TNT decoder, a satellite demodulator, a television set or a video projector.
  • an audio / video broadcasting apparatus such as a TNT decoder, a satellite demodulator, a television set or a video projector.
  • it is in the form of a computer card to be inserted in a computer or a housing ("dongle") to be connected to an input of a personal computer.
  • the transcoder device is in the form of a DVB-T receiver Wl-Fl which goes along a window of a house for DVB reception and redistributes audio / video streams by link WIFI in the house on all types of screen terminals.
  • the technical issue is the ability to filter within a multiplexed 24 Mbit / s broadcast signal, DVB reception for example, a single 2 Mbit / s program stream, the Wl-Fl, and automatically adapting the bit rate. of this stream to the display screen of the chosen terminal using a robust and efficient re-encoding.
  • SVC Scalable Video Coding
  • zapping symbolizes the possibility of remote control in return between the terminal (or a remote control) and the receiver.
  • the encryption and / or decryption represented in the transcoding device are optional, in particular the decryption can be omitted in the case of a broadcast of one or / or strings in the clear.
  • the decryption is performed in the user terminal, including the final transmission (link Wl-Fl local in this case in Figure 2) can be done with or without own encryption.
  • the transcoder device is in the form of an autonomous DVB-H BLUETOOTH receiver, having an authentication mechanism, for example a sim card, which receives 7.37 Mbit / s streams. s, splits them into 384 kbit / s channels and returns a channel to a BLUETOOTH terminal with display capability for audio and / or video playback.
  • This terminal can be a bluetooth mobile phone equipped with a suitable software "player" ("player").
  • This rendering software can incorporate an integrated software remote control.
  • a functional diagram of such a receiver is given in FIG. 3.
  • the encryption and / or decryption represented in the transcoding device are optional, in particular the decryption can be omitted in the case of broadcasting a / from strings. clear (or for encrypted channels /, the decryption being performed in the user terminal), including the final transmission (local BLUETOOTH link in this case in this Figure 3 can be performed with or without own encryption.
  • the transcoder device is in the form of a DVB-T receiver Wl-Fl for broadcasting TNT channels in SD light broadcast by Wl-Fl broadcast on a personal computer.
  • This transcoding device comprises a DVB-T demodulator receiver (tuner) and is compatible in particular with the following data formats: DVB-T; MPEG-2 SD (video); MPEG-1 Layer 2 stereo, AC3, MPEG-2 AAC, MPEG-4 HE AAC, Enhanced AC3, AC3 (audio); Ceefax and DVB-Sub (subtitles); ElTp / factual & other, EITs (program data).
  • the transcoder device is capable of performing a complete scan of the UHF band to search for the strings, to schedule them according to the signaling tables, and to memorize this technical information.
  • the Tuner / Demodulator can receive commands to tune to a particular frequency and channel.
  • DVB-H tuner / demodulator In the case of a DVB-H tuner / demodulator, the compatibility is possible in particular the following data formats: DVB-H; H264 QVGA (video); HE-AAC V2 (audio), DVB-IPDC (Electronic Service Guide).
  • FIG 5 functional extension of the transcoder device of Figure 4, presents a device for the broadcast of encrypted channels. It includes a DVB stream decryption and encryption function for the stream of the local radio link, the terminal having a suitable decryption means.
  • the number of input tuners / demodulators can be any (1, 2, 3, 4 or more).
  • the transcoder device is capable of transmitting by Wl-Fl a number of TV streams which is equal to the number of tuners / decoders.
  • the audio / video transcoding capabilities of the transcoder device must therefore be modular to accommodate any number of tuners / demodulators.
  • This functionality is implemented in the form of a transcoding chip, and must allow to manage at least one input TV stream and to transcode it. In the case where the chip can manage only one stream (a single chain) we will implement as much chip as tuners / demodulators.
  • a transcoding device of this type may comprise 3 tuners / demodulators and 3 transcoding chips, in addition to an integrated hard disk.
  • the chip can transcode any video stream from the tuner / demodulator to an MPEG-4 AVC format in this example.
  • the chip is able to transcode any incoming audio stream to an mp3 or AAC audio stream at a reduced rate.
  • the chip is capable of transcribing any subtitle stream to a subtitle stream compatible with the user terminal receiving the signal. local radio Wl-Fl in this case (streaming text 3GPP for example).
  • the user terminal is here a PC with a dedicated playback software ("Player") installed.
  • the PC can make it possible to consult the list of the available channels and to ensure the remote control (including "zapping" on a desired channel) via a web browser or video player (VLC type).
  • the PC can output video / audio / subtitle streams, select the audio track and subtitle to render. If the PC is not suitable for rendering an audio track (for example, AC3), it must be configured to select an MPEG-2 audio stream of the same language.
  • the transcoding device has a priori (input or prior programming) or recognizes (automatic recognition) the decoding capabilities of each user terminal so that the device can provide a compatible video / audio stream, and of maximum quality (especially in display capacity term), depending on the capabilities of each user terminal.
  • the transcoding device determines in real time the capabilities of the transmission channel and sends a video / audio stream of maximum quality at the rate actually available, and compatible with the capabilities of each user terminal. In particular, if the user moves with his terminal in the building, the transcoder device must adapt the quality of the TV stream on the local radio link to the available speed at any time.
  • the minimum quality criteria are: 12 frames per second minimum on mobile phone, in minimum QVGA definition and 25 frames per second on PC (possibly with temporal interpolation if it is not perceptible), in VGA definition minimum.
  • the minimum number of frames per second may be higher.
  • the transcoding device may not perform stream compression when this is not necessary (transmission via Ethernet for example, transmission via Wi-Fi to a network).
  • second TV decoder, etc.) only if the terminal announces itself to be fixed to avoid service interruptions when activating the compression.
  • the user terminal can be any device capable of processing / managing (for example a video recorder or digital recorder) and / or of restoring (for example TV) at least one audio / video stream such as, for example , a PC, be a Mac, a PMP, a personal assistant (PDA), a Wl-Fl phone. Access can be done on most Wl-Fl phones on the market (Symbian, iPhone, Windows Mobile, Android). It is understood that some of the functionalities to be implemented in the invention can be realized in purely software (computer program) or purely hardware (hardwired logic) or, still mixed. It is also understood that a compromise between these forms is performed both in terms of cost, flexibility (possibility of evolution and / or adaptation, in particular by software download) and capacity (response time, broadcast quality). local, number of terminals that can be connected).
  • the transcoder device adapts the Live TV stream to the capabilities of the local radio link and the terminal. for the second:
  • the transcoder device adapts the Live TV stream to the available immediate bitrate of the local radio link, in real time. for the third:
  • a subscriber watches TV on his main terminal in the living room.
  • the transcoder device allows the selection of streams, transparently for the subscriber. - for the fifth:
  • a subscriber watches TV on his main terminal in the living room. • Another household subscriber, but traveling to another country, connects to the main terminal using a secondary terminal, and can access TV streams as if he were in the home.
  • FIG. 6 shows a block diagram of the detailed architecture of a transcoder device according to the invention.
  • module' designates a software, hardware or mixed component that performs a set of coherent elementary functions.
  • groupings of functions performed to define the modules are indicative and intended to facilitate explanations.
  • These modules can be duplicated, triplicated or more as needed, these are:
  • a Tuner / Demodulator -Digital Video Broadcasting-DVB 31 -1, 31 -2 module is intended to scan the frequency band, to find the frequencies that transmit data, to transmit the data to the demultiplexer for the analysis of -System Information-SI tables (-Programm Association Table-PAT table, -Programm Map Table-PMT table, -Network Information Table-NIT table, -Bouquet Information Table- BAT table, -Service Table Description table - SDT ”) then call on a given frequency and transmit the stream -Transport Stream-TS to the demultiplexer for reading.
  • This module makes it possible to request stopping the transmission of the stream TS to the demultiplexer.
  • a demultiplexing module 32-1, 32-2 makes it possible to analyze a TS stream and store and / or update the service plan. Among other things, the list of channels, their order, the association of a channel or a frequency to a program number, 7)
  • This module also extracts streams (Audio / Video / subtitle) corresponding to a string, and stream transmission (in TS or -Packetized Elementary Stream- PES format) to audio, video or sub-transcoding modules. title and goes back the name of the channel, the choice of the audio language, the choice of the subtitles.
  • the RTP 33 encapsulation module makes it possible to encapsulate, according to the rtp protocol, the data coming from the transcoders.
  • This module allows the generation of a Session Description Protocol (SDP) file for each open rtp session. This file is transmitted to the user terminals thanks to the client request management module
  • SDP Session Description Protocol
  • the Video Transcoding module 34 allows the transcoding of the data from the demultiplexing and the transmission to the encapsulation module rtp. This module is in connection with the parameterization module 45 which can modify the transcoding parameters in real time.
  • the Audio Transcoding module 35 allows the transcoding of data from demultiplexing and transmission to the encapsulation module rtp. This module is linked to the parameterization module that can modify the transcoding parameters in real time.
  • the Subtitle Transcoding module 36 allows the selection of the subtitles having the correct language (the one chosen by the user) and ensures the transmission to the encapsulation module rtp.
  • the purpose of the data decoding module -Electronic Programm Guide- EPG 37-1, 37-2 is to decode the data -Event Information Table-EIT, -Time
  • the purpose of the network monitoring and parameterization module 38 is to modify the parameters of the audio and video transcoding modules according to: 1 - the type of user equipment
  • the parameters that can thus be modified are, on the one hand, at the level of the video transcoder, the level of the signal on video noise, the number of images per second and the resolution of the images (size of the screen at the level of the reception terminals), on the other hand at the level of the audio transcoder the encoding rate.
  • the type of user terminal (at the level of the reception, o the resolution of the screen o Supported audio formats (for example if the AAC + format is not supported, then the audio transcoder will perform transcoding in mp3 format for example). o the signal-on-noise parameters and the number of frames per second in order to make the nominal flow rate compatible with the type of wireless connection available on this or that user terminal (if a device has a WIFI 802.1 1 n connection then it will accept nominal rates higher than equipment that has a WIFI 802.1 1 b) connection.
  • the parameterization module accesses a database that characterizes the various terminals connecting to the service (this database is updated regularly to support the new wireless terminals).
  • This database is updated regularly to support the new wireless terminals.
  • the description of the user terminal is automatically retrieved at the first connection at the level of the customer request management module.
  • This type of setting controls the minimum quality below which the service will be interrupted for the user.
  • a user profile stored in a database 46 acts on the transcoding module of the subtitles setting the selected language in order to filter the subtitles in the language adapted to the user's choice.
  • 3- the network monitoring module that analyzes the round trip times on the network and the rate used by the stream on each wireless link.
  • This actual rate measurement takes into account the retransmissions associated with a noisy wireless channel.
  • the relevant indicator is the actual flow divided by the nominal flow. It is a value greater than 1.
  • the quality indicator of the link is equal to 1.
  • the indicator can increase by several multiples.
  • ⁇ X1> is the indicator of flow 1 and ⁇ X2> that of flow 2 and (X1 + X2) / available max flow is the ratio between the actual flow used by the 2 flows 1 and 2 by ratio to the total available, then according to thresholds on these 3 values, the transcoding parameters are associated.
  • the 3rd parameter is important because it makes it possible to manage the coexistence between several streams in parallel and to avoid that a flow towards a terminal in limit of zone, does not occupy all the resources to the detriment of another near terminal.
  • the client request management module 39 is an http server that receives the user requests and transfer to the control module. It also allows the recovery of the type of user equipment and gives the parameterization module the necessary information allowing
  • control module 40 initializes in order, the following modules:
  • the transcoding module (A / V / ST / EPG) 3. • The parameterization module, Demultiplexing module
  • This control module ensures the determination of available DVB channels / streams (call to the demodulator to scan the band that will call the demultiplexer to analyze the streams) and also the streams available from the service platform by making requests to the service platform ( format: Web Service http requests and XML responses)
  • Session Description Protocol (SDP) description retrieval For video streams from Internet broadcast servers, the control module retrieves from the service platform the streaming urls of these streams and sends these urls to the decoding modules (if the display is done on the Main terminal) or transcoding (if the display is done on the secondary user terminals) This module also makes it possible to process the channel change requests: determination of the parameters necessary for the demodulator and request for a change of frequency determination of the parameters and request for a change of PID to the demultiplexer change of url of streaming in the case of a broadcast stream by a server on the Internet
  • SDP Session Description Protocol
  • This module also deals with pausing and ending a stream
  • the generation module of the aggregated EPG retrieves data from the DVB-T and DVB-H streams (passing through DBV-T and DVB-H EPG decoding modules). )
  • the EPG format is different between the DVB-T and DVB-H streams even though the same type of information is provided.
  • Event Information Describes the events of the services, for example, table name, event time, duration, and so on.
  • This EPG aggregation module can be run on the PINGO box but also on the Service Platform level. In the 1 st case, the aggregation module of EPG goes back to the service platform the basic data from demultiplexed DVB streams. The recovery of this data is in the form of http request
  • the service platform refers to the Pingo box enriched data on the current program. This data is in an XML format
  • the architecture described in the diagram is replicated at the server level, that is to say that the platform servers recover the DVB EPGs from DVB tuners, demodulators and demultiplexers located on the platform side.
  • the exchange of data between the client (Pingo box) and the server (Platform) is replicated at the server level, that is to say that the platform servers recover the DVB EPGs from DVB tuners, demodulators and demultiplexers located on the platform side.
  • the advantage of this second embodiment is to limit the need for processor and memory resources of the box.
  • the EPG is displayed on the secondary user terminals (via the rtp encapsulation module and the wireless communication module) or for the main terminal (connected to the Pingo box by the TV screen interface (scart type).
  • the metadata is specific to each type of stream and program in progress.
  • Type 2 film and series (broadcast by DVB, IP TV or Video on Demand)
  • Type 3 Music clips (broadcast by DVB, IP TV or Videos type You Tube) Title Name, album Jacquette from album Composers, Singers Names • Photos
  • Type 4 Televised Journal (or in general, any type of program without guests and with columns and one or more animators)
  • Type 5 videos (video sharing site on the Internet like You Tube or DailyMotion)
  • the service platform connects to partner content sites to retrieve information such as actors who play in a movie and can retrieve from another site in another format, the biographies of these actors and so on.
  • the service platform has a role of aggregation of heterogeneous contents
  • ESG is called contextual when the services available are dependent on what is being broadcast on the selected channel.
  • the service platform then crosses the enriched and historical program grid information of the user to accurately write the types of programs viewed, the names of favorite presenters / presenters, favorite music, and favorite themes.
  • This module then allows to be able to generate bouquets of streams (DVB-T, DVB-H, IP TV, Video on demand or Video on site to share videos) according to user tastes and history
  • the wireless transmission module may use one of the following standards: 802.1 1b / g / a / n, Ultra Wide Band, Bluetooth 1.2, 2.0, 2.1 or other communication standard for passing packets IP, especially WIMAX.
  • the implementation of the invention makes it possible to limit the coverage requirements of DVB-T and DVB-H in low density areas by broadcasting the re-encoded TV stream in the last kilometers via the WIMAX network.
  • wired ethernet and carrier current standards are also conceivable for certain applications
  • the implementation of the functions described above is advantageously done in software form, in the case where / the functionalities are implemented in hardwired logic, some information may be useless (for example the links are inherent to the wiring between hardware blocks or dedicated circuits).
  • the discovery of the chains is conducted by the control module which calls the demodulation module which calls in turn N times (for each new TS) the demultiplexing module.
  • the control module requests the demultiplexer to request the demodulation module.
  • “threads” may be used. At least one can implement the following “threads”: one for the HTTP server and the control module, one for the network monitoring, one for the demodulation, one for the whole demultiplexing, transcoding, encapsulation and transmission. In this last "thread”, transcoding and encapsulation functions would be called consecutively when data is demultiplexed. Separate “threads” can also be implemented to handle audio / video / subtitle / EPG channels. In this case, it is necessary to transform the transcoding functions with a transcoding start function and to add a stop transcoding function.
  • FIG 7 there is shown a sequence diagram of the channel discovery phase.
  • Figure 8 is shown a sequence diagram of an initial connection request.
  • the processing can begin as soon as the demultiplexer has been informed of the string to be processed.
  • a negotiation of the IP communication ports between client and server is not necessary (reduction of the latency) and for that we will send the RTP data on "IP multicast" addresses.
  • Figure 9 there is a sequence diagram of an end of connection request.
  • Figure 10 shows a sequence diagram of a channel change request.
  • Channel change requests can therefore be HTTP POSTs.
  • the solution proposed by the invention allows: - Limited players to be able to play at least the part Audio / Video / Subtitle.
  • - RTP protocol support the "package” constraints that the reader will have to bear will be those of the 3GPP PSS standard. The reader will have to support the "multicast” addresses.
  • SDP protocol support the SDP descriptions used will comply with the 3GPP PSS standard. They will contain at least one audio stream, a video stream and a subtitle stream (in "3GPP Timed Text” format). They will contain a 3GPP DIMS stream that can be ignored or processed in order to display the EPG in graphic overlay.
  • This profile of the terminal can be stored in the database 46.
  • the secondary connection is made by means of a wireless connection of the WIFI type between the decoder 1 and the reader 20.
  • the decoder 1 distributes a secondary data stream in a zone cover "lit" by the WIFI signal, about 300 meters around the decoder.
  • the decoder is preferably connected to the mains by a power cable 2.
  • the decoder 1 is preferably positioned near a building window inside which is the player on which the user wishes to view a video content.
  • the decoder 1 can even be placed outside the building, on the front of it, for example.
  • the decoder 1 is advantageously provided with several antennas 3 for capturing the DVB signal. Indeed, it was found that the quality of reception was greatly improved when the system included several antennas with different relative orientations, thus ensuring a very good reception whatever the position of the decoder with respect to the transmission cone of the antenna of the network near which the decoder is located.
  • the received DVB-H stream is decoded by a dedicated DVB-H 4 chip.
  • the decoded data stream is transmitted, along internal connections 6, to a CPU calculation unit referenced by the number 5 in FIG. .
  • the data stream has a bit rate of 2 Mbps. The data flow corresponding to an individual video channel is therefore
  • the processing performed by the CPU 5 consists of the separation, or demultiplexing, of the five individual channels composing the primary decoded data stream into as many individual decoded data streams. These individual decoded data streams are then directed to storage and storage means. More precisely, "+", "0" and "-" files, for example of the MPEG type, are simultaneously and respectively dynamically increased data of the decoded and demultiplexed DVB stream.
  • the individual data stream and therefore the corresponding file, is enriched with some of the contextual data of the fourth channel "I" of the DVB-H stream.
  • One of the files "+”, "0" and "-" is then selected to be re-transmitted to the reader of the user.
  • the physical medium of the secondary protocol is a wireless local link, wireless WIFI type.
  • the WIFI standard for example 802.1 1b, has a theoretical bit rate of 1 1 Mbps, or 6 Mbps in actual bit rate, on a 2.4 GHz carrier, within a range of 300 meters.
  • the decoder 1 therefore comprises WIFI transmission means 10 and an antenna 1 1 associated with the.
  • the decoder 1 covers a large area in which an identified user can have several video signal display devices, or multiple users can receive the same video signal.
  • the portable video player 20 includes an antenna 21 and means capable of receiving and decoding the received WIFI signals 22.
  • the secondary data stream thus received is processed by the CPU 25 of the reader 20 to be displayed on a screen 23 of this reader.
  • the decoder 1 communicates directly with the reader without going through a home router. Indeed, on a shared communication link between several services, it has been found that the broadcasting of a video stream is easily disturbed by the other data transiting on this link. For example, downloading files from the Internet in parallel with broadcasting a video stream disturbs the latter. The video is displayed jerkily. Consequently, it will be preferable to have a local WIFI link dedicated to the replay of the video stream.
  • the DVB decoder could be integrated into a home router and the WIFI connection could be shared between several users or functionalities.
  • the decoder could communicate with the home router by means of a wired or wireless link, the router in turn repackaging the video stream to the video player via a wireless local WIFI link. Intraflux navigation concept (from one video channel to another)
  • Each particular operating frequency of digital television according to the DVB standard carries three multiplex channels successively selected from this list: a central channel "n" and two adjacent channels respectively directly above "n + 1" and directly below "n -1 "of the central channel.
  • the DVB-H reception means comprise a "tuner" function enabling the DVB-H receiver to switch from a first reception frequency f1 to a second neighboring frequency f2, for example directly above the first frequency. While the first frequency f 1 carries the channels n-1, n and n + 1, the channel n being the central channel "0" for this frequency f1, the second frequency f2 carries the channels n, n + 1 and n + 2, the central channel "0" corresponding for this second frequency f2 to the channel n + 1.
  • This "tuner” function therefore corresponds to the ability to switch from one group of channels to another group of channels immediately above in the ordered list of broadcast video channels.
  • the decoder 1 has a feature enabling the user to select a video channel among the three video channels present in a DVB-H data stream decoded at the present moment.
  • This is a kind of navigation inside a DVB-H data stream characterized by a constant frequency of operation of the DVB-H stream receiving means.
  • the "tuner" function of the DVB reception means also make it possible to navigate among the broadcast channels, but each time the reception frequency is modified, the "0", "+” and “-” files must be recreated and waited for. it has a sufficient volume to allow secondary diffusion without breaking the flow. This represents a certain time out.
  • IP television installations it has been found that, by virtue of the use of the IP protocol, a large latency time exists during a change of channel. Indeed, the time to recreate an IP connection carrying video information relating to the new channel and the time to store in a buffer enough information to subsequently ensure a smooth and continuous display of the video program, is about 10 to 15 sec.
  • the intraflux navigation according to the invention constitutes a decoupling between the use of the "tuner" function and the selection of the selected video channel.
  • the DVB tuner function is activated to call the primary reception on the frequency immediately above the frequency received so far.
  • the individual video channel selected and currently displayed now corresponds to the central channel "0" of the primary DVB-H data stream.
  • a new MPEG buffer file corresponding to the newly decoded channel n + 2 is created; the files corresponding to the common channels n and n + 1 continue to be decoded and are updated, possibly by changing the name; and the file corresponding to the n-1 channel that is no longer decoded is deleted.
  • the user chooses a channel via a remote control 30, either real and dedicated to the decoder 1, or virtual and emulated by software running on the portable video player 20.
  • the data of channel selection are transmitted from the reader 20 to the decoder 10 using the uplink flow bidirectional WIFI connection.
  • the navigation is done by the use of the selection buttons + 31 and - 32. Their actuation generates the sending of information for example by means of an infrared link between transmission means 35 of the remote control 30 to IR reception means 15 which is equipped with the decoder 10.
  • the communication between the remote control 30 and the decoder 1 can be done according to a proprietary communication protocol.
  • the remote control comprises an LCD screen 36 on which the metadata corresponding to the video channel currently displayed on the player.
  • This LCD screen 36 comprises, in its upper part, a series of aligned liquid crystals 37 for indicating the power of the DVB signal picked up by the decoder 1.
  • This feature makes it possible to place the decoder so that the reception of the DVB signal is the best possible.
  • a software corresponding to a virtual remote control can be downloaded during the first connection between the decoder 1 and the reader 20. This downloaded software is then executed to provide the reader 20 with this virtual feature.
  • the video data multiplexed in the primary DVB stream may be encrypted by the operator so as to allow viewing of the content only to identified users. Two architectures are then possible.
  • a first architecture shown in FIG. 1 after decoding, an encrypted decoded data stream corresponding to an individual channel is re-transmitted to the reader, and the decryption operation takes place at the level of the reader 20.
  • the reader 20 has a smart card 26 identification of the reader and its user.
  • the use of this first architecture requires the transmission of a decryption key to the reader 20. This can be done at regular intervals, for example every month, by the transmission by the operator of a DVB stream of which the fourth channel, called information, conveys this key data. A transmission buffer file of the key is then sent from the decoder 1 to the reader 20.
  • the reader 20 Once the reader 20, identified by its smart card, has received and stored the corresponding key, it is able to decrypt the received video signal for the duration of validity of said key.
  • the CPU 25 of the reader 20 reads the decryption key stored in a read-only memory of said reader 20 in order to decrypt the received secondary video stream.
  • the CPU 25 is then able to transmit the decrypted data to the screen 23.
  • Smart card on the decoder According to a second architecture, the decoder 1 is identifiable by its own smart card 8 (shown in dashed lines in FIG. 1). After identification according to a known method, a decryption key can be transmitted through the fourth information channel of the DVB stream to this identified decoder.
  • the key once available allows the CPU 5 to decrypt the different streams of the video channels.
  • the means 7, 10 and 11 make available a decrypted secondary video signal.
  • a secondary protocol based on BLUETOOTH support is also envisaged.
  • the BLUETOOTH communication format defines for example by the IEEE standard
  • 802.15.1 has the advantage of covering a reduced area of about 100 meters radius around the transmitter. This means of retransmitting a secondary video stream by a digital television decoder according to the invention is particularly well suited to a vehicle. And this especially since this format is already used for a whole series of applications in the automotive world.
  • the decoder can then be autonomous. It comprises in this case a rechargeable low power battery, for example by means of a solar cell associated with the decoder when it is placed on the facade of the building or on the rear window of a car.
  • BLUETOOTH connection requires the initial association of the reader and the decoder. This pairing step can be done simply by grabbing on the reader a key characterizing the BLUETOOTH connection of the decoder, indicated for example on a label placed on the underside of it.
  • the invention can be provided in many other ways than those specifically described by way of example.
  • the functionalities can be implemented by software rather than wired or in mixed mode (wired + software), these functionalities can be extended or limited according to the uses: limitation of the capacities of the demodulator for example, the type of DVB signal, the choice of flows: in the clear or not, encryption on the local radio link or not, choice of adaptive data compression method, choice of parameters defining the quality of the local link (latency, speed, retransmission rate ... ) ...

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Décodeur de flux audio/vidéo au format DVB comportant : des moyens de réception d'un flux de données primaire DVB ayant des données de contenu correspondant à une pluralité de canaux; des moyens d'extraction, de séparation et de traitement des données de contenu dudit flux primaire pour produire une pluralité d'ensembles de données, chaque ensemble de données correspondant à un canal; et, des moyens de réémission d'un ensemble parmi lesdits ensembles de données en tant que données de contenu d'un flux de données secondaire dans un protocole de communication locale.

Description

Décodeur de flux DVB
La présente invention se rapporte à la télévision numérique DVB (pour « Digital Video BroadCasting »), que ce soit la télévision numérique terrestre définie par la norme DVB-T (pour « Terrestrial ») ou bien la télévision numérique mobile définie par la norme DVB-H ( pour « Handheld »). Par exemple, la norme DVB-H dans sa version V1.2.1 de Novembre 2005 est présentée dans le document ETSI-TR- 102377 disponible en ligne, sur le site INTERNET de l'ETSI. Les symboles et abréviations utilisées dans le présent texte, si ils ne sont pas explicites, sont définis dans cette norme. Dans le présent document, l'invention sera plus précisément présentée dans le contexte de la télévision numérique mobile DVB-H, mais l'invention peut être mise en œuvre dans un autre contexte, par exemple celui de la télévision numérique terrestre DVB-T.
Un service de télévision mobile a pour but de permettre la visualisation du contenu d'un canal vidéo sur un appareil autonome, portable comportant un écran, appelé ci-après lecteur. Le lecteur peut être un téléphone portable, un assistant personnel, une télévision, etc. Le service de télévision mobile a pour vocation de permettre la diffusion d'un contenu vidéo au cours du déplacement de l'utilisateur. Il s'agit de diffuser un signal vidéo avec un débit suffisant pour garantir une image de qualité satisfaisante sur un écran dont la dimension n'excède pas 7 pouces de diagonale selon l'une des contraintes actuelles de la norme DVB.
Eventuellement, le lecteur est muni d'une carte à puce d'identification, équivalent d'une carte au format SIM actuellement utilisée largement dans les téléphones GSM, de manière à pouvoir gérer l'accès au contenu vidéo par un lecteur et/ou un utilisateur identifié. La carte à puce permet au distributeur du contenu vidéo de contrôler les droits d'accès et d'autoriser éventuellement le décryptage du flux vidéo.
Le principe général de la DVB-H par rapport à la DVB-T est d'émettre des paquets de données périodiquement pendant un temps de transmission extrêmement court, alors que la DVB-T émet des données de manière essentiellement uniforme et continue. De la sorte, un lecteur portable, synchronisé avec l'émetteur et connaissant la période d'émission des paquets DVB-H, ne fonctionne que pendant un temps très court correspondant à la réception d'un paquet de données. Entre la réception de deux paquets successifs, le lecteur est éteint. Sa consommation électrique est ainsi réduite répondant ainsi au critère d'autonomie du lecteur. Rappelons que la norme DVB est un protocole de communication et se rapporte donc à la couche physique de la transmission de données. La couche de données, quant à elle, peut comprendre par exemple des données vidéo au format MPEG2 ou bien des datagrammes IP encapsulant à leur tour des informations vidéo pouvant être codées sous le format MPEG4. De plus, le lecteur doit pouvoir être déplacé d'une cellule du réseau d'émission à une autre et la couche de données du protocole DVB-H comporte des données de correction d'erreurs de transmission pour obtenir une image vidéo de qualité, même dans des zones de faible couverture.
Au cours des études destinées à déterminer les modes possibles d'utilisation de la vidéo sur un terminal mobile, il a été constaté qu'un tel service serait essentiellement utilisé à domicile, c'est-à-dire non seulement sans déplacement d'une cellule du réseau à une autre, mais surtout en étant dans une enceinte plus ou moins hermétique aux ondes électromagnétiques de la couche physique du protocole DVB-H. En conséquence, pour que le signal effectivement reçu par le lecteur soit suffisamment puissant pour une communication correcte, il est actuellement envisagé d'augmenter la puissance des antennes émettrices du réseau, de manière à ce que la puissance du signal reçu soit suffisante malgré les pertes importantes lors de la traversée des murs des maisons d'habitation.
Ce besoin d'une puissance supplémentaire, qui existe également dans le cas de la télévision numérique terrestre DVB-T, pour assurer la pénétration des ondes dans les habitations, représente un coût additionnel de l'infrastructure d'émission qui n'est pas marginal. On estime que cela représente un coût additionnel de deux à quatre fois le coût d'une installation d'émission de puissance nominale, et ceci essentiellement à cause du nombre d'antennes à déployer pour atteindre effectivement la puissance requise sur tout le territoire couvert.
Il y a donc un besoin pour minimiser les coûts de déploiement d'une telle infrastructure permettant la diffusion de la télévision numérique DVB sur des lecteurs qu'ils soient portables (« Portable Media Device » - PMD) ou fixes, comme un poste de télévision. La présente invention concerne donc plus particulièrement un décodeur de flux audio/vidéo au format DVB ainsi que des procédés adaptés qui permet la gestion locale, notamment au sein d'une habitation individuelle, voire collective, ou au sein d'une commune de flux audio/vidéo entrants de diverses origines dont DVB vers des terminaux, notamment portables, d'utilisateurs. Les procédés et le décodeur sont mis en œuvre dans/sous forme d'un dispositif recevant des données audio/vidéo par liaison radio de type DVB ainsi que, de préférence, des données audio/vidéo ou d'autres types (images, textes, instructions, programmes informatiques...) en provenance de la toile (INTERNET) par liaison radio ou filaire. Ces données sont traitées dans le dispositif où elles sont décodées puis ré-encodées avec compression de données pour transmission radio locale (Wl-Fl ou BLUETOOTH de préférence) entre le dispositif et un terminal (ou plusieurs) d'un utilisateur (ou plusieurs terminaux d'un utilisateur ou de plusieurs utilisateurs) où les données ré-encodées reçues sont décompressées pour y être restituées visuellement et/ou sous forme de sons selon le cas. Le dispositif s'apparente donc à un transcodeur (appelé également dispositif transcodeur ou dispositif de transcodage) qui gère la redistribution des flux audio/vidéo en local. En outre de la compression, le ré-encodage peut comporter un cryptage notamment dans le cas de données devant être protégées (par droits d'auteur par exemple) et que seul un terminal autorisé pourra décrypter. De préférence, la compression pour diffusion sur liaison radio locale se fait selon un procédé MPEG-4 AVC.
Du fait que la liaison radio (Wl-Fl, WI-MAX, BLUETOOTH) locale/finale entre le dispositif transcodeur et le/les terminaux présente un débit limité par rapport aux flux initiaux en amont du dispositif (notamment DVB), une sélection de flux (choix d'un canal vidéo/audio parmi ceux possibles arrivant sur le dispositif, notamment parmi les canaux DVB) ainsi qu'une gestion de la bande passante sur la liaison radio locale/finale des canaux de données vidéo/audio est mise en œuvre dans le dispositif transcodeur, notamment sous la forme d'une adaptation en temps réel ou quasi réel de la compression à la qualité de la liaison radio locale/finale entre le dispositif et le terminal. En outre, avant le ou au début d'une restitution sur un terminal (à la mise en marche du terminal ou lors d'un passage en mode de réception et affichage vidéo/audio sur le terminal) ou lorsque l'utilisateur change la résolution (nombre de données et/ou qualité) d'affichage sur son terminal (si cela lui est possible), la compression est adaptée à ladite résolution courante du terminal concerné. A noter que, dans une variante, en cas de dégradation de la qualité de la liaison, le dispositif peut imposer de sa propre initiative une réduction de la résolution à un terminal donné.
Outre ses capacités de diffusion vers le ou les terminaux du ou des utilisateurs, de données vidéo/audio (ou autres) DVB et/ou en provenance de la toile, le dispositif (et les procédés de l'invention) permet une remontée d'information en provenance de l'utilisateur vers la toile (notamment vers une plateforme de service dédiée ou tout autre site ad hoc) par l'intermédiaire du dispositif de transcodage. Cette provenance peut être directe, notamment par l'intermédiaire d'une télécommande actionnée par l'utilisateur et communiquant avec le dispositif transcodeur (la télécommande peut être un appareil dédié - télécommande classique ou perfectionnée- ou un téléphone -par l'intermédiaire de BLUETOOTH par exemple- ou un ordinateur personnel portable ou tout autre outil pouvant communiquer avec le dispositif transcodeur). Cette provenance peut être indirecte, notamment par prise d'informations sur ce que l'utilisateur est en train de voir et/ou d'écouter, d'informations sur sa position absolue ou relative (en pratique de son terminal, voire de sa télécommande ou autre), de capteurs propres au terminal... En effet, le contenu vidéo/audio DVB et/ou de la toile, est généralement associé à des informations sous le format -Electronic Programme Guide-, EPG (ou autre format pour celles en provenance de la toile : nom de fichier par exemple) concernant leur identité (source, titre par exemple) et ces informations peuvent être renvoyées sur la toile par le dispositif de transcodage. Il est ainsi possible de suivre les choix actuels et passés d'un utilisateur et de lui proposer pour l'avenir des contenus divers audio/vidéo adaptés à ceux-ci.
L'invention consiste en un décodeur de flux audio/vidéo au format DVB, qui comporte : - des moyens de réception d'un flux de données primaire selon le protocole de communication DVB ayant des données de contenu correspondant à une pluralité de canaux ; des moyens d'extraction, de séparation et de traitement des données de contenu dudit flux primaire pour produire une pluralité d'ensembles de données, chaque ensemble de données correspondant à un canal dudit flux primaire; et, des moyens de réémission d'un ensemble parmi lesdits ensembles de données en tant que données de contenu d'un flux de données secondaire dans un protocole de radio communication secondaire locale vers un terminal d'un utilisateur pour restitution du flux, le protocole de communication secondaire constituant une contrainte sur le débit du flux de données secondaire par rapport à celui du flux primaire, ledit décodeur comportant des moyens de compression de l'ensemble de données réémis, lesdits moyens de compression étant adaptatifs en fonction d'au moins un critère de qualité de transmission de la radio communication secondaire locale.
Selon différents modes de réalisation présentant chacun ses avantages respectifs :
• au moins un critère de qualité de transmission de la radio communication secondaire locale sont choisis parmi : - temps de latence entre une demande de restitution et la restitution sur le terminal,
- débit de transmission sur la radio communication secondaire locale,
- taux de réémission radio du fait d'erreur de transmission sur la radio communication secondaire locale,
• lesdits moyens de compression sont adaptatifs en fonction d'au moins un critère de résolution de la restitution du flux du terminal utilisateur.
• le protocole de communication du flux secondaire est fondé sur un protocole de communication sans fil, de préférence WIFI ou BLUETOOTH.
• le protocole de communication du flux secondaire est fondé sur un protocole de communication filaire, de préférence du type Courants Porteurs en Ligne. • il comporte des moyens de navigation intra-flux DVB permettant la sélection de l'ensemble de données effectivement réémis par lesdits moyens d'émission, parmi ladite pluralité d'ensembles de données.
• lesdits moyens de navigation comportent une partie déportée du boîtier du décodeur, de préférence sur une télécommande ou sur un lecteur apte à fonctionner avec ledit décodeur.
« les données de contenu dudit flux primaire étant cryptées, il comporte des moyens de décryptage des données du flux primaire, de sorte que le contenu dudit flux secondaire réémis est décrypté.
• lesdits moyens d'émission permettent la réémission d'un flux secondaire sécurisé.
• le protocole de communication secondaire constitue une contrainte sur le débit du flux de données secondaire par rapport à celui du flux primaire, ledit décodeur comportant alors des moyens de compression de l'ensemble de données réémis.
L'invention concerne également un procédé de décodage d'un flux de données DVB, comportant les étapes consistant à: capter un flux primaire de données au format DVB; - extraire, séparer et traiter les données de contenu dudit flux primaire de manière à produire une pluralité de flux individuels de données décodées correspondant chacun à l'un des canaux dudit flux primaire ; retransmettre un desdits flux individuels correspondant à un canal vidéo au moyen d'un protocole secondaire de communication locale.
Selon différents modes de réalisation présentant chacun ses avantages respectifs :
• ledit protocole secondaire est fondé sur une liaison de communication secondaire sans fil du type WIFI ou BLUETOOTH.
• les flux individuels étant cryptés, le procédé consiste en outre à décrypter lesdites données. • ladite étape de décryptage est réalisée avant ladite étape de retransmission, et en ce que le procédé comporte une étape initiale d'établissement d'une liaison de communication secondaire sécurisée pour la retransmission dudit flux secondaire décrypté.
• il comporte une étape consistant à compresser lesdits flux individuels de données avant ladite étape de retransmission secondaire.
Avantageusement, l'invention porte donc sur un dispositif et un procédé permettant le découplage de la fonction de décodage du flux de données DVB et de la fonction d'affichage. Pour cela la totalité ou une partie des données vidéo décodées est réémise au moyen d'une liaison secondaire vers le lecteur affichant ce contenu vidéo. Parmi les avantages de la présente invention on peut mentionner que pour le
DVB-T, notamment à cause de problèmes d'intégration d'antennes en bande UHF et des pertes de pénétration dans les maisons ou appartements, la zone de réception pour un fonctionnement acceptable à l'intérieur des bâtiments est limitée. Dans le cas de la Télévision Numérique Terrestre, TNT française, l'organisme de régulation a privilégié un nombre maximum de chaînes par Multiplex en spécifiant une modulation sophistiquée (64 QAM 2/3) offrant le maximum de débit (-24 Mbit/s par MUX), en contrepartie d'une sensibilité de réception très faible. La couverture TNT annoncée concerne une réception fixe avec une antenne sur le toit à une hauteur de 10m. Dans le cas d'une utilisation de récepteurs TNT portables à l'intérieur de bâtiments, le rayon de couverture est limité à environ 15 % (avec une seule antenne) ou au mieux à 20% (avec deux antennes en mode diversité) du rayon de couverture annoncé La retransmission, conforme à l'invention, en Wl-Fl ou BLUETOOTH du signal audio/vidéo reçu en TNT au niveau d'une fenêtre permettrait d'éliminer les pertes occasionnées par les murs et cloisons et d'atteindre ainsi un rayon de couverture à l'intérieur des bâtiments plus important et plus proche du rayon de couverture fixe annoncé. On doit noter que ce problème est identique pour les transmissions DVB-H.
Les autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lumière de la description détaillée qui va suivre de modes de réalisation actuellement préférés. Cette description faite en référence aux figures annexées illustre l'invention mais n'a pas pour but de réduire ou de limiter celle-ci.
- La Figure 1 représente sous la forme d'un schéma blocs, l'architecture générale mise en œuvre selon l'invention, - La Figure 2 représente sous la forme d'un schéma blocs, l'architecture générale de la mise en œuvre de l'invention dans le cas d'un dispositif transcodeur DVB-T WI-FI,
- La Figure 3 représente sous la forme d'un schéma blocs, l'architecture mise en œuvre de l'invention dans le cas d'un dispositif transcodeur DVB-H BLUETOOTH,
- La Figure 4 représente sous la forme d'un schéma blocs, l'architecture générale de la mise en œuvre de l'invention dans le cas d'un dispositif transcodeur DVB-T Wl-Fl pour diffusion vers un ordinateur (PC),
- La Figure 5 représente sous la forme d'un schéma blocs, une architecture équivalente à celle de la Figure 4 mais dans le cas où des flux/chaînes cryptées doivent également être diffusées vers un/des terminaux utilisateurs,
- La Figure 6 montre un diagramme par bloc de l'architecture détaillée d'un exemple de réalisation d'un dispositif transcodeur selon l'invention,
- La Figure 7 montre un diagramme de séquence de la phase de découverte des chaînes,
- La Figure 8 montre un diagramme de séquence d'une demande de connexion initiale,
- La Figure 9 montre un diagramme de séquence d'une demande de fin de connexion, - La Figure 10 montre un diagramme de séquence d'une demande de changement de chaîne, et
- la Figure 1 1 montre un diagramme de séquence du dialogue client-serveur. Ces figures sont pour la plupart des organigrammes constitués de schémas bloc dont la fonction est précisée à l'intérieur du cadre correspondant. L'exemple de mise en œuvre représenté Figure 1 , permet la réception dans un décodeur 1 d'un flux amont radio DVB par une antenne 3 et un canal audio/vidéo est redistribué par une connexion sans fil radio locale du type WIFI ou BLUETOOTH vers un lecteur 20. Le décodeur 1 distribue un flux de données secondaire dans une zone de couverture « éclairée » par le signal radio local d'environ 300 mètres autour du décodeur dans le cas du Wl-Fl. Le décodeur est de préférence raccordé au secteur par un câble d'alimentation 2. Une télécommande 30 permet de piloter à distance le décodeur 1. Les autres éléments mis en œuvre seront décrits plus en détail par la suite.
En pratique, le dispositif transcodeur peut se présenter sous forme d'un boîtier dédié ou être intégré à un appareil de diffusion audio/vidéo comme par exemple un décodeur TNT, un démodulateur satellite, un téléviseur ou un vidéo projecteur. Dans une variante, il se présente sous forme d'une carte informatique à insérer dans un ordinateur ou un boîtier (« dongle ») à raccorder à une entrée d'un ordinateur personnel. Dans un mode de réalisation particulier, le dispositif transcodeur se présente sous la forme d'un récepteur DVB-T Wl-Fl qui se met le long d'une fenêtre d'une maison pour réception DVB et redistribue des flux audio/vidéo par liaison WIFI dans la maison sur tous types de terminaux à écran. L'enjeu technique est la capacité a filtrer au sein d'un signal broadcast multiplexe à 24 Mbit/s, réception DVB par exemple, un flux de programme unique de 2 Mbit/s, le Wl-Fl, et en adaptant automatiquement le débit de ce flux à l'écran de visualisation du terminal choisi à l'aide d'un réencodage robuste et efficace.
Un schéma fonctionnel d'un tel récepteur est donné sur la Figure 2. SVC signifie «Scalable Video Coding » pour codage vidéo variable et zapping symbolise la possibilité de télécommande en retour entre le terminal (ou une télécommande) et le récepteur.
Le/les cryptage et/ou décryptage représentés dans le dispositif de transcodage sont optionnels, notamment le décryptage peut être omis dans le cas d'une diffusion d'une ou/de chaînes en clair. P pour les chaînes cryptées, le décryptage s'effectue dans le terminal utilisateur, notamment la transmission finale (liaison Wl-Fl locale en l'espèce sur la Figure 2) peut s'effectue avec ou sans cryptage propre.
Dans un autre mode de réalisation, le dispositif transcodeur se présente sous la forme d'un récepteur DVB-H BLUETOOTH autonome, disposant d'un mécanisme d'authentification, par exemple une carte sim, qui reçoit des flux à 7,37 Mbit/s, les décompose en canaux de 384 Kbit/s et renvoie un canal vers un terminal BLUETOOTH à capacité d'affichage pour restitution audio et/ou vidéo. Ce terminal peut être un téléphone portable bluetooth équipé d'un logiciel de restitution ("player") adapté. Ce logiciel de restitution peut incorporer une télécommande logicielle intégré. Un schéma fonctionnel d'un tel récepteur est donné sur la Figure 3. Le/les cryptage et/ou décryptage représentés dans le dispositif de transcodage sont optionnels, notamment le décryptage peut être omis dans le cas de diffusion d'une/de chaînes en clair (ou pour une/des chaînes cryptées, le décryptage s'effectuant dans le terminal utilisateur), notamment la transmission finale (liaison BLUETOOTH locale en l'espèce sur cette Figure 3 peut s'effectuer avec ou sans cryptage propre.
Dans un autre mode de réalisation particulier représenté sur la Figure 4, le dispositif transcodeur se présente sous la forme d'un récepteur DVB-T Wl-Fl pour la diffusion de chaines TNT en clair SD retransmise par diffusion Wl-Fl sur un ordinateur personnel (PC). Ce dispositif de transcodage comporte un récepteur (tuner) démodulateur DVB-T et est compatible avec notamment les formats de données suivants : DVB-T ; MPEG-2 SD(vidéo) ; MPEG-1 Layer 2 stéréo, AC3, MPEG-2 AAC, MPEG-4 HE AAC, Enhanced AC3, AC3 (audio) ; Ceefax et DVB-Sub (sous-titres) ; ElTp/factual&other, EITs (données programme). Le dispositif transcodeur est capable d'effectuer un balayage complet de la bande UHF pour rechercher les chaînes, de les ordonnancer selon les tables de signalisation, et de mémoriser ces informations techniques. Le Tuner/démodulateur peut recevoir des commandes pour se caler sur une fréquence et une chaîne particulière.
Dans le cas d'un tuner/démodulateur DVB-H, la compatibilité est notamment possible les formats de données suivants : DVB-H ; H264 QVGA (vidéo) ; HE-AAC V2 (audio), DVB-IPDC (Guide Electronique des Services).
La Figure 5, extension fonctionnelle du dispositif transcodeur de la Figure 4, présente un dispositif permettant la diffusion de chaînes cryptées. Il comporte une fonctionnalité de décryptage de flux DVB puis de cryptage pour le flux de la liaison radio locale, le terminal comportant un moyen de décryptage adapté.
Le nombre de tuners/démodulateurs en entrée peut être quelconque (1 , 2, 3, 4 ou plus). Le dispositif transcodeur est capable de transmettre par Wl-Fl un nombre de flux TV qui est égal au nombre de tuners/décodeurs. Les fonctionnalités de transcodage audio/vidéo du dispositif transcodeur doivent donc être modulaires pour s'adapter à un nombre quelconque de tuners/démodulateurs. Cette fonctionnalité est mise en œuvre sous forme d'une puce de transcodage, et doit permettre de gérer un au moins flux TV en entrée et de le transcoder. Dans le cas où la puce ne peut gérer qu'un seul flux (une seule chaîne) on mettra en œuvre autant de puce que de tuners/démodulateurs. Dans une modalité particulière, un dispositif de transcodage de ce type peut comporter 3 tuners/démodulateurs et 3 puces de transcodage, en plus d'un disque dur intégré. Il est alors possible de visualiser sur une télévision (TV) par exemple ou sur un écran déporté (téléphone portable, TV de poche) le flux (la chaîne) du premier tuner, de consulter sur une autre TV ou un autre écran déporté le flux du deuxième tuner et d'enregistrer sur le disque dur du dispositif de transcodage le flux (la chaîne) du troisième tuner dédié. Le transcodage dans le dispositif de transcodage s'effectue selon un procédé de compression variable en fonction de la qualité de la liaison finale, Wl-Fl en l'espèce. Ainsi, la puce permet de transcoder n'importe quel flux vidéo provenant du Tuner/démodulateur vers un format MPEG-4 AVC dans cet exemple. De même pour le signal, la puce est capable de transcoder n'importe quel flux audio entrant, vers un flux audio mp3 ou AAC à un débit réduit. De même pour les sous-titres (ou autres données accessoires à l'audio ou vidéo), la puce est capable de transcoder n'importe quel flux de sous-titre vers un flux de sous-titre compatible avec le terminal utilisateur recevant le signal radio local Wl-Fl en l'espèce (streaming text 3GPP par exemple).
Le terminal utilisateur est ici un PC avec un logiciel de restitution (« Player ») dédié installé. Le PC peut permettre de consulter la liste des chaînes disponibles et assurer la télécommande (notamment « zapping » sur une chaîne désirée) via un navigateur web ou un lecteur vidéo (type VLC).
Le PC peut restituer les flux vidéo/audio/sous-titre, sélectionner la piste audio et sous-titre à restituer. Si le PC n'est pas adapté pour restituer une piste audio (AC3 par exemple), il doit être configuré pour sélectionner un flux audio MPEG-2 de même langue.
On comprend que le dispositif de transcodage dispose à priori (saisie ou programmation préalable) ou reconnaît (reconnaissance automatique) les capacités de décodage de chaque terminal utilisateur afin que le dispositif puisse fournir un flux vidéo/audio compatible, et de qualité maximale (notamment en terme de capacité d'affichage), selon les capacités de chaque terminal utilisateur. Le dispositif de transcodage détermine en temps réel les capacités du canal de transmission et envoi un flux vidéo/audio de qualité maximale selon le débit effectivement disponible, et compatible avec les capacités de chaque terminal utilisateur. En particulier, si l'utilisateur se déplace avec son terminal dans le bâtiment, le dispositif transcodeur doit adapter la qualité du flux TV sur la liaison radio locale au débit disponible à tout moment. Par exemple, les critères de qualité minimaux, selon chaque terminal utilisateur, sont : 12 trames par seconde minimum sur téléphone mobile, en définition QVGA minimum et 25 trames par seconde en rendu sur PC (avec éventuellement interpolation temporelle si elle est non perceptible), en définition VGA minimum. Pour un terminal de type TV fixe, le nombre minimal de trames par seconde peut être plus élevé.
Dans une modalité de fonctionnement particulière, le dispositif de transcodage, pour conserver la qualité d'image maximale, peut ne pas effectuer de compression de flux lorsque cela n'est pas indispensable (transmission par Ethernet par exemple, transmission par Wi-Fi vers un deuxième décodeur TV, etc.), cela seulement si le terminal s'annonce comme étant fixe pour éviter des interruptions de service lors de l'activation de la compression.
La mise en œuvre d'une liaison locale radio de type Wl-Fl ou BLUETOOTH permet une application type « Plug and Play » pour les terminaux des utilisateurs. Dans ce cas, l'utilisateur n'a à effectuer aucun réglage, hormis l'installation d'une application sur son terminal.
D'une manière générale, le terminal utilisateur peut être tout appareil capable de traiter/gérer (par exemple magnétoscope ou enregistreur numérique) et/ou de restituer (par exemple TV) au moins un flux audio/vidéo comme, à titre d'exemple, un PC, être un Mac, un PMP, un assistant personnel (PDA), un téléphone Wl-Fl. L'accès peut se faire sur la majorité des téléphones Wl-Fl du marché (Symbian, iPhone, Windows Mobile, Android). On comprend que certaines des fonctionnalités à mettre en oeuvre dans l'invention peuvent être réalisées sous forme purement logicielle (programme informatique) ou purement matérielle (logique câblée) ou, encore mixte. On comprend également qu'un compromis entre ces forme est effectué à la fois notamment en terme de côut, souplesse (possibilité d'évolution et/ou adaptation, notamment par téléchargement de logiciel) et de capacité (temps de réponse, qualité de la diffusion locale, nombre de terminaux pouvant être connectés).
Grâce aux fonctionnalités mises en oeuvre dans le dispositif de transcodage, les utilisateurs peuvent bénéficier de certaines facilités dont au moins: pour la première:
• Un abonné regarde la TV sur son terminal principal, dans le salon.
• Un autre abonné du foyer regarde la TV sur un terminal secondaire, dans une chambre.
• le dispositif transcodeur adapte le flux TV Live aux capacités de la liaison radio locale et du terminal. pour la deuxième :
• Un abonné regarde la TV sur son terminal principal, dans le salon.
• Un autre abonné du foyer regarde la TV sur un terminal secondaire.
• Ce deuxième abonné se déplace dans la maison ou le jardin avec son terminal secondaire
• le dispositif transcodeur adapte le flux TV Live au débit immédiat disponible de la liaison radio locale, en temps réel. pour la troisième :
• Un abonné regarde la TV sur son terminal principal, dans le salon. - Un autre abonné du foyer regarde la TV sur un terminal secondaire.
• Ce deuxième abonné sélectionne sur le terminal secondaire un autre flux TV à jouer.
• le dispositif transcodeur permet la sélection de flux, de manière transparente pour l'abonné. pour la quatrième :
• Un abonné regarde la TV sur un terminal secondaire.
• Un autre abonné du foyer regarde la TV sur un autre terminal secondaire, indépendamment du premier terminal secondaire. (Selon le nombre de tuner intégré, il peut être possible d'utiliser plus de terminaux secondaires.) - le dispositif transcodeur permet la sélection de flux, de manière transparente pour l'abonné. - pour la cinquième :
• Un abonné regarde la TV sur son terminal principal, dans le salon. • Un autre abonné du foyer, mais en déplacement dans un autre pays, se connecte au terminal principal à l'aide d'un terminal secondaire, et peut accéder aux flux TV, comme s'il était dans le foyer.
• le dispositif transcodeur permet le « place shifting ». La figure 6 montre un diagramme par bloc de l'architecture détaillée d'un dispositif transcodeur selon l'invention.
L'architecture du client sera détaillée par la suite. Dans ce diagramme et dans la suite, le terme 'module' désigne un composant logiciel, matériel ou mixte qui réalise un ensemble de fonctions élémentaires cohérentes. Les regroupements de fonctions effectués pour définir les modules sont indicatifs et destinés à faciliter les explications. Ces modules peuvent être dupliqués, tripliqués ou plus en fonction des besoins, ce sont les suivants :
I ) Un module Tuner/Démodulateur -Digital Video Broadcasting-DVB 31 -1 , 31 -2 a pour objet de scanner la bande de fréquences, de trouver les fréquences qui transmettent des données, de transmettre les données au démultiplexeur pour l'analyse des tables du -System Information- SI (la table -Programm Association Table-PAT, la table -Programm Map Table-PMT, la table -Network Information Table- NIT, la table -Bouquet Information Table- BAT, la table -Service Description Table- SDT ...) puis de se caller sur une fréquence donnée et transmettre le flux -Transport Stream-TS au démultiplexeur pour lecture. Ce module permet de demander l'arrêt de la transmission du flux TS au démultiplexeur.
2) Un module de démultiplexage 32-1 , 32-2 permet d'analyser un flux TS et de stocker et/ou de mettre à jour le plan de service. Entre autre, la liste des chaînes, leur ordre, l'association d'une chaîneou d'une fréquence à un numéro de programme, ...)
Ce module effectue également l'extraction des flux (Audio/Vidéo/sous-titre) correspondant à une chaîne, et la transmission des flux (au format TS ou -Packetized Elementary Stream- PES) aux modules de transcodage Audio, Vidéo ou sous-titre et remonte le nom de la chaîne, le choix de la langue audio, le choix des sous-titres.
II effectue également l'extraction des sections -Event Information Table-EIT, TDT/TOT du TS et transmission au module de génération des données EPG
3) Le module d'encapsulation RTP 33 permet d'encapsuler selon le protocole rtp, les données issues des transcodeurs.
Il est également possible de configurer l'encapsulation en identifiant en entrée, le flux à paramétrer et les paramètres à utiliser (taille des paquets, mode d'encapsulation, configuration du décodeur). Ce module permet la génération d'un fichier SDP (Session Description Protocol) pour chaque session rtp ouverte. Ce fichier est transmis aux terminaux utilisateurs grâce au module de gestion des requêtes clients
4) Le module de Transcodage Vidéo 34 permet le transcodage des données issues du démultiplexage et la transmission au module d'encapsulation rtp. Ce module est en liaison avec le module de paramétrage 45 qui peut modifier les paramètres de transcodage en temps réel.
5) Le module de Transcodage Audio 35 permet le transcodage des données issues du démultiplexage et la transmission au module d'encapsulation rtp. Ce module est en liaison avec le module de paramétrage qui peut modifier les paramètres de transcodage en temps réel.
6) Le module de Transcodage de sous-titre 36 permet la sélection des sous- titres ayant la bonne langue (celle choisie par l'utilisateur) et assure la transmission au module d'encapsulation rtp.
7) Le module de décodage de données -Electronic Programm Guide- EPG 37-1 , 37-2 a pour fonction de décoder les données -Event Information Table-EIT,-Time
Offset Table-TOT et Time Division Table-TDT.
8) Le module de monitoring réseau et de paramétrage 38 a pour but de modifier les paramètres des modules de transcodages audio et vidéo en fonction: 1 - du type d'équipement utilisateur
2- du paramétrages de l'utilisateur
3- de la qualité du lien sans-fil
Les paramètres pouvant ainsi être modifiés sont d'une part au niveau du transcodeur vidéo le niveau du signal sur bruit vidéo, le nombre d'images par seconde et la résolution des images (taille de l'écran au niveau des terminaux de réception), d'autre part au niveau du transcodeur audio le taux d'encodage.
Plus précisément les éléments en fonction desquels ces paramètres sont modifiés, sont en ce qui concerne :
1 - Le type de terminal utilisateur (au niveau de la réception, o la résolution de l'écran o les formats audios supportés (par exemple si le format AAC+ n'est pas supporté, alors le transcodeur audio effectuera du transcodage au format mp3 par exemple). o les paramètres signal sur bruit et nombre d'images par seconde afin de rendre le débit nominal du flux compatible avec le type de connexion sans fil disponible sur tel ou tel terminal utilisateur (si un équipement possède une connexion WIFI 802.1 1 n alors il acceptera des débits nominaux supérieurs à un équipement qui possède une connexion WIFI 802.1 1 b).
Pour cela, le module de paramétrage accède à une base de données qui caractérise les différents terminaux se connectant au service (cette base est mise à jour régulièrement pour supporter les nouveaux terminaux sans-fils). La description du terminal utilisateur est automatiquement récupérée à la 1 ère connexion au niveau du module de gestion des requêtes clients.
2- La possibilité offerte à l'utilisateur de paramétrer par exemple la qualité minimum en termes de signal sur bruit, le nombre d'images par seconde et résolution minimale.
Ce type de paramétrage commande la qualité minimum en dessous de laquelle le service sera interrompu pour l'utilisateur.
Un profil utilisateur enregisté dans une base de données 46 agit sur le module de transcodage des sous-titres paramétrant la langue sélectionnée afin de filtrer les sous-titres dans la langue adaptée au choix de l'utilisateur.
3- le module de monitoring réseau qui analyse les temps d'aller-retour sur le réseau et le débit utilisé par le flux sur chaque lien sans-fil.
Cette mesure de débit réel prend en compte les retransmissions associées à un canal sans-fil bruité. L'indicateur pertinent est le débit réel divisé par le débit nominal. C'est une valeur supérieure à 1. Lorsque le canal est parfait et n'est pas bruité (ce qui correspond à une distance émetteur / récepteur de quelques mètres), l'indicateur de qualité du lien est égal à 1. Lorsque on augmente cette distance jusqu'à la limite de portée du canal sans-fil, l'indicateur peut augmenter de plusieurs multiples.
II existe une table prenant en entrée les indicateurs de qualité de chaque lien ainsi que le débit total et en fournit en sortie des paramètres de transcodage audio et vidéo.
Par exemple si <X1 > est l'indicateur du flux 1 et <X2> celui du flux 2 et ( X1 + X2) / débit max disponible est le ratio entre le débit réel utilisé par les 2 flux 1 et 2 par rapport au total disponible, alors en fonction de seuils sur ces 3 valeurs, on associe les paramètres de transcodages.
Le 3ème paramètre est important car il permet de gérer la coexistence entre plusieurs flux en parallèle et éviter qu'un flux vers un terminal en limite de zone, n'occupe la totalité des ressources au détriment d'un autre terminal proche.
9) Le module de gestion des requêtes client 39 est un serveur http qui réceptionne les requêtes utilisateur et transfert au module de pilotage. Il permet également la récupération du type d'équipement utilisateur et donne au module de paramétrage les informations nécessaires permettant
10) Le module de pilotage 40 initialise dans l'ordre, les modules suivant :
1. • Le module d'encapsulation RTP, Gestion des requêtes client
2. • Le module de transcodage (A/V/ST/EPG) 3. • Le module de paramétrage, Module de démultiplexage
4. • le module de monitoring réseau,
5. • Le module Démodulateur
Ce module de pilotage assure la détermination des chaînes/flux DVB disponibles (appel au démodulateur pour scanner la bande qui appellera le démultiplexeur pour analyser les flux) et également les flux disponibles depuis la plateforme de service en effectuant des requêtes vers la plateforme de service (format : Web Service. Requêtes http et réponses XML)
II permet de traiter une demande de connexion initiale (en provenance de l'utilisateur via le module de gestion des requêtes clients: détermination des paramètres nécessaires au démodulateur et demande de changement de fréquence détermination des paramètres et demande de changement de PID au démultiplexeur demande de mise à jour des paramètres d'encodage et d'encapsulation à partir des informations reçues dans la requête HTTP (profil utilisateur) et des paramètres réseau
Récupération de la description SDP (Session Description Protocol) • Pour les flux vidéo issues de serveurs de diffusion sur Internet, le module de pilotage récupère de la plateforme de service les urls de streaming de ces flux et envoie ces urls aux modules de décodage (si l'affichage se fait sur le terminal Principal) ou de transcodage (si l'affichage se fait sur les terminaux utilisateurs secondaires) Ce module permet aussi de traiter les demandes de changement de chaîne : détermination des paramètres nécessaires au démodulateur et demande de changement de fréquence détermination des paramètres et demande de changement de PID au démultiplexeur changement d'url de streaming dans le cas d'un flux diffusé par un serveur sur Internet
Ce module traite aussi de la mise en pause et de la fin d'un flux
1 1 ) Le module de génération de I' -Electronic Program Guide- 41 EPG agrégé récupère les données en provenance des flux DVB-T et DVB-H (en passant à travers des modules de décodage des EPG DBV-T et DVB-H)
Le format EPG est différent entre le flux DVB-T et DVB-H même si le même type d'information est fourni.
Ci-dessous est décrit l'ensemble des données EPG DVB-T tel que décrit dans la norme DVB :
PlD Abbr Nom Description
0x001 1 SDT Service Description Décht les services du système
0 0012 EIT Event Information Décrit les événements des services, par exemple, nom de Table l'événement, heure de départ, durée etc.
0x0014 TDT j^Definitl0n Fournit l'information sur la date et l'heure au format UTC
0x0014 TOT Time offset Table ieXseauSre ^ ^ '* ^ * ^* ^ ^* ^ ™™ ^
Ce module d'agrégation d'EPG peut être exécuté sur le boitier PINGO mais aussi au niveau de la Plateforme de Service. Dans le 1 er cas, le module d'agrégation d'EPG remonte à la plateforme de service les données élémentaires provenant des flux DVB démultiplexés. La remontée de ces données se fait sous forme de requête http
La plateforme de service renvoie au boitier Pingo des données enrichies sur le programme en cours. Ces données sont dans un format XML
Dans le 2ème cas, l'architecture décrite sur le schéma est répliqué au niveau serveur, c'est-à-dire que le serveurs de la plateforme récupèrent les EPG DVB à partir de tuners, démodulateurs et démultiplexeurs DVB situés côté plateforme. L'échange de données entre le client (boitier Pingo) et le serveur (Plateforme de
Service) selon un protocole type flux RSS avec date de rafraîchissement adaptée et calculée côté plateforme de service
L'intérêt de ce deuxième mode de réalisation est de limiter le besoin en ressource processeur et mémoire du boitier.
Ces flux XML de métadonnées enrichies sont décodés et incorporés à l'EPG agrégé (enrichi)
L'EPG est affiché sur les terminaux utilisateurs secondaires (en passant par le module d'encapsulation rtp et le module de communication sans-fil) ou pour le terminal principal (relié au boitier Pingo par l'interface Ecran TV (type péritel)
On décrira maintenant le flux de métadonnées enrichi :
Les métadonnées sont spécifiques à chaque type de flux et de programme en cours.
Une liste non exhaustive de type de programmes possibles est la suivante :
typel : Emission talk avec invités (que ce soit des émissions sur IP TV, flux DVB ou vidéos type You Tube)
titre : nom du programme (exemple : « T'empêches tout le monde de dormir ») heure de début et de fin animateur(s) nom de l'animateur 1
Photo de l'animateur liste des émissions avec le même animateur et liens vers podcasts vidéos vidéos YouTube avec comme mot clé l'animateur nom de l'animateur 2
• lnvité(s)
Nom de l'invité 1 actualité de l'invité 1 (une ou deux phrases) Bio de l'invité Photo de l'invité • Détails de son actualité (si c'est un livre, ça serait la page web du livre)
Videos You Tube de l'invité et/ou de son actualité Nom de l'invité 2
Vidéos You Tube relatives aux mots clés de l'émission • Flux connexes (dont l'émission en cours est proche de l'émission en cours d'écoute)
Liens publicitaires en liaison avec les sujets de l'émission (liens vers des livres par exemple)
Type 2 : film et série (diffusé par DVB, IP TV ou Vidéo à la Demande)
Nom du film
Heure de début et de fin • Producteur/metteur en scène
Noms des producteurs, metteurs en scène
Photos o Liste des films produits par ces producteurs ou mis en scène par ces metteurs en scène • Acteurs
Noms
Photos
Bios
Actualités • Filmographie
Type 3 : Clips musicaux (diffusé par DVB, IP TV ou Vidéos type You Tube) Nom du titre, album Jacquette de l'album Compositeurs, chanteurs Noms • Photos
Bios
Actualités Discographie Paroles de la chanson
Type 4 : Journal Télévisé (ou de manière générale, tout type de programme sans invités et avec des chroniques et un ou des animateurs)
Nom du journal • Heure de début et fin
Présentateur(s) nom du présentateur photo actualité du présentateur • Liste des chroniques
Nom de la chronique
Sujet de la chronique
Vidéos You Tube connexes (récupérés à partir des mots clés du sujet et nom de la chronique) • Emission/flux connexes (par exemple l'émission qui parle du même sujet sur une autre chaine)
Type 5 : vidéos (site de partage de vidéos sur Internet comme You Tube ou DailyMotion)
Nom de la vidéo Notation
Nombre de vidéos visionnées Liste de vidéos connexes • Liste d'émissions qui ont des sujets connexes
On décrira maintenant le mécanisme de synchronisation type RSS avec date de rafraîchissement adaptée : Dans le fichier XML de métadonnée envoyé au boitier PINGO, le durée de la séquence en cours pour que le boitier Pingo puisse télécharger le nouveau flux lorsqu'il est nécessaire de le faire et pas à fréquence régulière (ce qui induirait une charge trop importante sur la plateforme)
Constitution des métadonnées agrégées et enrichies côté plateforme de service
La plateforme de service se connecte à des sites de contenus partenaires pour récupérer les informations telles que les acteurs qui jouent dans un film et pourra récupérer auprès d'un autre site sous un autre format, les biographies de ces acteurs et ainsi de suite.
La plateforme de service a un rôle d'agrégation de contenus hétérogènes
12) Le module de I'- Electronic Service Guide - ESG contextuel 42.
L'ESG est dit contextuel lorsque les services disponibles sont dépendants de ce qui est diffusé en ce moment sur la chaine sélectionnée.
Il s'agit d'une communication entre le boitier Pingo et la plateforme de Service
Quatre types de services contextuels sont notamment possibles:
1. • Achat des albums, films, livres recommandés (dans les métadonnées enrichies et intégrées dans l'EPG agrégé) 2. • Possibilité d'accéder à ces contenus sur d'autres terminaux utilisateurs comme un téléphone ou un ordinateur connecté à la plateforme de service
3. • Pour certaines émissions, l'utilisateur peut voter
4. • Certains jeux types « question à choix multiples » peuvent être proposés à l'utilisateur
13) Le module de statistiques 43
Capte tous les enchaînements visualisés sur les terminaux utilisateurs cette information est remontée à la plateforme de service.
La plateforme de service croise ensuite les informations de grille de programme enrichie et historique de l'utilisateur pour d'écrire de manière précise les types d'émissions visualisés, les noms des animateurs/présentateurs favoris, les musiques préférées et les thèmes préférés. Ce module permet ensuite de pouvoir générer des bouquets de flux (DVB-T, DVB-H, IP TV, Vidéo à la demande ou Vidéo sur site de partager de vidéos) en fonction des goûts utilisateurs et de l'historique
14) Le module de transmission sans-fil peut utiliser l'une des normes suivantes: 802.1 1 b/g/a/n, Ultra Wide Band, Bluetooth 1.2, 2.0, 2.1 ou toute autre norme de communication permettant de faire transiter des paquets IP, en particulier le WIMAX.
Dans ce dernier cas, la mise en œuvre de l'invention permet de limiter les besoins de couvertures du DVB-T et DVB-H dans les zones peu denses en diffusant le flux TV re-encodés dans les derniers kilomètres via le réseau WIMAX.
Les normes Ethernet filaire et courant porteur sont également envisageables pour certaines applications La mise en œuvre des fonctions décrites plus haut est avantageusement faite sous forme logicielle, dansle cas où des/les fonctionnalités sont mises en œuvre en logique câblée, certaines informations peuvent être inutiles (par exemple les liens sont inhérents au câblage entre des blocs matériels ou circuits dédiés).
En complément, on peut préciser que la découverte des chaînes est conduite par le module de pilotage qui appelle le module de démodulation qui appelle à son tour N fois (pour chaque nouveau TS) le module de démultiplexage. On peut utiliser un fonctionnement inverse : le module de pilotage demande au démultiplexeur de demander au module de démodulation.
Dans la mise en œuvre logicielle de l'invention, des « thread » (segmentation de processus) peuvent être utilisés. Au minimum on peut mettre en œuvre des « thread » suivants : un pour le serveur HTTP et le module de pilotage, un pour le monitoring réseau, un pour la démodulation, un pour l'ensemble démultiplexage, transcodage, encapsulation et transmission. Dans ce dernier « thread », les fonctions de transcodage et encapsulation seraient appelées consécutivement quand des données sont démultiplexées. On peut également mettre en œuvre des « threads » séparés pour traiter les chaînes audio/vidéo/sous-titre/EPG. Dans ce cas, il faut transformer les fonctions de transcodage avec une fonction démarrage du transcodage et ajouter une fonction d'arrêt du transcodage.
On va maintenant détailler les modalités des échanges de données qui ont lieu lors de la mise en œuvre de l'invention et plus particulièrement des diagrammes de séquences.
Sur la Figure 7, est représenté un diagramme de séquence de la phase de découverte des chaînes. Sur la Figure 8 est représenté un diagramme de séquence d'une demande de connexion initiale.
Le traitement (transcodage, encapsulation, envoi) peut commencer dès que le démultiplexeur a été informé de la chaîne à traiter. On privilégie ici une solution où une négociation des ports de communication IP entre client et serveur n'est pas nécessaire (réduction du temps de latence) et pour cela on enverra les données RTP sur des adresses « IP multicast ». Afin que la session se termine et que les ressources soient libérées pour d'autres utilisateurs, il est nécessaire de prévoir un message de fin de connexion avec une requête HTTP POST. Sur la Figure 9, on a un diagramme de séquence d'une demande de fin de connexion. Sur la Figure 10, est représenté un diagramme de séquence d'une demande de changement de chaîne
II est important de souligner ici que le demande de changement de chaîne ne modifie pas le contenu du fichier SDP (configuration du décodeur, mode d'encapsulation, ...) donc il n'est pas nécessaire de renvoyer un SDP. On peut donc conserver la même session de « streaming » (moins de latence). Les requêtes de changement de chaîne peuvent donc être des POST HTTP.
Par ailleurs, en ce qui concerne les dialogues Client / Serveur et Architecture Client, on doit noter que l'on souhaite maximiser les possibilités de lecture du contenu sur les terminaux utilisateurs cibles dont les téléphones, et que les limitations actuelles des téléphones sont les suivantes :
- Ils disposent d'un navigateur sur la toile (« Web ») capable d'afficher du contenu graphique mais faisant appel à des programmes (« plugins ») externes pour jouer l'audio vidéo. Cette solution n'est pas la plus satisfaisante car l'intégration de l'EPG et de l'A/V dans ce cas serait trop limitée.
- Ils disposent d'un lecteur multimédia, capable de jouer de l'audio/vidéo et parfois des sous-titres, mais peu de lecteurs savent afficher une surcouche graphique et interactive.
La solution proposée par l'invention permet : - Aux lecteurs limités de pouvoir jouer au moins la partie Audio/Vidéo/Sous-titre. On pourrait envisager que la consultation de l'EPG et la sélection de la chaîne se fasse par une interface Web.
- Aux lecteurs avancés (GPAC) de jouer toutes les données sous forme intégrée. Cette solution s'appuie sur le dialogue client-serveur représenté sur la Figure 1 1 qui représente un diagramme de séquence du dialogue client-serveur. Cette solution nécessite le pré requis suivant au niveau du client :
- Support du protocole RTP : les contraintes de « paquetisation » que le lecteur devra supporter seront celles de la norme 3GPP PSS. Le lecteur devra notamment supporter les adresses « multicast ». - Support du protocole SDP : les descriptions SDP utilisées seront conformes à la norme 3GPP PSS. Elles contiendront au moins un flux audio, un flux vidéo et un flux de sous-titre (au format « 3GPP Timed Text »). Elles contiendront un flux 3GPP DIMS qui pourra être ignoré ou traité afin d'afficher l'EPG en surcouche graphique. - Possibilité d'envoyer des requêtes HTTP GET avec en attachement le profil du terminal (taille écran, capacité de décodage ...) : ce traitement pourra être fait directement dans le lecteur si un format graphique et interactif type SVG est supporté. Sinon, le navigateur « Web » du téléphone pourra être utilisé. Ce profil du terminal peut être stocké dans la base de données 46. - Possibilité d'envoyer des requêtes HTTP POST avec en paramètres les valeurs de la chaîne et des pistes audio et sous-titres souhaités : ce traitement pourra être fait directement dans le lecteur si un format graphique et interactif type SVG est supporté. Sinon, le navigateur Web du téléphone pourra être utilisé. On va maintenant détailler des exemples de mise en œuvre de l'invention. Dans ce premier mode de réalisation du décodeur selon l'invention, la liaison secondaire est réalisée au moyen d'une connexion sans fil du type WIFI entre le décodeur 1 et le lecteur 20. Le décodeur 1 distribue un flux de données secondaire dans une zone de couverture « éclairée » par le signal WIFI, d'environ 300 mètres autour du décodeur. La mise en œuvre d'un tel format d'échange consommant une quantité relativement importante d'énergie électrique, le décodeur est de préférence raccordé au secteur par un câble d'alimentation 2.
Le décodeur 1 selon l'invention est de préférence positionné à proximité d'une fenêtre du bâtiment à l'intérieur duquel se trouve le lecteur sur lequel l'utilisateur souhaite visualiser un contenu vidéo. Le décodeur 1 peut même être placé à l'extérieur du bâtiment, sur la façade de celui-ci, par exemple.
L'avantage d'un tel décodeur en ce qu'il est possible de le positionner de manière à recevoir un signal DVB de bonne qualité. Pour que le signal DVB ne subisse que peu de perte de puissance, il est préférable de positionner le décodeur près d'une fenêtre ou à l'extérieur du bâtiment. En conséquence, si l'utilisation d'un tel décodeur relais domestique était généralisée, la puissance du réseau d'antennes de diffusion DVB qu'il faudrait mettre en place serait à revoir à la baisse. En effet le nombre des antennes du réseau serait en nombre plus faible qu'initialement estimé. Cela conduirait à diminuer les coûts de déploiement du réseau DVB qui deviendrait alors un projet dont la mise en œuvre serait plus facile, en particulier pour un réseau DVB-H.
Le décodeur 1 est avantageusement muni de plusieurs antennes 3 pour capter le signal DVB. En effet, il a été constaté que la qualité de réception était fortement améliorée lorsque le système comportait plusieurs antennes ayant des orientations relatives différentes, garantissant ainsi une très bonne réception quelle que soit la position du décodeur par rapport au cône d'émission de l'antenne du réseau près de laquelle se situe le décodeur.
Le flux DVB-H reçu est décodé par une puce DVB-H 4 dédiée.
Après que le flux de données DVB-H a été décodé par la puce DVB-H 4, le flux de données décodé est transmis, le long de connexions internes 6, vers une unité de calcul CPU référencée par le chiffre 5 sur la figure 1.
Selon le protocole DVB, cinq canaux individuels indépendants sont multiplexes et transmis dans un même flux de données à une fréquence définie. Le premier canal
« + » représente le contenu vidéo de la chaîne n+1 , le deuxième canal « 0 » représente le contenu vidéo de la chaîne n, le troisième canal « -» représente le contenu vidéo de la chaîne n-1 , le contenu du quatrième canal « I » est un flux de données correspondant à des informations sur les données vidéos des trois premiers canaux, telles que des metadonnées, et le cinquième canal « Q » correspond à des données sur la qualité de transmission. Selon la norme DVB-H, le flux de données a un débit de 2 Mbps. Le flux de données correspondant à un canal vidéo individuel est donc de
384 kbps chacun.
Le traitement effectue par le CPU 5 consiste en la séparation, ou démultiplexage, des cinq canaux individuels composant le flux de données décodé primaire en autant de flux de données décodé individuels. Ces flux de données décodé individuels sont ensuite dirigés vers des moyens de stockage et de mémorisation. Plus précisément, des fichiers « + », « 0 » et « - », par exemple du type MPEG, sont simultanément et respectivement augmentés dynamiquement des données du flux DVB décodé et démultiplexé.
Eventuellement, le flux de données individuel, et donc le fichier correspondant, est enrichi de certaines des données contextuelles du quatrième canal « I » du flux DVB-H.
Un des fichiers « + », « 0 » et « - » est alors sélectionné pour être réémis vers le lecteur de l'utilisateur.
Dans un mode de réalisation préférentiel, le support physique du protocole secondaire est une liaison hertzienne locale, sans fil du type WIFI. La norme WIFI, par exemple 802.1 1 b, a un débit théorique de 1 1 Mbps, soit 6 Mbps en débit réel, sur une porteuse à 2,4 GHz, dans un périmètre de 300 mètres. Le décodeur 1 comporte donc des moyens d'émission WIFI 10 et une antenne 1 1 associée au.
Le décodeur 1 couvre une zone importante dans laquelle un utilisateur identifié peut avoir plusieurs dispositifs de visualisation du signal vidéo, ou bien plusieurs utilisateurs peuvent recevoir le même signal vidéo.
L'avantage de l'utilisation du format WIFI est qu'il a été défini pour encapsuler des datagrammes IP. Ainsi, en cas d'utilisation de datagrammes IP encapsulés dans le format DVB-H, ceux-ci sont simplement réencapsulés dans le format WIFI. De son coté, le lecteur vidéo 20 portable comporte une antenne 21 et des moyens aptes à la réception et au décodage des signaux WIFI 22 captés. Le flux de données secondaire ainsi reçu est traité par le CPU 25 du lecteur 20 pour être affiché sur un écran 23 de ce lecteur. Dans le mode de réalisation actuellement préféré, le décodeur 1 communique directement avec le lecteur, sans passer par l'intermédiaire d'un routeur domestique. En effet, sur un lien de communication partagé entre plusieurs services, il a été constaté que la diffusion d'un flux vidéo est facilement perturbée par les autres données transitant sur ce lien. Par exemple, le téléchargement de fichiers depuis l'Internet en parallèle avec la diffusion d'un flux vidéo perturbe ce dernier. La vidéo est affichée de manière saccadée. En conséquence, on préférera disposer d'une liaison locale WIFI dédiée à la rediffusion du flux vidéo.
On pourrait imaginer qu'une évolution prochaine du protocole de communication WIFI introduise la notion de hiérarchie et de priorité entre paquets de données. De la sorte, l'on pourrait donner une priorité supérieure au flux vidéo par rapport à des activités Internet menées en parallèle, tel que le téléchargement de fichiers. Grâce à cette évolution du format WIFI, le décodeur DVB pourrait être intégré à un routeur domestique et la connexion WIFI pourrait être partagée entre plusieurs utilisateurs ou fonctionnalités. Alternativement, le décodeur pourrait communiquer avec le routeur domestique au moyen d'une liaison filaire ou sans fil, le routeur réémettant à son tour le flux vidéo en direction du lecteur vidéo par une liaison locale sans fil WIFI. Notion de navigation intraflux (d'un canal vidéo à l'autre)
Les différents canaux vidéo diffusés par la télévision numérique sont répertoriés dans une liste ordonnée. Chaque fréquence particulière de fonctionnement de la télévision numérique selon la norme DVB porte trois canaux multiplexes choisis successivement dans cette liste : un canal central « n » et deux canaux voisins respectivement directement au-dessus « n+1 » et directement au-dessous « n-1 » du canal central.
Les moyens de réception DVB-H comportent une fonctionnalité « tuner » permettant au récepteur DVB-H de passer d'une première fréquence f1 de réception à une seconde fréquence f2 voisine, par exemple directement au-dessus de la première fréquence. Alors que la première fréquence f 1 porte les canaux n-1 , n et n+1 , le canal n étant le canal central « 0 » pour cette fréquence f1 , la seconde fréquence f2 porte les canaux n, n+1 et n+2, le canal central « 0 » correspondant pour cette seconde fréquence f2 au canal n+1. Cette fonction « tuner » correspond donc à la capacité de passer d'un groupe de canaux à un autre groupe de canaux situés immédiatement au- dessus dans la liste ordonnée des canaux vidéo diffusés.
A côté de cette fonctionnalité de sélection en fréquence, le décodeur 1 selon l'invention dispose d'une fonctionnalité permettant à l'utilisateur de sélectionner un canal vidéo parmi les trois canaux vidéo présents dans un flux de données DVB-H décodé à l'instant présent. Il s'agit d'une sorte de navigation à l'intérieur d'un flux de données DVB-H caractérisé par une fréquence constante de fonctionnement des moyens de réception du flux DVB-H. Ainsi, d'une manière qui sera décrite ci-après en détail, l'utilisateur, alors qu'il était en train de visualiser le programme vidéo associé au canal central « 0 », décide de visualiser le contenu du canal immédiatement au-dessus « + » ou au-dessous « - » du canal central, en actionnant la fonctionnalité de navigation « intraflux ». Ainsi, alors que le fichier « 0 » correspondant au canal « 0 » était retransmis vers les moyens de retransmission 7, 10 et 1 1 , c'est maintenant le fichier « + » qui est retransmis et visualisable sur l'écran du lecteur 20.
Cette fonctionnalité permet une très grande fluidité de l'utilisation du service de télévision numérique. En effet, la fonction « tuner » des moyens de réception DVB permettent également de naviguer parmi les canaux diffusés, mais à chaque modification de la fréquence de réception, il faut recréer les fichiers « 0 », « + » et « - » et attendre qu'il ait un volume suffisant pour permettre une diffusion secondaire sans rupture du flux. Cela représente donc un certain temps mort. De plus, dans les installations connues de télévision IP, il a été constaté que du fait même de l'utilisation du protocole IP, un temps de latence important existe lors d'un changement de chaîne. En effet, le temps de recréer une connexion IP transportant des informations vidéo relatives à la nouvelle chaîne et le temps de stocker dans une mémoire tampon suffisamment d'informations pour assurer ultérieurement un affichage fluide et continu du programme vidéo, est d'environ 10 à 15 s. Ce temps de latence est rédhibitoire pour que l'utilisateur final d'un système de visualisation portable soit satisfait par ce nouveau moyen de regarder un programme vidéo. Au contraire, la navigation intraflux selon l'invention constitue un découplage entre l'utilisation de la fonction « tuner » et la sélection du canal vidéo sélectionné.
Avantageusement, alors que le fichier correspondant à un canal individuel est émis vers lelecteur, la fonction tuner DVB est activée pour caller la réception primaire sur la fréquence immédiatement au-dessus de la fréquence reçue jusqu'à présent. Ainsi, le canal vidéo individuel sélectionné et actuellement visualisé, correspond maintenant au canal central « 0 » du flux de données DVB-H primaire. Lors de ce changement de fréquence, un nouveau fichier tampon MPEG correspondant au canal n+2 nouvellement décodé est crée ; les fichiers correspondants aux canaux communs n et n+1 continuent d'être décodés et sont mis à jour, éventuellement en en changeant le nom ; et le fichier correspondant au canal n-1 qui n'est plus décodé est supprimé.
Pour naviguer, l'utilisateur choisit un canal par l'intermédiaire d'une télécommande 30, soit réelle et dédiée au décodeur 1 , soit virtuelle et émulée par un logiciel exécuté sur le lecteur vidéo portable 20. Dans ce dernier cas, les données de sélection du canal sont transmises du lecteur 20 vers le décodeur 10 en utilisant le flux montant de la liaison bidirectionnelle WIFI.
Dans le cas de l'utilisation d'une télécommande 30 réelle, la navigation se fait par l'utilisation des boutons de sélection + 31 et - 32. Leur actionnement génère l'envoi d'informations par exemple au moyen d'une liaison infrarouge entre des moyens d'émission 35 de la télécommande 30 vers des moyens de réception IR 15 dont est équipé le décodeur 10. La communication entre la télécommande 30 et le décodeur 1 peut se faire selon un protocole de communication propriétaire.
De préférence, la télécommande comporte un écran LCD 36 sur lequel les metadonnées correspondantes au canal vidéo actuellement affiché sur le lecteur. Cet écran LCD 36 comporte, dans sa partie supérieure, une série de cristaux liquides 37 alignés permettant d'indiquer la puissance du signal DVB capté par le décodeur 1. Cette fonctionnalité permet de placer le décodeur de sorte que la réception du signal DVB soit la meilleure possible. Dans l'alternative consistant à émuler des moyens de navigation intraflux sur le lecteur 20, un logiciel correspondant à une télécommande virtuelle peut être téléchargé lors de la première connexion s'établissant entre le décodeur 1 et le lecteur 20. Ce logiciel téléchargé est ensuite exécuté pour munir le lecteur 20 de cette fonctionnalité virtuelle. Cryptage des données vidéo
Les données vidéo multiplexées dans le flux DVB primaire peuvent être cryptées par l'opérateur de manière à ne permettre la visualisation du contenu qu'à des utilisateurs identifiés. Deux architectures sont alors possibles.
Selon une première architecture représentée sur la figure 1 , après décodage, un flux de données décodé crypté correspondant à un canal individuel est réémis vers le lecteur, et l'opération de décryptage à lieu au niveau du lecteur 20. Pour cela, le lecteur 20 comporte une carte à puce 26 d'identification du lecteur et de son utilisateur. L'utilisation de cette première architecture nécessite la transmission d'une clé de décryptage jusqu'au lecteur 20. Ceci peut être réalisé à intervalle régulier, par exemple tous les mois, par l'émission par l'opérateur d'un flux DVB dont le quatrième canal, dit d'information, véhicule ces données de clé. Un fichier tampon de transmission de la clé est alors émis du décodeur 1 vers le lecteur 20.
Une fois que le lecteur 20, identifié grâce à sa carte à puce, a reçu et mémorisé la clé correspondante, il est apte à décrypter le signal vidéo reçu pendant toute la durée de validité de ladite clé. Le CPU 25 du lecteur 20 lit la clé de décryptage mémorisée dans une mémoire morte dudit lecteur 20 afin de décrypter le flux vidéo secondaire reçu. Le CPU 25 est ensuite apte à transmettre les données décryptées vers l'écran 23. Carte à puce sur le décodeur Selon une seconde architecture, le décodeur 1 est identifiable par sa propre carte à puce 8 (représenté en pointillés sur la figure 1 ). Après identification selon un procédé connu, une clé de décryptage peut être transmise à travers le quatrième canal d'information du flux DVB vers ce décodeur identifié. La clé une fois disponible permet au CPU 5 de décrypter les différents flux des canaux vidéo. Selon cette variante de réalisation, les moyens 7, 10 et 1 1 mettent à disposition un signal vidéo secondaire décrypté.
En conséquence, celui-ci peut être affiché par plusieurs lecteurs situés dans la zone de couverture de l'antenne WIFI 1 1. C'est la raison pour laquelle, de préférence, la liaison WIFI entre le décodeur 1 et un lecteur 20 est sécurisée. Dans ce schéma de contrôle du flux secondaire diffusé, le signal n'est pas de nouveau encodé, mais est simplement sécurisé. Ceci est par exemple réalisable en utilisant un protocole WIFI sécurisé, ou d'autres protocoles WPA ou WPA 2. II est également à noter la possibilité de munir le décodeur 1 d'un moyen de traitement intermédiaire 14 pour les flux individuels de données décodées. Il a été évoqué ci-dessus la possibilité d'enrichir le fichier correspondant à un canal vidéo individuel de métadonnées. De plus, lorsque le protocole de communication secondaire constitue une contrainte, il est également possible de compresser les flux individuels de manière à générer des fichiers individuels compressés dont le volume plus faible est compatible avec le débit de la liaison secondaire. Mode de réalisation 1 décodeur BLUETOOTH
En alternative à l'utilisation d'un protocole secondaire sur un support WIFI, un protocole secondaire fondé sur un support BLUETOOTH est également envisagé. Le format de communication BLUETOOTH définit par exemple par la norme IEEE
802.15.1 présente l'avantage de couvrir une zone réduite d'environ 100 mètres de rayon autour de l'émetteur. Ce moyen de réémission d'un flux vidéo secondaire par un décodeur de télévision numérique selon l'invention est particulièrement bien adapté à un véhicule. Et ceci d'autant plus que ce format est d'ores et déjà utilisé pour toute une série d'applications dans l'univers automobile.
L'avantage supplémentaire d'une connexion BLUETOOTH réside en ce que dès à présent, un grand nombre des téléphones portables et PDA vendus est équipé de moyens de communication BLUETOOTH.
De plus le décodeur peut alors être autonome. Il comporte dans ce cas une batterie de faible puissance rechargeable, par exemple au moyen d'une cellule solaire associée au décodeur lorsqu'il est placé sur la façade du bâtiment ou sur la lunette arrière d'une voiture.
L'utilisation d'une liaison BLUETOOTH nécessite l'association initiale du lecteur et du décodeur. Cette étape d'appariement peut se faire simplement en saisissant sur le lecteur une clé caractérisant la liaison BLUETOOTH du décodeur, indiquée par exemple sur une étiquette placée sur le dessous de celui-ci.
L'invention peut être déclinée de nombreuses autres manières que celles spécifiquement décrites à titre d'exemple. Notamment les fonctionnalités peuvent être mises en œuvre par logiciel plutôt que câblées ou en mode mixte (câblé + logiciel), ces fonctionnalités peuvent être étendues ou limitées en fonction des usages : limitation des capacités du démodulateur par exemple, du type de signal DVB, du choix des flux : en clair ou non, cryptage sur la liaison radio locale ou non, choix du procédé de compression de données adaptatif, choix des paramètres définissant la qualité de la liaison locale (temps de latence, débit, taux de retransmission...)...

Claims

REVENDICATIONS
1. Décodeur de flux audio/vidéo au format DVB, caractérisé en ce qu'il comporte : des moyens de réception d'un flux de données primaire selon le protocole de communication DVB ayant des données de contenu correspondant à une pluralité de canaux ; - des moyens d'extraction, de séparation et de traitement des données de contenu dudit flux primaire pour produire une pluralité d'ensembles de données, chaque ensemble de données correspondant à un canal dudit flux primaire; et, des moyens de réémission d'un ensemble parmi lesdits ensembles de données en tant que données de contenu d'un flux de données secondaire dans un protocole de radio communication secondaire locale vers un terminal d'un utilisateur pour restitution du flux, le protocole de communication secondaire constituant une contrainte sur le débit du flux de données secondaire par rapport à celui du flux primaire, ledit décodeur comportant des moyens de compression de l'ensemble de données réémis, lesdits moyens de compression étant adaptatifs en fonction d'au moins un critère de qualité de transmission de la radio communication secondaire locale.
2. Décodeur selon la revendication 1 , caractérisé en ce que au moins un critère de qualité de transmission de la radio communication secondaire locale sont choisis parmi :
- temps de latence entre une demande de restitution et la restitution sur le terminal,
- débit de transmission sur la radio communication secondaire locale,
- taux de réémission radio du fait d'erreur de transmission sur la radio communication secondaire locale,
3. Décodeur selon l'une quelconque des revendications 1 et 2, caractérisé en ce que lesdits moyens de compression sont adaptatifs en fonction d'au moins un critère de résolution de la restitution du flux du terminal utilisateur.
4. Décodeur selon l'une quelconque des revendications 1 à 3, caractérisé en ce que le protocole de communication du flux secondaire est fondé sur un protocole de communication sans fil, de préférence WIFI ou BLUETOOTH.
5. Décodeur selon l'une quelconque des revendications 1 à 3, caractérisé en ce que le protocole de communication du flux secondaire est fondé sur un protocole de communication filaire, de préférence du type Courants Porteurs en Ligne.
6. Décodeur selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte des moyens de navigation intra-flux DVB permettant la sélection de l'ensemble de données effectivement réémis par lesdits moyens d'émission, parmi ladite pluralité d'ensembles de données.
7. Décodeur selon la revendication 6, caractérisé en ce que lesdits moyens de navigation intra-fux comportent une partie déportée du boîtier du décodeur, de préférence sur une télécommande ou sur un lecteur apte à fonctionner avec ledit décodeur.
8. Décodeur selon l'une quelconque des revendications 1 à 7, caractérisé en ce que, les données de contenu dudit flux primaire étant cryptées, il comporte des moyens de décryptage des données du flux primaire, de sorte que le contenu dudit flux secondaire réémis est décrypté.
9. Décodeur selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits moyens d'émission permettent la réémission d'un flux secondaire sécurisé.
10. Décodeur selon l'une quelconque des revendications précédentes, caractérisé en ce que le protocole de communication secondaire constitue une contrainte sur le débit du flux de données secondaire par rapport à celui du flux primaire, ledit décodeur comportant alors des moyens de compression de l'ensemble de données réémis.
1 1. Procédé de décodage d'un flux de données DVB, caractérisé en ce qu'il comporte les étapes consistant à: capter un flux primaire de données au format DVB; extraire, séparer et traiter les données de contenu dudit flux primaire de manière à produire une pluralité de flux individuels de données décodées correspondant chacun à l'un des canaux dudit flux primaire ; retransmettre un desdits flux individuels correspondant à un canal vidéo au moyen d'un protocole secondaire de communication locale.
12. Procédé selon la revendication 1 1 , caractérisé en ce que ledit protocole secondaire est fondé sur une liaison de communication secondaire sans fil du type WIFI ou BLUETOOTH.
13. Procédé selon l'une des revendications 1 1 et 12 caractérisé en ce que les flux individuels étant cryptés, le procédé consiste en outre à décrypter lesdites données.
14. Procédé selon la revendication 13, caractérisé en ce que ladite étape de décryptage est réalisée avant ladite étape de retransmission, et en ce que le procédé comporte une étape initiale d'établissement d'une liaison de communication secondaire sécurisée pour la retransmission dudit flux secondaire décrypté.
15. Procédé selon l'une quelconque des revendications 1 1 à 14, caractérisé en ce qu'il comporte une étape consistant à compresser lesdits flux individuels de données avant ladite étape de retransmission secondaire.
PCT/FR2008/051159 2007-06-25 2008-06-25 Décodeur de flux dvb WO2009007600A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0756012 2007-06-25
FR0756012A FR2917933B1 (fr) 2007-06-25 2007-06-25 Decodeur de flux dvb.

Publications (1)

Publication Number Publication Date
WO2009007600A1 true WO2009007600A1 (fr) 2009-01-15

Family

ID=38982544

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2008/051159 WO2009007600A1 (fr) 2007-06-25 2008-06-25 Décodeur de flux dvb

Country Status (2)

Country Link
FR (1) FR2917933B1 (fr)
WO (1) WO2009007600A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090268649A1 (en) * 2008-04-25 2009-10-29 Qualcomm Incorporated Multiradio-database systems and methods
WO2010126545A1 (fr) * 2009-04-27 2010-11-04 Qualcomm Incorporated Systèmes et procédés de transfert de diffusion multimédia
WO2016071912A1 (fr) 2014-11-05 2016-05-12 Insuline Medical Ltd. Dispositif de suivi d'un médicament
US11833333B2 (en) 2017-07-12 2023-12-05 Insuline Medical Ltd Drug tracking device

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000076217A1 (fr) * 1999-06-03 2000-12-14 Opentv, Inc. Assistant numerique domestique
WO2001017255A1 (fr) * 1999-08-27 2001-03-08 Nokia Corporation Terminal multimedia mobile pour dvb-t et communication par cellules de petite et grande tailles
WO2001047248A2 (fr) * 1999-12-22 2001-06-28 Koninklijke Philips Electronics N.V. Fourniture a distance de contenu multimedia, a partir de dispositifs electroniques d'utilisateurs
EP1150506A2 (fr) * 2000-04-28 2001-10-31 Nokia Corporation Procédé et système de fourniture securisée de données de contenu concernant un abonné
US6339450B1 (en) * 1999-09-21 2002-01-15 At&T Corp Error resilient transcoding for video over wireless channels
WO2004088983A2 (fr) * 2003-04-03 2004-10-14 Koninklijke Philips Electronics N.V. Acheminement de medias electroniques a un dispositif sans fil
EP1494375A2 (fr) * 2003-06-30 2005-01-05 Nokia Corporation Transmission de données
EP1521476A1 (fr) * 2003-09-30 2005-04-06 Sharp Kabushiki Kaisha Transmission vidéo sans fil
GB2410160A (en) * 2004-01-15 2005-07-20 Jason Andrew Rees Base station for transmitting audio visual signal to a mobile device in a home network
US20060015783A1 (en) * 2000-10-31 2006-01-19 Takeshi Nagai Data transmission apparatus and method
EP1633161A1 (fr) * 2003-06-11 2006-03-08 NEC Corporation Dispositif recepteur de signal de support, dispositif emetteur et systeme emetteur-recepteur
EP1681789A1 (fr) * 2005-01-12 2006-07-19 Sagem SA Système et procédé de réception d'un flux numérique
EP1771003A1 (fr) * 2005-09-29 2007-04-04 Siemens Informatica S.p.A. Technologie permettant une interactivité multiple dans un environnement DVB-T

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8001251B2 (en) * 2005-01-21 2011-08-16 Panasonic Corporation AV server

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000076217A1 (fr) * 1999-06-03 2000-12-14 Opentv, Inc. Assistant numerique domestique
WO2001017255A1 (fr) * 1999-08-27 2001-03-08 Nokia Corporation Terminal multimedia mobile pour dvb-t et communication par cellules de petite et grande tailles
US6339450B1 (en) * 1999-09-21 2002-01-15 At&T Corp Error resilient transcoding for video over wireless channels
WO2001047248A2 (fr) * 1999-12-22 2001-06-28 Koninklijke Philips Electronics N.V. Fourniture a distance de contenu multimedia, a partir de dispositifs electroniques d'utilisateurs
EP1150506A2 (fr) * 2000-04-28 2001-10-31 Nokia Corporation Procédé et système de fourniture securisée de données de contenu concernant un abonné
US20060015783A1 (en) * 2000-10-31 2006-01-19 Takeshi Nagai Data transmission apparatus and method
WO2004088983A2 (fr) * 2003-04-03 2004-10-14 Koninklijke Philips Electronics N.V. Acheminement de medias electroniques a un dispositif sans fil
EP1633161A1 (fr) * 2003-06-11 2006-03-08 NEC Corporation Dispositif recepteur de signal de support, dispositif emetteur et systeme emetteur-recepteur
EP1494375A2 (fr) * 2003-06-30 2005-01-05 Nokia Corporation Transmission de données
EP1521476A1 (fr) * 2003-09-30 2005-04-06 Sharp Kabushiki Kaisha Transmission vidéo sans fil
GB2410160A (en) * 2004-01-15 2005-07-20 Jason Andrew Rees Base station for transmitting audio visual signal to a mobile device in a home network
EP1681789A1 (fr) * 2005-01-12 2006-07-19 Sagem SA Système et procédé de réception d'un flux numérique
EP1771003A1 (fr) * 2005-09-29 2007-04-04 Siemens Informatica S.p.A. Technologie permettant une interactivité multiple dans un environnement DVB-T

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090268649A1 (en) * 2008-04-25 2009-10-29 Qualcomm Incorporated Multiradio-database systems and methods
US8638810B2 (en) * 2008-04-25 2014-01-28 Qualcomm Incorporated Multiradio-database systems and methods
US9083474B2 (en) 2008-04-25 2015-07-14 Qualcomm Incorporated Multimedia broadcast forwarding systems and methods
WO2010126545A1 (fr) * 2009-04-27 2010-11-04 Qualcomm Incorporated Systèmes et procédés de transfert de diffusion multimédia
WO2016071912A1 (fr) 2014-11-05 2016-05-12 Insuline Medical Ltd. Dispositif de suivi d'un médicament
US11833333B2 (en) 2017-07-12 2023-12-05 Insuline Medical Ltd Drug tracking device

Also Published As

Publication number Publication date
FR2917933A1 (fr) 2008-12-26
FR2917933B1 (fr) 2009-10-30

Similar Documents

Publication Publication Date Title
US10951856B2 (en) Transcoding and caching for off air television programming delivery
EP2039159B1 (fr) Procede d&#39;affichage d&#39;une image mosaïque au sein d&#39;un recepteur pour la selection de programmes audiovisuels, recepteurs et serveurs associes
WO2004086767A2 (fr) Traitement d’un format de flux de donnees pour la reception audiovisuelle mobile
WO2012092790A1 (fr) Procédé et système de collecte, de transmission, d&#39;édition et d&#39;intégration, de diffusion et de réception de signaux
US20110197229A1 (en) Method and apparatus to broadcast content to handheld wireless devices via digital set-top-box receivers
EP3127336A1 (fr) Dispositif et procédé de commande a distance de la restitution de contenus multimedia
CN110087093A (zh) 信息处理装置和方法以及非暂态计算机可读介质
US8612456B2 (en) Scheduling recording of recommended multimedia programs
FR3006541A1 (fr) Appareil de reception video pour l&#39;elaboration d&#39;un contenu video recevable a partir d&#39;une pluralite de plateformes de distribution et methode d&#39;elaboration d&#39;un tel contenu video
CN110225421A (zh) 客户端设备、内容分发方法、计算机可读存储介质及用途
WO2009007600A1 (fr) Décodeur de flux dvb
FR2898458A1 (fr) Procede pour la distribution securisee de sequences audiovisuelles, decodeur et systeme pour la mise en oeuvre de ce procede
FR2944933A1 (fr) Procede de diffusion de donnees numeriques.
US20040234234A1 (en) Content selection
EP1798999B1 (fr) Procédé de gestion du comportement d&#39;une application interactive lors de la diffusion d&#39;un programme selon la norme DVB-H
EP1681789B1 (fr) Système et procédé de réception d&#39;un flux numérique
EP1804500A1 (fr) Téléviseur multifonction et autonome
CN101917327A (zh) 一种流媒体收录方法及一种播放器
EP4254968A1 (fr) Procédé de génération d&#39;une chaîne de télévision virtuelle pour un utilisateur d&#39; au moins un service de diffusion de contenus audiovisuels, dispositif de génération, équipement de service et programme d ordinateur correspondants
US10440328B2 (en) Method and apparatus to synchronize personalized co-cast content with user viewing habits
WO2013102745A1 (fr) Controle de services a la demande communiques en mode de diffusion
Yim et al. Implementation of a Prototype Personal Live Broadcasting System
EP2200317A1 (fr) Dispositif source d&#39;un réseau de communication audiovisuel domestique, procédé de gestion et produit programme d&#39;ordinateur correspondant.
EP1804023A1 (fr) Baladeur multifonction et autonome
Nuuri Internet protocol television (IPTV) services

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: 08806088

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08806088

Country of ref document: EP

Kind code of ref document: A1