EP1941734A1 - Procedes de filtrage, de transmission et de reception de flux video scalables, programmes, serveur, noeud intermediaire et terminal correspondants - Google Patents

Procedes de filtrage, de transmission et de reception de flux video scalables, programmes, serveur, noeud intermediaire et terminal correspondants

Info

Publication number
EP1941734A1
EP1941734A1 EP06777838A EP06777838A EP1941734A1 EP 1941734 A1 EP1941734 A1 EP 1941734A1 EP 06777838 A EP06777838 A EP 06777838A EP 06777838 A EP06777838 A EP 06777838A EP 1941734 A1 EP1941734 A1 EP 1941734A1
Authority
EP
European Patent Office
Prior art keywords
data units
filtering
data
video stream
paths
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
EP06777838A
Other languages
German (de)
English (en)
Inventor
Isabelle Amonou
Stéphane PATEUX
Gérard Babonneau
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1941734A1 publication Critical patent/EP1941734A1/fr
Ceased legal-status Critical Current

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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234381—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the temporal resolution, e.g. decreasing the frame rate by frame skipping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234354—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering signal-to-noise ratio parameters, e.g. requantization
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234363—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the spatial resolution, e.g. for clients with a lower screen resolution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4621—Controlling the complexity of the content stream or additional data, e.g. lowering the resolution or bit-rate of the video stream for a mobile client with a small screen
    • 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/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64784—Data processing by the network
    • H04N21/64792—Controlling the complexity of the content stream, e.g. by dropping packets

Definitions

  • the field of the invention is that of the processing of video signals, and more particularly video sequences compressed in scalable or scalable form. More specifically, the invention relates to the improvement of the operation of a scalable stream, in particular, but not exclusively, within the framework of the coding scheme currently developed in MPEG4-SVC. This MPEG4-SVC technique is notably presented in the documents:
  • JVT Joint Video Team
  • JSVM Scalable Video Model Joint
  • Such encoders are very useful for all applications for which the generation of a single compressed stream, organized in several layers of scalability, can serve several clients of different characteristics, for example:
  • VOD target terminals: UMTS, PC ADSL, TV ADSL, ..
  • a scalable video stream can be considered as a set of substreams represented by cubes 11 in a three-dimensional space formed of the three spatial dimensions 12, temporal 13, and quality, where SNR, 14 (S, T, Q), as schematically illustrated in FIG.
  • the size of the increments in the different directions corresponds to the "granularity" of the scability: it can be fine, average (10% of flow per increment of scalability: MGS) or coarse (25% of flow per increment, CGS).
  • MGS fine, average
  • CGS coarse
  • the CGS scalability corresponds to a "layered" system ("layers” in the document MPEG2005 / M 12043, April 2005. "ISO / MP4 File Format for Storage of Scalabie Video", Thomas Rathgen, Peter Amon and Andréas Hutter) and MGS scalability to a "level” system in this same document. 2.1.2 Fine Scalability Mode (MGS)
  • a scalable bit stream can be arranged to support fine scalability.
  • MGS Medium Grain Scalability
  • any coherent substream can be extracted (including the base level) and decoded with the corresponding quality, ie any combination of supported resolutions (time, spatial or SNR) can be extracted.
  • the MGS bitstreams allow for the highest flexibility. 2 J, 3 Layered Scalability Mode
  • a binary train can be organized in layers. We will then talk about CGS flow ("Coarse Grain Scalability"). A layer contains all the scalability levels necessary to move to the top quality layer.
  • a layer must increase the quality in at least one direction (temporal, spatial or SNR).
  • a CGS representation allows simple adaptation operations, especially at the nodes of the network.
  • the evolutions of the information in the quality-spatial resolution-temporal resolution space are defined a priori according to the conditions imposed by an application or by a user of the service. 2.2 MPBG-4 SVC
  • the JSVM MPEG is described in the already mentioned JSVM 2.0 document.
  • the model that has been chosen is based on a scalable encoder strongly oriented towards AVC type solutions, whose schematic structure of a corresponding encoder is shown in Figure 2. It is a pyramid structure.
  • the video input components 20 undergo dyadic subsampling (2D decimation by 2 referenced 21, 2D decimation by 4 referenced 22).
  • Each of the subsampled streams is then subjected to a time division 23 of the MCTF type ("Motion Compensated Temporal Filtering" for "motion compensated temporal filtering").
  • a low resolution version of the video sequence is encoded 14 up to a given bit rate R_rO_max which corresponds to the maximum decodable bit rate for the low spatial resolution r ⁇ (this base level is AVC compatible).
  • the higher levels are then encoded 25, 26 by subtracting the previous reconstructed and over-sampled level and encoding the residuals as: a base level; - Possibly one or more levels of enhancement obtained by multi-pass coding bit planes (hereinafter called FGS for "Fine Grain Scalability", fine grained scalability).
  • the prediction residue is encoded up to a rate R_rLmax which corresponds to the maximum decodable bit rate for the resolution ri.
  • the MCTF filtering blocks 23 perform temporal wavelet filtering, that is to say they realign the signals in the direction of motion before filtering in wavelets: they deliver motion information 27 which feeds a block motion coding 24-26, and texture information 28, which feeds a prediction module 29.
  • the predicted data at the output of the prediction module 29 serves to perform an interpolation 210 from the lower level. They also feed a block 211 of spatial transformation and entropy coding, which works on levels of signal refinement.
  • a multiplexing module 212 orders the different subflows generated in a global compressed data stream. This new approach is able to provide grain scalable feeds average in the temporal, spatial, and quality dimensions.
  • FGS bit planes
  • the texture information is coded using a progressive scheme at each level:
  • Base Layer a first level of minimum quality
  • the SVC encoder is based on a two-layer system, like AVC:
  • VCL layer (“Video Coding Layer”) manages the encoding of the video
  • NAL Network Abstraction Layer
  • NALU NAL Units
  • data units provided by the VCL layer.
  • a NALU is an elementary unit containing the base level of a Spatiotemporal Image, containing all (in the current version) or part (being discussed for versions future) of an FGS level of a spatio-temporal image;
  • An AU is the set of NALUs corresponding to a time instant.
  • JSVM Two signaling modes (corresponding substantially to CGS and MGS modes) are currently being discussed in the JSVM: a fixed path signaling mode, and a variable path signaling mode.
  • T, Q a two-dimensional 2D context
  • a scalable video stream contains the nested CIF sub-flow representations, of 15 Hz temporal resolutions (31) and Hz (32).
  • the flow consists of four NALUs A (O), B (2), C (I) and D (2). Using these four NALUs we can obtain the flow-distortion points a, b, c, d.
  • the priority of the NALUs is indicated in parentheses.
  • This mode signals a unique path in 3D space for extracting the scalable ftux. It is well adapted to the CGS mode for some applications. In the example of Figure 3, a fixed path will be chosen, for example (a, c, d).
  • This mode proposes to leave the application (or network) the choice of the extraction path.
  • the filtering rules used here are: For a time resolution T target (30 or 15 Hz) keep all
  • the method is generalizing to more than two dimensions. In the example illustrated by FIG. 4A, there are three dimensions of scalability:
  • T Time: 15 Hz / 30 Hz
  • the "priority fiels” contains the priority indicator and the "decolability info” contains the information of spatial, temporal and quality resolution. Both of these indicators require a two-byte representation.
  • a NAL will be identified by its four indices (P, D, T, Q) accessible for example in the file header where: P indicates the priority;
  • T indicates the temporal resolution
  • Q indicates quality, or complexity. It should be noted that the cells in bold of the table above have anomalies with respect to the requested spatial and temporal resolution: in QCIF 30 Hz, it would be desirable to benefit from the NALU B, and not only the NALU A which is at 15 Hz.
  • the fixed-path solution does not allow different applications to be used simultaneously because there is only a single dependency relationship between the NALUs from a hierarchical coder.
  • the multi-path solution is more open than the fixed path solution: it can be adapted to different applications / resolutions in the network or at the decoder.
  • the increase in complexity remains limited, but may not be suitable for adaptation to very low complexity as done on some network routers, for example.
  • the fixed-path solution does not adapt over time to different conditions on the side of the user, the network or the server: a customer can not choose at a moment to favor an axis (for example the fluidity temporal) rather than another (eg SNR quality) such as the choice imposed by the scheduling defined by the fixed adaptation path.
  • a customer can not choose at a moment to favor an axis (for example the fluidity temporal) rather than another (eg SNR quality) such as the choice imposed by the scheduling defined by the fixed adaptation path.
  • an object of the invention is to provide a fine scalable video representation technique (in layers) of data units, or packets, or NALtJs, from a scalable video coder in the spatial-temporal 3D-quality domain. which is more efficient than known techniques.
  • an objective of the invention is to make it possible to manage different paths in this 3D space according to the characteristics of the application, the network or customer needs
  • an object of the invention is to provide such a technique for performing adapted treatments of the same scalable video for different applications.
  • Another objective of the invention is to make it possible to define specific dependency modes that are dependent on or independent of the applications.
  • the purpose of the invention is also to make it possible to define specific or application-independent modes of specific ascent.
  • Another object of the invention is to allow variation over time and the operating points for the same video stream.
  • a filtering process of a scalable video stream "organized in blocks of data units each comprising a a basic data unit and a set of distributed enhancement data units according to at least two types of enhancement data, corresponding respectively to temporal and / or spatial and / or quality characteristics, and making it possible to define several levels of quality , depending on the number and type of uplift data units used.
  • this method comprises a step of defining at least two distinct profiles, or paths, for filtering the data units of each block, each path defining a series of successive fallback positions, starting from a position initial, each fallback position using at least one data unit less than the previous position, and a step of selecting one of said paths according to a predetermined criterion taking into account a content type of said flow and / or at least one piece of information representative of the capabilities of the terminal receiving said stream.
  • the invention makes it possible to adapt finely to a large number of contexts for which it is desirable to reduce or increase the quantity of information transmitted or received. For example, it may be necessary to adapt the data at the server level, at intermediate nodes, or translators, placed in a network, or at the terminal by selecting a profile by the user.
  • a first of said paths favors a characteristic representative of the quality of each image reconstructed by a terminal and a second of said paths favors a characteristic representative of the fluidity of the video
  • each of said raising data units carries at least two indicators for defining said paths, among the indicators belonging to the group comprising: a priority indicator (P);
  • said paths are stored in a path file, associating each of said paths with a predetermined application profile.
  • This file of paths can notably be a file in XML format.
  • said path file is transmitted in said video stream, in the form of at least one piece of information data.
  • the filtering method comprises the following steps: separating said enhancement data units, depending on the selected path, between data units to be used and data units being separated;
  • This last step can correspond to a storage, for example on a hard disk, making it possible to replay the video later with another level of quality, for example if the screen size is no longer the same. It can also be a storage in a buffer memory, for transmission of data units spread on another transmission channel.
  • discarded data units can also be directly deleted.
  • the method comprises the following steps: detection of at least one data unit to be used that is missing or deteriorated;
  • the method of the invention can be implemented at different levels of the transmission chain, and in particular by at least one of the following elements:
  • the invention also relates to a computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for the implementing at least one step of the filtering method described above.
  • it relates to a method of transmitting a scalable video stream by a video stream server to at least one receiving terminal, via a transmission network, said stream being organized in blocks of data.
  • data units each comprising a basic data unit and a set of enhancement data units distributed according to at least two types of enhancement data, corresponding respectively to temporal and / or spatial and / or quality characteristics, and to define multiple quality levels, depending on the number and type of lift data units used.
  • This method comprises a step of transmitting at least two distinct profiles or paths for filtering the data units of each block, each path defining a series of successive fold positions, starting from an initial position, each position of fallback using at least one data unit less than the previous position.
  • Said server and / or an intermediate node of said transmission network implements a step of selecting one of the two paths according to a predetermined criterion taking into account a content type of said flow and / or at least one information representative of the capabilities of the terminal (or multiple terminals) receiving said flow, and a step of transmitting the selected data units.
  • said server and / or said intermediate node implements said selection step as a function of selection information transmitted by said terminal. It can also take into account a summary of information emitted by a group of terminals.
  • the invention also relates to a computer program product for implementing at least one step of this method of transmitting a scalable video stream.
  • the invention relates to a method of receiving in a receiving terminal a scalable video stream transmitted by a video stream server, via a transmission network, said stream being organized in blocks.
  • data units each comprising a basic data unit and a set of enhancement data units distributed according to at least two types of enhancement data, corresponding respectively to temporal and / or spatial and / or quality characteristics, and allowing to define several levels of quality, according to the number and type of raising data units used.
  • this method uses at least two profiles, or fructa, distinct from filtering the data units of each block, each path defining a series of successive foldback positions, from an initial position, each fallback position using at least one least one unit of data less than the previous position, and said receiving terminal implements a step of selecting one of said paths according to a predetermined criterion taking into account a content type of said stream and / or d at least one piece of information representative of the capabilities of the terminal receiving said stream.
  • the notion of using at least two profiles may mean that the terminal has previously received from the server these different profiles and / or that it has calculated them. , for example on the fly.
  • the selection of a path can be automatic (controlled by the terminal) and / or at the initiative of the user.
  • the invention also relates to a computer program product for implementing at least one step of this method of receiving a scalable video stream.
  • the invention also relates to the video stream servers, the intermediate nodes of a transmission network and the video stream receiving terminals comprising means for implementing the methods described below.
  • the invention relates to a signal intended to be transmitted from a server to at least one terminal, to allow the processing of a scalable video stream transmitted by said video stream server, via a transmission network, said stream being organized as detailed previously.
  • a signal carries definition data of at least two profiles, or paths, distinct from filtering data units of each block, each path defining a series of successive fallback positions from an initial position, each fallback position using at least one data unit less than the previous position.
  • This signal thus makes it possible to select one of said paths as a function of a predetermined criterion taking into account a content type of said stream and / or at least one piece of information representative of the capacities of the terminal receiving said stream.
  • the signal carries on the one hand said data units forming said video stream, and on the other hand said definition data. Both elements can also be transmitted independently. 6 .. List of figures
  • FIG. 1 already commented on in the preamble, illustrates the structure of a scalable video stream, whose subflows are represented by cubes in a three-dimensional space formed of the three spatial, temporal and quality dimensions
  • Figure 2 also commented in the preamble, shows the schematic structure of an encoder of the flow of Figure 1
  • Figure 3 commented in the preamble, is an example of structuring a scalable flow in two dimensions, and three corresponding paths
  • FIG. 4A also commented on in the preamble, illustrates an example of three-dimensional scalability structuring
  • FIG. 4B shows an alternative distribution of priorities for a NAL, according to one aspect of the invention
  • Figure 5 is a simplified flowchart of the principle of the invention
  • FIG. 6 illustrates a filtering table presenting two paths according to the invention
  • Figure 7 shows the flow rates corresponding to the table of Figure 6
  • FIG. 8 is another example of a filtering table according to the invention, using the notion of priority indicator
  • FIGS. 9 to 11 illustrate three implementations of the invention, respectively in a client-server model, the adaptation of the bit rate in an intermediate node and the adaptation to a terminal
  • FIG. 12 illustrates the dependencies defined by a profile
  • FIG. 13 the reconstruction of the dependencies for the replica on the best quality possible in the event of the loss of a NALU
  • FIGS. 14, 15 and 16 respectively show simplified diagrams of the servers, the transmission node and the terminal according to the invention, 7. Description of a preferred embodiment of the invention 7.1 essential elements of the invention
  • the invention therefore proposes to use, according to the embodiment described hereinafter, the fields (P, D, T, Q) of NALUs SVC, in order to manage priority orders depending on the specified application needs and usable for making the adaptation of a server-side video stream (rate control, adaptation to the request), transmission nodes (DiffServ, TOS) or client side (adaptation in complexity, (7) -
  • a set of application profiles (or paths) is defined. These application profiles therefore define different orders of priority over fallback modes, based on criteria such as the type of video (sports or cinema for example), the type of terminal (processing capacity and memory, screen size) and / or network capabilities. For example, in the first case, two profiles can be defined: - - Sport profile; we favor temporal fluidity:
  • An application profile is then defined by a series of values (P, D, T, Q) i.
  • the set of application profiles can be stored in a file, for example an XML file (this file applies to a complete sequence or to segments of the sequence or to a set of sequences).
  • This file can be transmitted with the video stream, or in a separate channel. It must be available before the beginning of the decoding of the sequence / segment ).
  • Another embodiment is the transport of these meta-parameters in information NALUs (eg SEI-type NALUs).
  • NALUs eg SEI-type NALUs
  • Reading 51 of the application profiles file containing fallback modes and choices 52 a. an initial mode of operation (eg sport) (fallback and recovery paths); b. an initial operating point (for example high speed CIF @ 30 Hz);
  • an initial mode of operation eg sport
  • an initial operating point for example high speed CIF @ 30 Hz
  • This operating point can be updated externally (on a bit rate, quality, complexity, etc. basis) in accordance with a defined fallback strategy; 2. Reading 53 of the indices of the scalable video unit to be processed: Ht in the header of the NAL the information of resolution spatio-temporal-quality (P_paq, D_paq, T_paq, Q_paq) (one or more of dimensions can be omitted); 3, depending on the operating point (updated or not by the external process); at. Reading 55 of the operating mode (for example: sport) associated with an ascending and descending path making it possible to move in the scalability space; b. Choosing an operating point (reading or calculating F'_cible
  • Filtering 56 a. Flow reduction; deleting packets for which (P_paq, D_ ⁇ aq, T_paq, Q_Paq) do not conform to the target, according to the XML table; b. rejection 57 or use 58 of the packet (or NALU);
  • Modification 54 (possibly via an external process or otherwise) of the operating point; at. change of the operating mode (from a given priority to the fluidity of the images to a priority on the quality or the spatial resolution); b. change of the operating point (request of ascent or descent in quality of service).
  • the modification 54 takes into account a fallback mode flag 59 issued by a profile adapter 510 controlled as appropriate by the client terminal 511, the server 512 and the network 513.
  • the invention is based on the definition of a relationship between the fields P, D, T, Q of the header of the NALUs in order to organize the video stream at the output of the method in accordance with the expectations of a service particular, or a group of services. 7..2 NALUS signaling
  • the filtering table illustrated in FIG. 6 is established in accordance with the prior art. One can also calculate, optionally, a rate associated with each "box" significant table.
  • This table can be interpreted as a set of resolution intervals with overlapping flows (or not). This interpretation is illustrated in Figure 7. Within each range, the rate increases with Priority_id P ,.
  • a fallback mode corresponds to a descent (arrows 61 and 62) in the table of FIG. 6. For example, we define:
  • a film profile 62 according to which quality is preferred over fluidity and spatial resolution:
  • range On the example XML file above, we defined operating ranges (called “range”). These operating ranges correspond to a value triplet (DTQ) and a range of values of ⁇ riority_id ⁇ Pmin, Pmax). This priority_id range then makes it possible to offer a variation in quality / throughput for a given resolution. The availability of different ranges for different space-time resolutions then makes it possible to define fallback application profiles.
  • An application profile is then defined by a sequence of "range”.
  • the sport profile goes from a range of flow in CIF @ 30Hz then a range of flow for QCIF @ 30Hz and finally for QCIF @ 15Hz, thus privileging a temporal fluidity during the use of mode of downturn.
  • bit rate ranges proposed in an application mode can overlap (see FIG. 7). This thus allows a hysteresis phenomenon in the algorithm described hereinafter which then allows greater stability of the system by limiting the use of fallback modes. 7.4 _ Generic adaptation algorithm
  • an adaptation algorithm works as follows: 1- Reading application profiles. For example the xml file described above: a- selection of an application mode. For example sport profile ("application one"); b- selection of an initial operating point. Default choice of the maximum operating mode; Point having the maximum priority_id in the "range” 9.
  • the external process then varies the value of the priority_id in the current range (for example by using a feedback system, or by using a tabukt ⁇ on " ⁇ riority_id" gives flow).
  • This step conventional in itself, consists of;
  • the invention can take into account a large number of application constraints and can be carried out indifferently at any point of the network placed on the path between the encoder and the decoder, in a real-time or processing process. delayed.
  • FIG. 14 shows the simplified structure of a server according to the invention, which comprises a memory M 148, a processing unit 146, equipped for example with a microprocessor: and driven by the computer program Pg 147.
  • a server which comprises a memory M 148, a processing unit 146, equipped for example with a microprocessor: and driven by the computer program Pg 147.
  • the code instructions of the computer program 147 are for example loaded into a RAM memory before being executed by the processor of the processing unit 146.
  • the processing unit 146 receives as input a set of NALUs 141, the microprocessor ⁇ p of the processing unit 146 delivers a filtered video stream 143 according to the profile, or path, selected, according to the instructions of the Pg 147 program.
  • the server 91 proposes (911) to the client 92 a choice of application profiles, according to a request 921 of video stream.
  • the customer chooses (922) a mode and an operating point.
  • the server receives the operating mode and the operating point
  • Modes and operating points can be updated by an external adaptation process 93 receiving reports from the user (or network).
  • the profile adapter 93 uses the "RangeOrder" elements of the profiles XML file. 7.6.2 Background 2; server-network-client model (network adaptation)
  • FIG. 15 shows the simplified structure of an intermediate network node according to the invention, which comprises a memory M 154, a processing unit 151, equipped for example with a microprocessor, and driven by the computer program Pg 152
  • the code instructions of the computer program 152 are for example loaded into a RAM memory before being executed by the processor of the processing unit 151.
  • the processing unit 151 receives as input a video stream 151.
  • the microprocessor ⁇ P of the processing unit 151 filters the video stream 151, according to a selected profile, and delivers a filtered stream 153, according to the instructions of the program Pg
  • the server 101 sends a high-speed video stream 102 to the network intended for a group of receivers accepting a high-quality image and with a high bit rate. Unlike the previous example running point-to-point, this example works in multicast.
  • the intermediate node 103 receives the same stream 02 as the other receivers placed on the network. It has a target application profile internally 1031 for controlling the filtering algorithm 1032 to achieve the target flow rate of the stream 1033, 1034 by eliminating off-profile packets.
  • the client 104 receives this filtered video 1033,
  • the intermediate node can calculate new profiles directly by analysis of the fields ⁇ P, D, T, Q ⁇ , 7.6.3 Adaptation of the flow rate to the resources of the terminal
  • FIG. 16 shows the simplified structure of a terminal according to the invention, which comprises a memory M 160, a processing unit 161, equipped for example with a microprocessor, and driven by the computer program Pg 162.
  • a terminal which comprises a memory M 160, a processing unit 161, equipped for example with a microprocessor, and driven by the computer program Pg 162.
  • the code instructions of the computer program 162 are for example loaded into a RAM before being executed by the processor of the processing unit 161.
  • the processing unit 161 receives an input.
  • the microprocessor ⁇ P of the processing unit 161 filters the video stream 163, according to the profile selected, according to the instructions of the program.
  • the processing unit 161 outputs a filtered video stream 164.
  • FIG. 11 gives an example of the adaptation of the display to the resources of a terminal 111, for example a terminal with limited resources.
  • the transport of the video 112 contains all the information for all the terminals. Depending on the reduced capacity of the terminal, a. user can choose
  • HMI It also has an HMI that will allow it to navigate the levels of quality.
  • H can choose to increase or decrease the operating point.
  • the application profiles are inserted into the general parameters 1121 of the video, by SEl message, xml table, EPG or by any other means.
  • the filtering 11 13 is performed according to the selected profile, and the decoder 1114 reconstructs the corresponding images. 7.6.4 Best quality recovery in the event of loss of NAL in a receiver
  • the adaptation of the NALUs may vary in the quality ranges corresponding to a level, as indicated by Figure 12, the switching from one level to another can be done at the ends of the range.
  • NALUs 131, 132 and 133 were lost.
  • the analysis of PDTQ fields makes it possible to find the available information of better quality while waiting for the next image received without error.
  • Received NALUs 134 and 135 correspond to the missing lower levels that do not allow decoding. We then fall back on the NALU 136.
  • element ref "debits"/> ⁇ ! - to define the type of the application profile. eg "sport”, “movie”, ... -> ⁇ ! - to illustrate the type of fallback strategy used, eg "temporal”, "quality”, ... ->
  • ⁇ ! allows to define the rates associated with the different rates e.g. "100-300 400" to indicate that the first range varies between 100 and 300 kbits; and that the second range is at a rate of 400 kbit / s -> ⁇ / xs: sequence>
  • ⁇ ! - Range defines an operating flow range (defined by Pmin, Pmax) for a given spatio-temporal resolution (defined by S, T, O) ->
  • Root for file definition. Must contain a definition of flow ranges (3D Space), and a list of application profiles (MyApplications) -> ⁇ / xs: element> ⁇ ! - Definition of types of syntax elements used

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

L'invention concerne un procédé de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, comprenant une étape de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.

Description

Procédés de filtrage, de transmission et de réception de flux vidéo scalables, programmes, serveur, nœud intermédiaire et terminal correspondants. Xt domaine de l'Invention Le domaine de l'invention est celui du traitement de signaux vidéo, et plus particulièrement de séquences vidéo compressées sous forme échelonnable, ou scalable. Plus précisément, l'invention concerne l'amélioration de l'exploitation d'un flux scalable, notamment, mais non exclusivement, dans le cadre du schéma de codage actuellement développé dans MPEG4-SVC. Cette technique MPEG4-SVC est notamment présentée dans les documents :
- JSVM 2.0 : Joint Video Team (JVT) of ISO/IEC MPEG & ITU-T VCEG, N7084, Joint Scalable Video Model (JSVM) 2,0 Référence Encodlng Algorithm, Description, April 2005, Busan (Julien Reichel, Heiko Schwarz, Mathias Wien) ; et
- W D2 : J. Reichel, H. Schwarz M. Wien - Scalable Video Coding - Working Draft 2 -ISO/IEC JTC1/SC29/WG11, W70S4, April 2005, Busan.
3, art antérieur % 1 les systèmes vidéo scalables (échelonnables)
Actuellement, la plupart des codeurs vidéo génèrent un seul flux compressé correspondant à l'intégralité d'une séquence codée. Chaque client souhaitant exploiter Ie fichier compressé pour décodage et visualisation doit pour cela télécharger (ou « streamer ») le fichier compressé complet. Or, dans un système hétérogène (par exemple Internet), tous les clients ne disposent pas du même type d'accès aux données : la bande passante, les capacités de traitement, les écrans des différents clients peuvent etre très différents (par exemple, sur un réseau Internet, l'un des clients pourra disposer d'un débit ADSL à 1024 kb/s et d'un micro-ordinateur (PC) puissant alors que l'autre ne bénéficiera que d'un accès modem et d'un PDA). Une solution évidente à ce problème consiste à générer plusieurs flux compressés correspondant à différents débits/résolutions de la séquence vidéo : c'est le simulcast, Cette solution est cependant sous-optimale en termes d'efficacité, et suppose de connaître à l'avance les caractéristiques de tous les clients potentiels ;
Plus récemment sont apparus des algorithmes de codage vidéo dit scalables (ou échelonnables), c'est-à-dire à qualité adaptable et résolution spatio- temporelle variable, pour lesquels le codeur génère un flux compressé en plusieurs couches, chacune de ses couches étant emboîtée dans la couche de niveau supérieur. Ces algorithmes sont aujourd'hui en cours d'adoption en amendement de MPEG4-AVC (appelé dans la suite de ce document : SVC).
De tels codeurs sont très utiles pour toutes les applications pour lesquelles la génération d'un seul flux compressé, organisé en plusieurs couches de scalabilitÉ, peut servir à plusieurs clients de caractéristiques différentes, par exemple :
- service de vidéo à la demande, ou VOD (terminaux cibles : UMTS, PC ADSL, TV ADSL,..) ;
- mobilité de session (reprise sur un PDA d'une session vidéo commencée sur TV ; ou sur un mobile UMTS d'une session commencée sur GPRS) ;
- continuité de session (partage de la bande passante avec une nouvelle application) ;
- TV haute définition (encodage unique pour servir des clients SD - "Standard Définition" et HD - "High Définition") ; - visioconférence (encodage unique pour des clients UMTS/Internet) ;
2.1.1 Granularité de la scabilité
Un flux vidéo scalable peut être considéré comme un ensemble de sous- flux représentés par des cubes 11 dans un espace tridimensionnel formé des trois dimensions spatiale 12, temporelle 13, et qualité, oυ SNR, 14 (S,T,Q), comme illustré schématiquement par la figure 1.
La taille des incréments dans les différentes directions correspond à Ia "granularité" de la scabilité : elle peut etre fine, moyenne (10% de débit par incrément de scalabilité : MGS) ou grossière (25% de débit par incrément ; CGS). Dans la suite, on considérera que la scalabilité CGS correspond à un système « en couches » (« layers » dans le document MPEG2005/M 12043, Avril 2005. "ISO/MP4 File Format for Storage of Scalabie Video",Thomas Rathgen, Peter Amon et Andréas Hutter) et la scalabilité MGS à un système « par niveaux » (« levels » dans ce même document). 2.1.2 Mode de scalabilité fine (MGS)
Un train binaire scalable peut être organisé pour supporter une scalabilité fine. On parlera par la suite de scalabilité MGS (« Médium Grain Scalability ») conformément à la règle adoptée dans MPEG. À partir du train binaire, n'importe quel sous-flux cohérent peut etre extrait (y compris le niveau de base) et décodé avec la qualité correspondante, c'est-à-dire n'importe quelle combinaison des résolutions supportées (temporelle, spatiale ou SNR) peut Être extraite. Les trains binaires MGS permettent k flexibilité Ia plus élevée. 2 J ,3 Mode d'organisation en couches (« Layered Scalability Mode »)
Alternativement un train binaire peut être organisé en couches. On parlera alors de flux CGS (« Coarse Grain Scalability »). Une couche contient tous les niveaux de scalabilité nécessaires pour passer à la couche de qualité supérieure.
Une couche doit augmenter la qualité dans au moins une direction (temporelle, spatiale ou SNR).
Une représentation CGS permet des opérations simples d'adaptation, notamment au niveau des nœuds du réseau. Les évolutions des informations dans l'espace qualité-résolution spatiale-résolution temporelle sont définis a priori selon les conditions imposées par une application ou par un utilisateur du service. 2.2 MPBG-4 SVC
Le JSVM MPEG est décrit dans Ic document JSVM 2.0 déjà cité. Le modèle qui a été retenu est basé sui un codeur scalable fortement orienté vers des solutions de type AVC, dont Ia structure schématique d'un encodeur correspondant est présenté à la figure 2. Il s'agit d'une structure pyramidale. Les composantes d'entrée vidéo 20 subissent un sous-échantillonnage dyadique (décimatioπ 2D par 2 référencée 21, décimation 2D par 4 référencée 22). Chacun - -des flux sous-échantillonnés subit ensuite une décomposition temporelle 23 de type MCTF ("Motion Compensated Temporal Filtering" pour "filtrage temporel compensé en mouvement"). Une version basse résolution de la séquence vidéo est codée 14 jusqu'à un débit donné R_rO_max qui correspond au débit maximum décodable pour Ia résolution spatiale basse rθ (ce niveau de base est compatible AVC).
Les niveaux supérieurs sont ensuite codés 25, 26 par soustraction du niveau précédent reconstruit et sur-échantillonné et codage des résidus sous forme : d'un niveau de base ; - éventuellement d'un ou plusieurs niveaux de rehaussement obtenus par codage multipasse de plans de bits (appelé par la suite FGS pour "Fine Grain Scalability", échelonnabilité à grain fin). Le résidu de prédiction est codé jusqu'à un débit R_rLmax qui correspond au débit maximum décodable pour la résolution ri. Plus précisément, les blocs de filtrage MCTF 23 réalisent un filtrage en ondelettes temporel, c'est-à-dire qu'ils réalignent les signaux dans le sens du mouvement avant filtrage en ondelettes : ils délivrent des informations de mouvement 27 qui alimentent un bloc de codage de mouvement 24-26, et des informations de texture 28, qui alimentent un module de prédiction 29. Les données prédites, en sortie du module de prédiction 29 servent à réaliser une interpolation 210 depuis le niveau inférieur. Elles alimentent également un bloc 211 de transformation spatiale et de codage entropique, qui travaille sur des niveaux de raffinement du signal. Un module de multiplexage 212 ordonne les différents sous-flux générés dans un flux de données compressé global. Cette nouvelle approche est capable de fournir des flux scalables à grain moyen dans les dimensions temporelles, spatiale, et en qualité.
Les caractéristiques principales de cette technique sont les suivantes :
- solution pyramidale avec sous-échantillonnage dyadique des composantes d'entrée ; - - décomposition temporelle de type MCTF ("Motion Compensated Temporal Filtering" ou filtrage temporel de compensation de mouvement) à chaque niveau ;
- codage du niveau de base (compatible AVC) ;
- codage des niveaux supérieurs par soustraction du niveau précédent reconstruit et codage des résidus sous forme ;
- d'un niveau de base ; et
* d'un ou plusieurs niveaux de réhaussement obtenus par codage multipasse de plans de bits (par la suite : FGS),
Afin de réaliser une adaptation en débit, les informations de texture sont codées à l'aide d'un schéma progressif à chaque niveau :
- codage d'un premier niveau de qualité minimale (appelé « Base Layer » - Couche de Base) ;
- codage de niveaux de raffinement progressif (appelés "Enhancement Layer" - Couche de Rehaussement). 2,3 Architecture du, codeur SVC
L'encodeur SVC est basé sur un système en deux couches, comme AVC :
- La couche VCL ( "Video Coding Layer") gère l'encodage de Ia vidéo ;
- La couche NAL ("Network Abstraction Layer") assure une interface entre la couche VCL et l'extérieur. En particulier, ce niveau organise en AUs ("access units" ou "blocs d'unités de données") les différentes
NALU ("NAL Units" ou "unités de données") qui lui sont fournies par la couche VCL.
- Une NALU est une unité élémentaire contenant le niveau de base d'une Image spatio-temporelle, contenant tout (dans la version courante) ou partie (en cours de discussion pour les versions futures) d'un niveau FGS d'une image spatio-temporelle ; - Une AU est l'ensemble des NALUs correspondant à un instant temporel.
24 Signalisation des modes de scalabilité dans la couche NAL SVC - - Afin de pouvoir décoder convenablement une NAL SVC, il faut pouvoir signaler son positionnement dans l'espace (S,T,Q) illustré par la figure 1.
Deux modes de signalisation (correspondant sensiblement aux modes CGS et MGS) sont actuellement en cours de discussion dans le JSVM : un mode de signalisation par chemin fixe, et un mode de signalisation par chemin variable. Un exemple simple est donné par la figure 3, pour un contexte à deux dimensions 2D (T, Q) : un flux vidéo scalable contient les représentation.. emboîtées de sous-flux en CIF, de résolutions temporelles 15 Hz (31) et 30 Hz (32). Le flux est constitué de quatre NALUs A(O), B (2), C(I) et D(2). En utilisant ces quatre NALUs on peut obtenir les points de débit-distorsion a, b, c, d. La priorité des NALUs est indiquée entre parenthèses.
Sur cet exemple, on voit qu'il y a plusieurs "chemins" 33, 34 et 35, de décodage possible entre les points a et d : (a,b,c,d) mais aussi (a,b,d) ou (a,c,d).
On comprend que certaines applications pourront privilégier un chemin par rapport à l'autre, Par exemple, il peut être judicieux d'utiliser le chemin (a,c,d) pour obtenir une vidéo fluide en 30 Hz, mais plutôt (a,b,d) si l'on souhaite privilégier la qualité en 15 Hz.
Ce chemin est donc dépendant de l'application et du mode de codage utilisé. 2,5.1 Chemin fixe
Ce mode signale un chemin unique dans l'espace 3D pour l'extraction du ftux scalable. Il est bien adapté au mode CGS pour certaines applications. Dans l'exemple de la figure 3, un chemin fixe va être choisi, par exemple (a,c,d).
Ce chemin sera toujours utilisé, que l'on décode en 30 ou en 15 Hz. L'inconvénient majeur qui apparaît alors est que Ie point b ne sera pas décodé, même en 15 Hz, alors qu'il pourrait être plus intéressant de le décoder pour avoir une meilleure qualité en 15Hz.
Dans ce contexte, un indicateur unique permet de coder ce chemin fixe. 2.5,2 chemin variable
_ 5 Ce mode propose de laisser à 1,'application (ou au réseau) le choix du chemin d'extraction. Pour ce faire, on introduit un élément supplémentaire, que l'on appelle l'indicateur de priorité, et qui va permettre de résoudre le problème évoqué plus haut lorsqu'on décode en 30 Hz.
Les deux tableaux suivants montrent respectivement les priorités affectées
10 aux NALUs A, B, C et D dans l'exemple ci-dessus et le résultat du filtrage en 15 Hz et en 30 Hz selon la priorité choisie au décodage (sont décodées/conservées les NALUs qui apparaissent dans le tableau). On notera qu'il est possible en 30 Hz de définir plusieurs chemins différents en fonction de l'indice de priorité affecté aux quatre NALUs.
15
Les règles de filtrage utilisées ici sont les suivantes : Pour une résolution temporelle T cible (30 ou 15 Hz) garder toutes les
20 NALs dont la résolution temporelle est inférieure ou égale à la résolution demandée (T_NAL <= T-CiWe) et la priorité est inférieure ou égale à la priorité demandée (pri,oritéJSTAL<= prioπté_cible). Le procédé est généralisante à plus de deux dimensions .* dans Vexemple illustré par Ia figure 4A, il y a trois dimensions de scalabilité :
25 D = Spatial : QCIF/CIF (la dépendance D est un sur-ensemble de la résolution spatiale S) ;
T = Temporel : 15 Hz/30 Hz ;
Q = Qualité/complexité faible/forte (« low/high »)- Un exemple d'association de priorités aux différentes NALUs est précisé sur la figure, et un exemple de filtrage associé est montré dans le tableau ci- dessous.
Dans ce contexte, un indicateur double est nécessaire : le "priority fiels" contient l'indicateur de priorité et le "decolability info" contient les informations de résolution spatiale, temporelle et en qualité. Ces deux indicateurs nécessitent une représentation sur deux octets. Ainsi, dans toute la suite du document, une NAL sera repérée par ses quatre indices (P,D,T,Q) accessibles par exemple dans l'en-tête de fichier où : P indique la priorité ;
D indique la dépendance (sur-ensemble de la résolution spatiale
S) ;
T indique la résolution temporelle ; Q indique la qualité, ou la complexité. On notera que les cellules en gras du tableau ci-dessus présentent des anomalies par rapport à la résolution spatio-temporelle demandée : en QCIF 30 Hz, il serait souhaitable de béneficier de la NALU B, et non uniquement de la NALU A qui est à 15 Hz.
L'invention a entre autres comme objectif de pallier ce problème. 3 Inconvénients de la technique antérieure
La solution à chemin fixe ne permet pas de servir simultanément des applications différentes, car il n'existe qu'une relation unique de dépendance entre les NALUs issus d'un codeur hiérarchique.
La solution à chemins multiples est plus ouverte que la solution à chemins fixes : elle permet de s'adapter à des applications/résolutions différentes, dans le réseau, ou au niveau du décodeur. L'augmentation de complexité reste limitée, mais peut n'être pas adaptée pour une adaptation à très faible complexité comme fait sur certains routeurs de réseaux par exemple.
La solution à chemin fixe ne permet pas de s'adapter au cours du temps à des conditions différentes du côté de l'utilisateur, du réseau ou du serveur : un client ne pourra choisir à un instant de favoriser un axe (par exemple la fluidité temporelle) plutôt qu'un autre (par exemple la qualité SNR) tel que le choix imposé par l'ordonnancement défini par le chemin fixe d'adaptation.
Aucune des deux solutions (fixe ou variable) ne permet de gérer un mode de repli qui permettrait à un utilisateur de réduire la qualité ou Ia résolution des données reçues selon ses propres préférences.
4 Objectifs de l'invention
L'invention a notamment pour objectif de pallier ces inconvénients de l'état de la technique. Plus précisément, un objectif de l'invention est de fournir une technique de représentation vidéo scalable fine (en couches) des unités de données, ou paquets, ou NALtJs, issus d'un codeur vidéo scalable dans le domaine 3D spatial-temporel- qualité, qui soit plus efficaces que les techniques connues.
Ainsi, un objectif de l'invention est de permettre de gérer des chemins différents dans cet espace 3D en fonction des caractéristiques de l'application, du réseau ou des besoins du client
En d'autres termes, un objectif de l'invention est de fournir une telle technique permettant de réaliser des traitements adaptés d'une même vidéo scalabte pour des applications différentes. Un autre objectif de l'invention est de permettre de définir des modes de repli spécifiques dépendants ou indépendants des applications.
L'invention a également pour objectif de permettre de définir des modes de remontée spécifiques dépendants ou indépendants des applications.
Un autre objectif de l'invention est de permettre de varier au cours du temps modes et les points de fonctionnement pour un même flux vidéo.
5._ Résumé de l'invention
Ces objectifs, ainsi que d'autres qui apparaîtront plus clairement par la suite, sont atteints selon l'invention à l'aide d'un procédé de filtrage d'un flux vidéo scalable» organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement â des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et îe type d'unités de données de réhaussement utilisées. Selon l'invention, ce procédé comprend une étape de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
Ainsi, l'invention permet de s'adapter finement à un grand nombre de contextes pour lesquels il est souhaitable de réduire ou augmenter la quantité d'informations transmises ou reçues. II peut par exemple s'agir d'adapter les données au niveau du serveur, au niveau de nœuds intermédiaires, ou translateurs, placés dans un réseau, ou au niveau du terminal par sélection d'un profil par l'usager.
De façon avantageuse, un premier desdits chemins privilégie une caractéristique représentative de la -qualité de chaque image reconstruite par tin terminal et un deuxième desdits chemins privilégie une caractéristique représentative de la fluidité de la vidéo,
H est ainsi possible de privilégier, selon le contenu, la qualité de l'image» par exemple pour un film, ou la fluidité des mouvements, par exemple pour du sport. De nombreux autres chemins (également appelés profils) et variantes peuvent bien sûr être définis,
Préférentiellement, chacune desdites unités de données de réhaussement porte au moins deux indicateurs permettant de définir lesdits chemins, parmi les indicateurs appartenant au groupe comprenant : - un indicateur de priorité (P) ;
- un indicateur de dépendance, relatif à la résolution spatiale (D) ;
- un indicateur de résolution temporelle (T) ;
- un indicateur de qualité et/ou de complexité (Q).
Selon un mode de réalisation avantageux de l'invention, lesdits chemins sont stockés dans un fichier de chemins, associant chacun desdits chemins à un profil applicatif prédéterminé. Ce fichier de chemins peut notamment Être un fichier au format XML.
Il peut par exemple être stocké et/ou calculé à la volée par les terminaux. Dans un mode de réalisation préférentiel, ledit fichier de chemins est transmis dans ledit flux vidéo, sous la forme d'au moins une unité de données d'information.
De façon avantageuse, Ie procédé de filtrage comprend les étapes suivantes : - séparation desdites unités de données de rehaussement, en fonction du chemin sélectionné, entre des unités de données à utiliser et des unités de données ecartées ;
- reconstruction d'images vidéo à l'aide desdites unités de données à utiliser ;
- mémorisation desdites unités de données écartées.
Cette dernière étape peut correspondre à un stockage, par exemple sur un disque dur, permettant de rejouer plus tard la vidéo avec un autre niveau de qualité, par exemple si la taille d'écran n'est plus la meme. II peut également s'agir d'une mémorisation dans une mémoire tampon, en vue d'une transmission des unités de données écartées sur un autre canal de transmission.
Bien sûr, les unités de données écartées peuvent également être directement supprimées.
Avantageusement, le procédé comprend les étapes suivantes : - détection d'au moins une unité de données à utiliser manquante ou détériorée ;
- reconstruction d'une vidéo à partir d'unités de données correspondant à une des positions de repli du chemin sélectionné.
Ainsi, en cas de perte d'un paquet, on ne perd pas la restitution de la vidéo, mais on passe simplement à une qualité inférieure.
Le procédé de l'invention peut Être mis en œuvre à différents niveaux de la chaîne de transmission, et notamment par au moins un desdits éléments suivants :
- serveur de flux vidéo ;
- nœud intermédiaire d'un réseau de transmission ; - terminal récepteur d'un flux vidéo.
L'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en œuvre d'au moins une étape du procédé de filtrage décrit ci-dessus. Selon un autre aspect de l'invention, celle-ci concerne un procédé de transmission d'un flux vidéo scalable par un serveur de flux vidéo vers au moins un terminal récepteur, via un réseau de transmission, ledit flux, étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées. Ce procédé comprend une étape de transmission d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente. Ledit serveur et/ou un nœud intermédiaire dudit réseau de transmission met en oeuvre une étape de sélection de l'un desdïts chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal (ou de plusieurs terminaux) recevant ledit flux, et une étape de transmission des unités de données sélectionnées.
De façon avantageuse, ledit serveur et/ou ledit nœud intermédiaire met en œuvre ladite étape de sélection en fonction d'une information de sélection émise par ledit terminal. Elle peut également tenir compte d'une synthèse des informations émises par un groupe de terminaux. L'invention concerne également un produit programme d'ordinateur pour la mise en œuvre d'au moins une étape de ce procédé de transmission d'un flux vidéo scalable.
Selon encore un autre aspect, l'invention concerne un procédé de réception dans un terminal récepteur d'un flux vidéo scalable transmis par un serveur de flux vidéo, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de-qualité, selon le nombre et Ie type d'unités de données de réhaussement utilisées.
Selon ce procédé, oit utilise au moins deux profils, ou chemina, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et ledit terminal récepteur met en œuvre une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux, La notion d'utilisation d'au moins deux profils peut signifier que le terminal a préalablement reçu, du serveur, ces différents profils, et/ou qu'il les a calculé, par exemple à la volée. La sélection d'un chemin peut être automatique (pilotée par le terminal) et/qu à l'initiative de l'utilisateur.
L'invention concerne également un produit programme d'ordinateur pour la mise en œuvre d'au moins une étape de ce procédé de réception d'un flux vidéo scalable.
L'invention concerne également les serveurs de flux vidéo, les nœuds intermédiaires d'un réseau de transmission et les terminaux récepteurs de flux vidéo comprenant des moyens pour mettre en œuvre les procédés décrits ci- dessous.
Enfin, l'invention concerne un signal destiné à être transmis depuis un serveur vers au moins un terminal, pour permettre Ie traitement d'un flux vidéo scalable transmis par ledit serveur de flux vidéo, via un réseau de transmission, ledit flux étant organisé comme détaillé précédemment. Un tel signal porte des données de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente.
Ce signal permet ainsi une sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terninal recevant ledit flux.
Selon un mode de réalisation avantageux, le signal porte d'une part lesdites unités de données formant ledit flux vidéo, et d'autre part lesdites données de définition. Les deux éléments peuvent également être transmis de façons indépendantes. 6.. Liste des figures
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donnée à titre de simple exemple illustratif et non limitatif, et des dessins annexés parmi lesquels : la figure 1 , déjà commentée en préambule, illustre la structure d'un flux vidéo scalable, dont les sous-flux sont représentés par des cubes dans un espace tridimensionnel formé des trois dimensions spatiale, temporelle, et qualité ; la figure 2, également commentée en préambule, présente la structure schématique d'un encodeur du flux de la figure 1 ; la figure 3, commentée en préambule, est un exemple de structuration d'un flux scalable en deux dimensions, et de trois chemins correspondants ; - la figure 4A, également commentée en préambule, illustre un exemple de structuration à trois dimensions de scalabilité, et la figure 4B présente une une variante de répartition des priorités pour une NAL, selon un aspect de l'invention ; la figure 5 est un organigramme simplifié du principe de l'invention ; - la figure 6 illustre un tableau de filtrage présentant deux chemins selon l'invention ; la figure 7 présente les plages de débit correspondant au tableau de la figure 6 ; la figure 8 est un autre exemple de tableau de filtrage selon l'invention, utilisant la notion d'indicateur de priorité ; les figures 9 à 11 illustrent trois mises en oeuvre de l'invention, respectivement dans un modèle client-serveur, l'adaptation du débit dans un noeud intermédiaire et l'adaptation à un terminal; la figure 12 illustre les dépendances définies par un profil, et la figure 13 la reconstruction des dépendances pour le répli sur la meilleure qualité possible en cas de perte d'une NALU ; les figures 14, 15 et 16 présentent respectivement des schémas simplifiés des serveur, nceud de transmission et terminal selon l'invention, 7. Description d'un mode de réalisation préférentiel de l'invention 7.1 éléments essentiels de l'invention
L'invention propose donc d'utiliser, selon le mode de réalisation décrit par la suite, les champs (P,D,T,Q) de NALUs SVC, afin de gérer des ordres de priorité dépendant des besoins applicatifs spécifiés et utilisable pour faire de l'adaptation d'un flux vidéo coté serveur (régulation de débit, adaptation à la demande), nœuds de transmission (DiffServ, TOS) ou côté client (adaptation en complexité, ...)-
On se place dans le contexte du filtrage générique connu, décrit précédemment. Chaque NAL est donc définie par le quadruple! (P,D,T,Q).
Le filtrage s'effectue selon N des 4 dimensions (N<=4). On dispose de modes de repli, c'est-à-dire de mécanismes permettant de privilégier un chemin dans l'espace (D,T,Q) lorsque les résolutions cibles ne peuvent être atteintes (pour des raisons de diminution de débit, de complexité, de choix de l'utilisateur...).
Selon l'invention, un ensemble de profils applicatifs (ou chemins) est défini. Ces profils applicatifs définissent donc des ordres différents de priorité sur les modes de repli, en fonction de critères tels que le type de vidéo (sport ou cinéma par exemple), le type de terminal (capacité de traitement et de mémoire, taille de l'écran) et/ou les capacités du réseau. Par exemple, dans le premier cas, on peut définir deux profils : - - Profil sport ; on privilégie la fluidité temporelle :
SD@30Hz high ≈> SD@30Rz low => CIF@30Hz high => CIF@15Hz high
Profil film : on privilégie la qualité à la fluidité et résolution spatiale : SD@30Hz high => SD@15Hz high ≈> SD@7.5Hz high =>
CIF@7.5Eïz high.
Un profil applicatif est alors défini par une suite de valeurs (P,D,T,Q)i. L'ensemble des profils applicatifs peut être stocké dans un fichier, par exemple un fichier XML (ce fichier s'appliquant à une séquence complète ou bien à des segments de la séquence ou encore à un ensemble de séquences). Ce fichier peut être transmis avec le flux vidéo, ou dans un canal séparé. Il doit être disponible avant le début du décodage de la séquence/segment...). Un autre mode de réalisation est le transport ces méta-paramètres dans des NALUs d'information (par exempte NALUs de type SEI), Le déroulement du procédé de filtrage, illustré par l'organigramme de Ia figure 5, est le suivant ;
1. Lecture 51 du fichier des profils applicatifs contenant les modes de repli et choix 52 : a. d'un mode de fonctionnement initial (par exemple sport) (chemins de repli et de remontée) ; b. d'un point de fonctionnement initial (par exemple haut débit CIF@30 Hz) ;
Ce point de fonctionnement peut être remis à jour de façon externe (sur une base d'adaptation en débit, en qualité, en complexité,..) conformément à une stratégie de repli définie ; 2. Lecture 53 des indices de l'unité de vidéo scalable à traiter : on Ht dans l'en-tête de la NAL les informations de résolution spatio-temporelles- qualité (P_paq, D__paq, T_paq, Q_paq) (une ou plusieurs des dimensions peuvent etre omises) ; 3, En fonction du point de fonctionnement (remis à jour ou non par le processus externe) ; a. Lecture 55 du mode de fonctionnement (par exemple : sport) associé à un chemin ascendant et descendant permettant de se déplacer dans l'espace de scalabilité ; b. Choix d'un point de fonctionnement (lecture ou calcul de F'_cible
D'_cibIe, T'_cit>le, Q'_cîble) ;
4. Filtrage 56 : a. Réduction du débit ; suppression des paquets pour lesquels (P_paq, D_ρaq, T_paq, Q_Paq) ne sont pas conformes à la cible, conformément à la table XML ; b. rejet 57 ou utilisation 58 du paquet (ou NALU) ;
5. Modification 54 (éventuelle via un processus externe ou autre) du point de fonctionnement ; a. changement du mode de fonctionnement (passer d'une priorité donnée à la fluidité des images à une priorité sur la qualité ou la résolution spatiale) ; b. changement du point de fonctionnement (demande de remontée ou de descente en qualité de service).
La modification 54 tient compte d'un indicateur 59 de mode de repli délivré par un adaptateur de profil 510 contrôlé selon les cas par le terminal client 511 , le serveur 512 et Ie réseau 513.
Chacune de ces étapes est détaillée par la suite.
L'invention s'appuie sur la définition d'une relation entre les champs P, D, T, Q de l'en-tête des NALUs en vue d'organiser le flux vidéo en sortie du procédé conformément aux attentes d'un service particulier, ou d'un groupe de services. 7..2 Signalisation des NALUSs
On propose, selon un mode de réalisation avantageux, d'améliorer la numérotation proposée dans l'art antérieur en déclarant que chaque niveau de base est de priority_id 0 Cette approche est illustrée par la figure 4B, Elle permet efficacement de faire disparaitre les points en anomalie entre les résolutions spatio-temporelles demandées et délivrées (case en gras du tableau de l'art antérieur). 7.3 Etablissement du tableau de filtrage
Le tableau de filtrage illustré en figure 6 est établi conformément à l'art antérieur. On peut aussi calculer, de manière optionnelle, un débit associé à chaque "case" significative du tableau.
On peut interpréter ce tableau comme un ensemble d'intervalles de résolutions avec des débits recouvrants (ou non). Cette interprétation est illustré par la figure 7. A l'intérieur de chaque intervalle, le débit augmente avec le Priority_id P,.
Sur le tableau de la figure 6, on peut noter que chaque série est monotone dans le tableau, alors que la courbe 61 ne l'est pas. Cela est un avantage de la solution de l'invention.
Un mode de repli correspond à une descente (flèches 61 et 62) dans le tableau de la figure 6. Par exemple, on définit :
- un profil sport 61, selon lequel on privilégie la fluidité temporelle CIF@30Hz high -> CIF@30Hz low => QCIF@30Hz high => QCDF®30HzLow > QCJF@15Hz high ;
- un profil film 62, selon lequel on privilégie la qualité à la fluidité et résolution spatiale :
CIF @30Hz high -> CIF @ 15Hz high =>QCtF @ 15Hz high =>QCIF @7.5Hz high.
La meme approche peut etre définie par évolution de plages de débit, comme illustré par la figure 8 : - profil sport 81 : SD@30Hz (high to low) => CIP@30Hz (hîgh to low) => QCIF@30Hz (hightolow) ... - profil film 82...
Afin de définir ces modes de repli en fonction des applications, on peut imaginer par exemple un fichier XML des profils applicatifs du type suivant-:-
<?xml veersion="1.0"? >
<Root xmls: xsi="http : //www. w3.org/2001 /XMLSchema ~instance" xsi: noNamespaceSchemalocation ="C: \Mes Documents\Brevets\DIH\Transport SVC\XML\Repli. xsd"> <Espace3D>
<!-- Définion de plages de fonctionnement pour des résolutions types ->
<Range id="1" S="QCIF" T="15Hz " Q="low" PMin="0" PMax="0"/> < ! --cette première plage correspond a du QCIF 15hz avec PMin=PMax, i.e. un seul point" -->
<Range id="2" S="QCIF" T="15Hz"" Q="high" PMin="0" PMax= "1"/>
<! --cette première plage correspond à du QCIF 15hz avec PMin<PMax, plusieurs points"-->
<Range id="3" S="QCIF" T="30Hz" Q="low" PMin="0" PMax="0" />
<Range id="4" S="QCIF" T="30Hz" Q="high" PMin="0" PMax="3" /> <Range id="5" S="CIF" T="15Hz" Q="low" PMin="0"
<Range id="6" S="CIF" T=" 15 Hz" Q="high" PMin ="1"
<Range id="7" S="CIF" T= "30Hz" Q= "low" PMin="0" PMax="0"/> <Range id="8" S="CIF" T="30Hz" Q="high" PMin="0" PMax="3"/>
<Range id="9" S="CIF" T="30Hz" Q="high" PMin ="2" PMax="3"/> <Espace 3D>
<Mesapplications >
<Application name="application une"> <!-- application numero un — > <tγpe> sport </type> <! --application de type sport" -->
<path_preference> temporel </path_preference> <RangeOrder > "8 4 2"</RangeOrder> <!-- Ce chemin indique une preference de fluidite temporelle - -> <debits>"150 150-300 450 450-900"</debits >
</Application>
<Application name=" application deux"> <!-- application numero deux--> <type>film<type > <! --application de type film"— >
<path_preference > qualité</path_preference > <RangeOrder> "9 6 2"</RangeOrder > <! — ce chemin indique une preference de qualite par rapport aux autres axes --> <debits> "100-200 400-600 800-900"</debits>
<Application> <Application name="application trois">
<!-- mon application numero trois - -> <type>mobile</type> <path_preference > resolution</path _preference > <RangeOrder>"9 6 5"</RangeOrder> <debits/> </Application> </Mesapplications> <Roct >
On présente en annexe un schéma complet permettant de valider cet exemple.
Tout autre moyen de description des profils applicatifs est possible, tel qu'un tableau dans un langage de programmation, ou une insertion dans le flux vidéo (SEI à définir).
Sur l'exemple de fichier XML ci-dessus, on a défini des plages de fonctionnement (dénommées « range »). Ces plages de fonctionnement correspondent à un triplet de valeur (DTQ) et une plage de valeurs de ρriority_id {Pmin, Pmax). Cette plage de priority_id permet alors d'offrir une variation en qualité/débit pour une résolution donnée. La disponibilité de différentes plages pour différentes résolutions spatio-temporelles permet alors de définir des profils applicatifs de repli.
Un profil applicatif est alors défini par une suite de « range ». Ainsi sur cet exemple, le profil sport passe d'une plage de débit en CIF@30Hz puis une plage de débit pour du QCIF@30Hz et enfin pour du QCIF@15Hz, privilégiant ainsi une fluidité temporelle lors de l'utilisation de mode de repli.
Il est à noter que les plages de débits proposées dans un mode applicatif peuvent se chevaucher (voir figure 7), Ceci autorise ainsi un phénomène d'hystérésis dans l'algorithme décrit par la suite qui permet alors une plus grande stabilité du système en limitant l'utilisation des modes de repli. 7,4 _ Algorithme générique d'adaptation
En reprenant l'exemple de profils applicatifs tels que décrit ci-dessus, un algorithme d'adaptation fonctionne de la manière suivante: 1- Lecture des profils applicatif. Par exemple le fichier xml décrit ci-dessus : a- sélection d'un mode applicatif. Par exemple profil sport ("application une") ; b- sélection d'un point de fonctionnement initial. Par défaut choix du mode de fonctionnement maximal; Point ayant le priority_id maximum dans le « range » 9. Soit p_cible=3, D_cible≈CIP, T_cible=30H2, Q_cible=High ; 2- Lors d'une adaptation nécessaire, le processus externe fait alors varier la valeur du priority_id dans le range courant (par exemple en utilisant un système de rétroaction, ou bien en utilisant une tabuktïon « ρriority_id » donne débit). Si Ia contrainte n'est pas satisfaite, on peut alors décider d'opérer un repli (sélection du range inférieur) ou de remontée (sélection du range supérieur). La recherche du « range » adéquat et du « priority_id » peut être poursuivi jusqu'à obtention de la contrainte. 7,5 Filtrage
Cette étape, classique en soi, consiste à ;
• Rejeter (ou traiter de façon adéquate - par exemple par routage haut débit) tous les paquets pour lesquels (P_paq > P_courant) et/ou
(S_paq > S_courant) et/ou (T_ρaq > T_couxant) et/ou (Q'_paq > Q_courant),
• Traiter les autres paquets (transmission, stockage, ...). 7.6. Exemple d'applications de l'invention L'invention peut prendre en compte un grand nombre de contraintes applicatives et peut se réaliser indifféremment en tout point du réseau placé sur le chemin entre le codeur et le décodeur, dans un processus temps réel ou de traitement en différé.
Le tableau ci-dessous décrit plusieurs exemples d'actions types et leurs localisations possibles dans le réseau:
7.6.1 Contexte 1 : modèle client-serveur (adaptation aux ressources et aux choix de l'utilisateur)
La Figure 14 présente la structure simplifiée d'un serveur selon l'invention, qui comprend une mémoire M 148, une unité de traitement 146, équipée par exemple d'un microprocesseur:, et pilotée par le programme d'ordinateur Pg 147. A l'initialisation, les instructions de code du programme d'ordinateur 147 sont par exemple chargées dans une mémoire RAM avant d'etre exécutées par le processeur de l'unité de traitement 146. L'unité de traitement 146 reçoit en entrée un ensemble de NALUs 141, Le microprocesseur μp de l'unité de traitement 146 délivre un flux vidéo filtré 143 en fonction du profil, ou chemin, sélectionné, selon les instructions du programme Pg 147.
Cette mise en œuvre est illustrée par la figure 9. Le serveur 91 propose (911) au client 92 un choix de profils applicatifs, en fonction d'une demande 921 de flux vidéo. Le client choisit (922) un mode et un point de fonctionnement.
Le serveur reçoit le mode de fonctionnement et le point de fonctionnement
912 du client, en fonction de quoi il filtre (913) les éléments 914 du codage vidéo.
Seuls les paquets conservés, formant la vidéo filtrée 915, sont transmis au client.
Les modes et points de fonctionnement peuvent etre remis à jour par un processus d'adaptation externe 93 recevant des rapports de l'usager (ou du réseau).
L'adaptateur de profils 93 utilise les éléments "RangeOrder" du fichier XML de profils. 7.6.2 Contexte 2 ; modèle serveur-réseau- client (adaptation au réseau)
La figure 15 présente la structure simplifiée d'un nœud intermédiaire de réseau selon l'invention, qui comprend une mémoire M 154, une unité de traitement 151, équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur Pg 152. A l'initialisation, les instructions de code du programme d'ordinateur 152 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 151. L'unité de traitement 151 reçoit en entrée un flux vidéo 151. Le microprocesseur μP de l'unité de traitement 151 filtre le flux vidéo 151, en fonction d'un profil sélectionné, et délivre un flux filtré 153, selon les instructions du programme Pg
152.
Cette deuxième mise en oeuvre est illustrée par la figure 10. Le serveur 101 envoie dans le réseau un flux (vidéo haut débit) 102 destiné à un groupe de récepteurs acceptant une image haute qualité et avec un débit élevé. Contrairement à l'exemple précédent fonctionnant en point à point, cet exemple fonctionne en multicast.
Le nœud intermédiaire 103 reçoit le même flux ]02 que les autres récepteurs placés sur Ic réseau. Il dispose en interne d'un profil applicatif cible 1031 permettant de piloter l'algorithme de filtrage 1032 pour aboutit au débit cible du flux 1033, par élimination 1034 des paquets hors profil. Le client 104 reçoit cette vidéo filtrée 1033,
Dans le cas ou les profils fournis par le serveur ne sont pas adaptés, le nœud intermédiaire peut calculer de nouveaux profils directement par analyse des champs {P,D,T,Q}, 7,6.3 Adaptation du débit aux ressources du terminal
La figure 16 présente la structure simplifiée d'un terminal selon l'invention, qui comprend une mémoire M 160, une unité de traitement 161, équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur Pg 162. A l'initialisation, les instructions de code du programme d'ordinateur 162 sont par exemple chargées dans une mémoire RAM avant d'etre exécutées par le processeur de l'unité de traitement 161. L'unité de traitement 161 reçoit en entrée un. flux vidéo 163» Le microprocesseur μP de l'unité de traitement 161 filtre le flux vidéo 163, en fonction du profil sélectionné, selon les instructions du programme
Pg 162. L'unité de traitement 161 délivre en sortie un flux vidéo filtré 164.
La figure 11 donne un exemple de l'adaptation de l'affichage aux ressources d'un terminal 111, par exemple un terminal à ressources limitées. Le transport de la vidéo 112 contient l'ensemble des informations pour tous les terminaux. En fonction de la capacité réduite du terminal, un. usager peut choisir
(11 11), pour son confort personnel, de privilégier uo profil avec une meilleure fluidité ou un profil avec une meilleure définition, parmi ceux disponibles 1112. Par exemple, l'utilisateur choisit le profil "sport".
Il dispose en outre d'une IHM qui va lui permettre de naviguer dans les niveaux de qualité. H peut en particulier choisir d'augmenter ou diminuer le point de fonctionnement.
Les profils applicatifs sont insérés dans les paramètres généraux 1121 de la vidéo, par message SEl, table xml, EPG ou par tout autre moyen.
Le filtrage 11 13 est effectué en fonction du profil sélectionné, et le décodeur 1114 reconstruit les images correspondantes. 7,6.4 Récupération de la meilleure qualité en cas de perte de NAL dans un récepteur
L'adaptation des NALUs peut varier dans les plages de qualité correspondant à un niveau, comme indiqué par la Figure 12, le basculement d'un niveau vers un autre peut s'effectuer aux- extrémités de la plage.
En considérant un usager recevant le niveau CIP30, et donc tous les niveaux intermédiaires, la description des profils applicatifs permet de retrouver l'information fournissant la meilleure qualité. La figure 13 montre un exemple de cette approche. Les NALUs 131, 132 et 133 ont été perdus. L'analyse des champs PDTQ permet de retrouver l'information disponible de meilleure qualité en attendant l'image suivante reçue sans erreur. Les NALUs reçus 134 et 135 correspondent aux niveaux inférieurs manquants ne permettent pas le décodage. On se replie alors sur la NALU 136.
ANNEXE
<?xml version ="1.0" encoding="UTF-8 "?> <xs: schema xmlns:xs="http://www. w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs: element name="Application">
<xs : complexType>
<xs:sequence >
<xs: element ref="type" /> <xs: element ref="path_preference"/> <xs: element ref="RangeOrder" minOccurs="l"/>
<xs:element ref="debits" /> <!-- pour définir le type du profil applicatif. e.g. "sport", "film", ... — > <!-- pour illustrer le type de stratégie de repli utilisé, e.g. "temporel", "qualité", ... — >
<!-- définit les plages de fonctionnement à utiliser dans l'ordre; cet élément est obligatoire — >
<! - permet de définir les débits associés aux di fférentes pl ages e.g.. "100-300 400" pour indiquer que la première plage varie entre 100 et 300 kbits; et que la deuxième plage est à un débit de 400 kbit/s — > </xs :sequence>
<xs : attribute name=name" type="xs: string" use="required" />
</xs : complexType >
<! -- une application définit une gamme de plage de débit entre lesquels évoluer -->
</xs:element > <xs:e lement name=Espace3D"> <xs : complexType>
<xs:sequence>
<xs: element ref="Range" maxOccurs="unbounded"/> </xs:sequence>
</xs:complexType>
<!-- un espace 3D définit un ensemble de plage de débits (Range) susceptibles d' etre utilisés pour définir des profils d'applications --> </xs:element>
<xs:element name="Mesappllications "> <xs : complexType>
<xs :element ref="Application" maxOccurs="unbounded"/>
</xs:sequence> < /xs :complexType>
<!-- contient la liste des différents profils applicatifs--> </xs :element >
<xs:e lement name="Range"> <xs: c omplexType >
<xs:attribute name="id" type="xs: positiveInteger" use="required " /> <xs:attribute name="S" use=required ">
<xs : simpleType>
<xs: restriction base="xs: NMTOKEN"> <xs:enumeration value="CIF"/> <xs: enumeration value="QCIF"/> <xs:e numerationt value="SD"/> <xs:enumeration val ue="HD"/> < /x s: restriction> </ xs : simpleType>
<! - le champ S correspond au niveau spatial - ->
</xs: attribute>
<xs: attribute name="T" use="required"> <xs :simpleType>
<xs: restriction base="xs: NMTOKEN" > <xs:enumeration value="7.5Hz"/>
<xs:enumeration value="15 Hz"/> <xs :enumeration value="30Hz"/> <xs:enumeration value="60 Hz"/> </xs:restriction >
</xs: simpleType>
<!-- le champ T correspond au niveau temporel --- >
</xs:attribute> <xs: attribute name="Q" use="required" >
<xs : simpleType>
<xs: restriction base="xs: NMTOKEN" >
<xs : enumeration value= "high"/ > <xs:enumeration value ="med"/> <xs:enumeration value="low"/> </xs:restriction >
</xs: simpleType>
<! - - le champ Q correspond au niveau de qualité ou bien encore de complexité -->
</xs:attribute> <xs: attribute name="PMin" type="xs:nonNegativeInteger" use="required"/>
<xs: attribute name="PMax" type="xs : nonNegativeInteger" use="required"/ > <! - PMin, PMax définissent les limites de la plage de fonctionnement — >
</xs : complexType>
<!-- Range définit une plage de débit de fonctionnement (défini par Pmin, Pmax ) pour une résolution spatio- temporelle donnée (définie par S, T, O) -->
</xs:element > <xs: élément name="Root"> <xs : complexType >
<xs: sequence > <xs:element ref="Espace3D"/>
<xs:element ref="Mesapplications"/ > <xs:s equence > </xs: complexType>
<!-- Racine de définition du fichier. Doit contenir une définition de plages de débit (Espace 3D) , et une liste de profils applicatifs (MesApplications ) - > </xs:element> <!- Définition des types des éléments syntaxiques utilisés
<xs :element name=" débits" type="xs :string"/>
<xs: element name=RangeOrder" type="xs :string"/> <xs: element name ="path_preference "' type="xs:string "/> <xs: element name="type" type="xs: string "/> </xs:schema>

Claims

REVENDICATIONS
1. Procédé de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées, caractérisé en ce qu'il comprend une étape de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
2. Procédé de filtrage d'un flux vidéo scalable selon la revendication 1, caractérisé en ce qu'un premier desdits chemins privilégie une caractéristique représentative de la qualité de chaque image reconstruite par un terminal et un deuxième desdits chemins privilégie une caractéristique représentative de la fluidité de la vidéo.
3. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 et 2, caractérisé en ce que chacune desdites unités de données de réhaussement porte au moins deux indicateurs permettant de définir lesdits chemins, parmi les indicateurs appartenant au groupe comprenant : un indicateur de priorité (P) ;
- un indicateur de dépendance, relatif à la résolution spatiale (D) ;
- un indicateur de résolution temporelle (T) ; un indicateur de qualité et/ou de complexité (Q).
4. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 3, caractérisé en ce que lesdits chemins sont stockés dans un fichier de chemins, associant chacun desdits chemins à un profil applicatif prédéterminé.
5. Procédé de filtrage d'un flux vidéo scalable selon la revendication 4, caractérisé en ce que ledit fichier de chemins est un fichier au format XML.
6. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 4 et 5, caractérisé en ce que ledit fichier de chemins est transmis dans ledit flux vidéo, sous la forme d'au moins une unité de données d'information.
7. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comprend les étapes suivantes : séparation desdites unités de données de réhaussement, en fonction du chemin sélectionné, entre des unités de données à utiliser et des unités de données écartées ; reconstruction d'images vidéo à l'aide desdites unités de données à utiliser ;
- mémorisation desdites unités de données écartées.
8. Procédé de filtrage d'un flux vidéo scalable selon la revendication 7, caractérisé en ce qu'il comprend une première étape de transmission desdites unités de données à utiliser via un premier canal de transmission, et une seconde étape de transmission desdites unités de données écartées via un second canal de transmission.
9. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comprend les étapes suivantes : détection d'au moins une unité de données à utiliser manquante ou détériorée ;
- reconstruction d'une vidéo à partir d'unités de données correspondant à une des positions de repli du chemin sélectionné.
10. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il est mis en œuvre par au moins un desdits éléments suivants :
- serveur de flux vidéo ; - nœud intermédiaire d'un réseau de transmission ; terminal récepteur d'un flux vidéo.
11. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en œuvre d'au moins une étape du procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 10.
12. Procédé de transmission d'un flux vidéo scalable par un serveur de flux vidéo vers au moins un terminal récepteur, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées, caractérisé en ce qu'il comprend une étape de transmission d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et en ce que ledit serveur et/ou un nœud intermédiaire dudit réseau de transmission met en œuvre une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités d'au moins un terminal recevant ledit flux, et une étape de transmission des unités de données sélectionnées.
13. Procédé de transmission selon la revendication 12, caractérisé en ce que ledit serveur et/ou ledit nœud intermédiaire met en œuvre ladite étape de sélection en fonction d'une information de sélection émise par ledit terminal.
14. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en œuvre d'au moins une étape du procédé de transmission d'un flux vidéo scalable selon l'une quelconque des revendications 12 et 13.
15. Procédé de réception dans un terminal récepteur d'un flux vidéo scalable transmis par un serveur de flux vidéo, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées, caractérisé en ce qu'on utilise au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et en ce que ledit terminal récepteur met en œuvre une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
16. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en œuvre d'au moins une étape du procédé de réception d'un flux vidéo scalable selon la revendication 15.
17. Serveur de flux vidéo comprenant des moyens de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles ou spatiales, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisés, caractérisé en ce que lesdits moyens de filtrage comprennent des moyens de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et des moyens de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
18. Nœud intermédiaire d'un réseau de transmission de flux vidéo comprenant des moyens de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles ou spatiales, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisés, caractérisé en ce que lesdits moyens de filtrage comprennent des moyens de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et des moyens de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
19. Terminal récepteur de flux vidéo comprenant des moyens de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles ou spatiales, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisés, caractérisé en ce que lesdits moyens de filtrage comprennent des moyens de prise en compte d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et des moyens de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
20. Signal destiné à être transmis depuis un serveur vers au moins un terminal, pour permettre le traitement d'un flux vidéo scalable transmis par ledit serveur de flux vidéo, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées, caractérisé en ce que ledit signal porte des données de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, de façon à permettre une sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
21. Signal selon la revendication 20, caractérisé en ce qu'il porte d'une part lesdites unités de données formant ledit flux vidéo, et d'autre part lesdites données de définition.
EP06777838A 2005-07-19 2006-07-18 Procedes de filtrage, de transmission et de reception de flux video scalables, programmes, serveur, noeud intermediaire et terminal correspondants Ceased EP1941734A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0507690A FR2889017A1 (fr) 2005-07-19 2005-07-19 Procedes de filtrage, de transmission et de reception de flux video scalables, signal, programmes, serveur, noeud intermediaire et terminal correspondants
PCT/EP2006/064382 WO2007009996A1 (fr) 2005-07-19 2006-07-18 Procedes de filtrage, de transmission et de reception de flux video scalables, programmes, serveur, noeud intermediaire et terminal correspondants

Publications (1)

Publication Number Publication Date
EP1941734A1 true EP1941734A1 (fr) 2008-07-09

Family

ID=36570538

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06777838A Ceased EP1941734A1 (fr) 2005-07-19 2006-07-18 Procedes de filtrage, de transmission et de reception de flux video scalables, programmes, serveur, noeud intermediaire et terminal correspondants

Country Status (4)

Country Link
US (1) US8743950B2 (fr)
EP (1) EP1941734A1 (fr)
FR (1) FR2889017A1 (fr)
WO (1) WO2007009996A1 (fr)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101601305B (zh) * 2006-10-20 2013-01-23 诺基亚公司 用于可伸缩多媒体的自适应路径的通用指示
EP2037683A1 (fr) * 2007-09-17 2009-03-18 Alcatel Lucent Processus pour administrer à un terminal de média un flux vidéo adapté grâce à un noeud d'accès
US8155184B2 (en) * 2008-01-16 2012-04-10 Sony Corporation Video coding system using texture analysis and synthesis in a scalable coding framework
GB0905184D0 (en) * 2009-03-26 2009-05-06 Univ Bristol Encryption scheme
TWI595770B (zh) 2011-09-29 2017-08-11 杜比實驗室特許公司 具有對稱圖像解析度與品質之圖框相容全解析度立體三維視訊傳達技術
CN104041023B (zh) 2011-09-29 2016-09-14 杜比实验室特许公司 双层帧相容全分辨率立体3d视频输送
US11327942B2 (en) 2015-10-08 2022-05-10 Signal Vine, Inc. Systems and methods for providing a two-way, intelligent text messaging platform
CN110830762B (zh) * 2018-08-13 2021-06-18 视联动力信息技术股份有限公司 一种音视频数据的处理方法和系统
US10778938B2 (en) * 2018-12-20 2020-09-15 Hulu, LLC Video chunk combination optimization
CN110147239B (zh) * 2019-05-22 2023-03-21 苏州仙峰网络科技股份有限公司 游戏安装包体的多重压缩的方法、设备及存储介质

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5708473A (en) * 1994-08-30 1998-01-13 Hughes Aircraft Company Two stage video film compression method and system
US5621660A (en) * 1995-04-18 1997-04-15 Sun Microsystems, Inc. Software-based encoder for a software-implemented end-to-end scalable video delivery system
US6233017B1 (en) * 1996-09-16 2001-05-15 Microsoft Corporation Multimedia compression system with adaptive block sizes
US5844613A (en) * 1997-03-17 1998-12-01 Microsoft Corporation Global motion estimator for motion video signal encoding
CA2252170A1 (fr) * 1998-10-27 2000-04-27 Bruno Bessette Methode et dispositif pour le codage de haute qualite de la parole fonctionnant sur une bande large et de signaux audio
GB9909606D0 (en) * 1999-04-26 1999-06-23 Telemedia Systems Ltd Networked delivery of profiled media files to clients
WO2002031670A1 (fr) * 2000-10-12 2002-04-18 Teraglobal Communications Corp. Procede et systeme de transmission de qualite de service selectionnable par le destinataire sur des reseaux
US20020073238A1 (en) * 2000-11-28 2002-06-13 Eli Doron System and method for media stream adaptation
KR100834748B1 (ko) * 2004-01-19 2008-06-05 삼성전자주식회사 스케일러블 비디오 스트림 재생 방법 및 장치
KR100834749B1 (ko) * 2004-01-28 2008-06-05 삼성전자주식회사 스케일러블 비디오 스트림 재생장치 및 그 방법
EP1599046A1 (fr) * 2004-05-19 2005-11-23 THOMSON Licensing Procédé de codage des données vidéo d'une séquence d'images
KR100786132B1 (ko) * 2004-11-01 2007-12-21 한국전자통신연구원 적응적으로 세분화된 ｇｏｐ 구조를 이용한 계층적ｂ픽쳐-기반 동영상 부호화 및 복호화 방법
US20060156363A1 (en) * 2005-01-07 2006-07-13 Microsoft Corporation File storage for scalable media
US7538823B1 (en) * 2005-09-23 2009-05-26 Cirrus Logic, Inc. Luminance/chrominance video data separation circuits and methods and video systems utilizing the same
KR100825752B1 (ko) * 2005-11-21 2008-04-29 한국전자통신연구원 Ｓｖｃ에서 효율적인 비트율 제어 방법 및 장치
FR2894421B1 (fr) * 2005-12-07 2008-01-18 Canon Kk Procede et dispositif de decodage d'un flux video code suivant un codage hierarchique
FR2899758A1 (fr) * 2006-04-07 2007-10-12 France Telecom Procede et dispositif de codage de donnees en un flux scalable
US8392595B2 (en) * 2006-09-15 2013-03-05 France Telecom Method and device for adapting a scalable data stream, corresponding computer program product and network element

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
NICOLA ADAMI ET AL: "Fully embedded entropy coding with arbitrary multiple adaptation capabilities", 70. MPEG MEETING; 18-10-2004 - 22-10-2004; PALMA DE MALLORCA; (MOTION PICTURE EXPERT GROUP OR ISO/IEC JTC1/SC29/WG11),, no. M11378, 15 October 2004 (2004-10-15), XP030040152, ISSN: 0000-0251 *
See also references of WO2007009996A1 *

Also Published As

Publication number Publication date
WO2007009996A1 (fr) 2007-01-25
US8743950B2 (en) 2014-06-03
FR2889017A1 (fr) 2007-01-26
US20080310497A1 (en) 2008-12-18

Similar Documents

Publication Publication Date Title
WO2007009996A1 (fr) Procedes de filtrage, de transmission et de reception de flux video scalables, programmes, serveur, noeud intermediaire et terminal correspondants
EP1839442B1 (fr) Dispositifs et procedes de codage et de decodage echelonnables de flux de donnees d&#39;images, signal, programme d&#39;ordinateur et module d&#39;adaptation de qualite d&#39;image correspondants
FR2939593A1 (fr) Procede et dispositif de codage video
FR2931610A1 (fr) Procede et un dispositif de transmission de donnees d&#39;images
FR2903556A1 (fr) Procedes et des dispositifs de codage et de decodage d&#39;images, un systeme de telecommunications comportant de tels dispositifs et des programmes d&#39;ordinateur mettant en oeuvre de tels procedes
FR2909474A1 (fr) Procede et dispositif de codage d&#39;images numeriques et procede et dispositif de decodage d&#39;images numeriques codees
EP1779669A1 (fr) Procede de mise en forme de trames d&#39;une sequence video
EP2052545B1 (fr) Dispositif et procede de codage et de decodage echelonnables de flux de donnees d&#39;images, signal et programme d&#39;ordinateur correspondants
EP3707900B1 (fr) Procédé de formation d&#39;une séquence d&#39;images de sortie à partir d&#39;une séquence d&#39;images d&#39;entrée, procédé de reconstruction d&#39;une séquence d&#39;images d&#39;entrée à partir d&#39;une séquence d&#39;images de sortie, dispositifs, equipement serveur, equipement client et programmes d&#39;ordinateurs associés
FR2932050A1 (fr) Procede et dispositif de transmission de donnees video
FR2820255A1 (fr) Procedes de codage et de decodage d&#39;images, dispositifs, systemes, signaux et applications correspondants
FR2896117A1 (fr) Procedes de codage et de decodage d&#39;une sequence d&#39;images, dispositifs , programmes d&#39;ordinateur, et signal correspondants
WO2009138656A2 (fr) Transmission d&#39;un flux video code par codage hierarchique
Capovilla et al. An architecture for distributing scalable content over peer-to-peer networks
EP3378232B1 (fr) Procédé de traitement de données codées, procédé de réception de données codées, dispositifs, et programmes d&#39;ordinateurs associés
FR2913163A1 (fr) Procede et dispositif de transmission de donnees video
WO2008032001A1 (fr) Procede et dispositif d&#39;adaptation d&#39;un flux de donnees scalable, produit programme d&#39;ordinateur et equipement reseau correspondants
WO2012056148A1 (fr) Codage video echelonnable a partir d&#39;un epitome hierarchique
FR2923970A1 (fr) Procede et dispositif de formation, de transfert et de reception de paquets de transport encapsulant des donnees representatives d&#39;une sequence d&#39;images
EP2172023B1 (fr) Adaptation d&#39;un flux de donnees scalables avec prise en compte des retransmissions
FR3041851A1 (fr) Procede d&#39;allocation de debit, dispositif, codeur et programme d&#39;ordinateur associes
Ramzan et al. Scalable and Adaptable Media Coding Techniques for Future Internet.
FR2913844A1 (fr) Procede et dispositif d&#39;allocation de debit dans une sequence video
Lee et al. Dynamic full-scalability conversion in scalable video coding
FR2936388A1 (fr) Procede et dispositif de transcodage d&#39;une sequence video

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080507

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: AMONOU, ISABELLE

Inventor name: PATEUX, STEPHANE

Inventor name: BABONNEAU, GERARD

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

17Q First examination report despatched

Effective date: 20140102

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20170612