EP1941734A1 - Method for filtering, transmitting and receiving scalable video streams and corresponding programs, server, intermediate node and a terminal - Google Patents

Abstract

The invention relates to a method for filtering a scalable video stream, organised in the form of data unit blocks, each of which comprises a base data unit and a set of data units distributed according to two types of enhancement data, corresponding respectively to time and/or space and/or quality characteristics and making it possible to define several quality levels. The inventive method consists in defining at least two distinct filtering profiles, or paths of each block data units, wherein each path defines a row of successive foldover positions and each foldover position uses at least by one less data units than a previous position, and in selecting one of said paths according to a predetermined criterion, taking into account the type of content of said stream and/or at least one information item representing the capacities of a terminal receiving said stream.

Description

Methods of filtering, transmitting and receiving scalable video streams, programs, server, intermediate node and corresponding terminal. FIELD _OF THE INVENTION 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:

- JSVM 2.0: Joint Video Team (JVT) of ISO / IEC MPEG & ITU-T VCEG, N7084, Scalable Video Model Joint (JSVM) 2.0 Encodlng Algorithm Reference, Description, April 2005, Busan (Julien Reichel, Heiko Schwarz, Mathias Wien); and

- W D2: J. Reichel, H. Schwarz M. Wien - Scalable Video Coding - Working Draft 2 - ISO / IEC JTC1 / SC29 / WG11, W70S4, April 2005, Busan.

3, prior art% 1 scalable video systems (scalable)

Currently, most video encoders generate a single compressed stream corresponding to the entirety of an encoded sequence. Each client wishing to use the compressed file for decoding and visualization must download (or "stream") the complete compressed file. However, in a heterogeneous system (for example the Internet), not all clients have the same type of access to data: the bandwidth, the processing capacities, the screens of the different clients can be very different (for example, on an Internet network, one of the customers will be able to have an ADSL speed of 1024 kb / s and a powerful microcomputer (PC) while the other will only benefit from a modem access and a PDA ). An obvious solution to this problem is to generate several compressed streams corresponding to different bit rates / resolutions of the video sequence: it is the simulcast, This solution is however sub-optimal in terms of efficiency, and requires knowing in advance the characteristics of all potential customers _;

More recently, scalable (or scalable) video coding algorithms have been introduced, that is to say with adaptable quality and variable space-time resolution, for which the coder generates a compressed stream in several layers, each of its layers being nested in the upper level layer. These algorithms are now being adopted as an amendment to MPEG4-AVC (hereinafter referred to as SVC).

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:

- video on demand service, or VOD (target terminals: UMTS, PC ADSL, TV ADSL, ..);

- session mobility (resumption on a PDA of a video session started on TV, or on a UMTS mobile of a session started on GPRS);

- continuity of session (bandwidth sharing with a new application);

- High definition TV (single encoding to serve SD clients - "Standard Definition" and HD - "High Definition"); - videoconferencing (single encoding for UMTS / Internet clients);

2.1.1 Granularity of the scability

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). In the following, it will be considered that 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. We will speak later of scalability MGS ("Medium Grain Scalability") in accordance with the rule adopted in MPEG. From the bit stream, 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

Alternatively 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. More precisely, 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.

The main features of this technique are:

- pyramidal solution with dyadic subsampling of the input components; time-division decomposition of MCTF ("Motion Compensated Temporal Filtering") type at each level;

- base level coding (AVC compatible);

coding of the higher levels by subtraction of the reconstructed previous level and coding of the residues in form;

- a basic level; and

* one or more levels of enhancement obtained by multi-pass coding of bit planes (hereinafter: FGS),

In order to achieve a rate adaptation, the texture information is coded using a progressive scheme at each level:

coding of a first level of minimum quality (called "Base Layer" - Base layer);

- coding of progressive refinement levels (called "Enhancement Layer"). 2.3 Architecture of the SVC Encoder

The SVC encoder is based on a two-layer system, like AVC:

- The VCL layer ("Video Coding Layer") manages the encoding of the video;

- The Network Abstraction Layer (NAL) provides an interface between the VCL layer and the outside. In particular, this level organizes in AUs ("access units" or "blocks of data units") the different

NALU ("NAL Units" or "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.

24 Scalability mode signaling in the NAL layer SVC - - In order to properly decode an NAL SVC, it is necessary to signal its positioning in the space (S, T, Q) illustrated in FIG.

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. A simple example is given in FIG. 3, for a two-dimensional 2D context (T, Q): 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.

In this example, we see that there are several "paths" 33, 34 and 35, possible decoding between points a and d: (a, b, c, d) but also (a, b, d) or (a, c, d).

We understand that some applications may favor a path relative to another, For example, it may be wise to use the path (a, c, d) to obtain a fluid video in 30 Hz, but rather (a, b , d) if one wishes to privilege the quality in 15 Hz.

This path is therefore dependent on the application and the coding mode used. 2.5.1 Fixed path

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 path will always be used, which is decoded in 30 or in 15 Hz. The major disadvantage that appears then is that point b will not be decoded, even in 15 Hz, whereas it could be more interesting to decode it to have a better quality in 15Hz.

In this context, a single indicator is used to code this fixed path. 2.5.2 variable path

This mode proposes to leave the application (or network) the choice of the extraction path. To do this, we introduce an additional element, called the priority indicator, which will solve the problem mentioned above when decoding in 30 Hz.

The following two tables show respectively the priorities assigned

10 to the NALUs A, B, C and D in the example above and the result of the filtering in 15 Hz and in 30 Hz according to the priority chosen at the decoding (are decoded / conserved the NALUs which appear in the table). It will be noted that it is possible in 30 Hz to define several different paths according to the priority index assigned to the four NALUs.

15

The filtering rules used here are: For a time resolution T target (30 or 15 Hz) keep all

20 NALs whose temporal resolution is less than or equal to the requested resolution (T_NAL <= T-CiWe) and the priority is less than or equal to the requested priority (pri, orityJSTAL <= target_preferred). The method is generalizing to more than two dimensions. In the example illustrated by FIG. 4A, there are three dimensions of scalability:

D = Spatial: QCIF / CIF (dependence D is a superset of the spatial resolution S);

T = Time: 15 Hz / 30 Hz;

Q = Low / High Quality / Complexity - An example of an association of priorities to different NALUs is shown in the figure, and an example of associated filtering is shown in the table below.

In this context, a dual indicator is necessary: 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. Thus, throughout the rest of the document, 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;

D indicates the dependence (superset of the spatial resolution

S);

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.

One of the aims of the invention is to overcome this problem. 3 Disadvantages of the prior art

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.

Neither of the two solutions (fixed or variable) allows to manage a fallback mode that would allow a user to reduce the quality or the resolution of the received data according to his own preferences.

4 Objectives of the invention

The invention particularly aims to overcome these disadvantages of the state of the art. More specifically, 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.

Thus, 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

In other words, 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.

5._ Summary of the invention

These objectives, and others which will become clear later, are achieved according to the invention using 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. According to the invention, 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.

Thus, 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.

Advantageously, 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,

It is thus possible to favor, depending on the content, the quality of the image _" for example for a film, or the fluidity of the movements, for example for sports. Many other paths (also called profiles) and variants can of course be defined,

Preferably, 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);

an indicator of dependence, relative to the spatial resolution (D);

a time resolution indicator (T);

- an indicator of quality and / or complexity (Q).

According to an advantageous embodiment of the invention, 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.

It can for example be stored and / or calculated on the fly by the terminals. In a preferred embodiment, said path file is transmitted in said video stream, in the form of at least one piece of information data.

Advantageously, 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;

reconstruction of video images using said data units to be used;

storage of said discarded data units.

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.

Of course, the discarded data units can also be directly deleted.

Advantageously, the method comprises the following steps: detection of at least one data unit to be used that is missing or deteriorated;

reconstructing a video from data units corresponding to one of the fallback positions of the selected path.

Thus, in case of loss of a package, we do not lose the restitution of the video, but we simply switch to a lower quality.

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:

- video stream server;

- intermediate node of a transmission network; - receiving terminal of a video stream.

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. According to another aspect of the invention, 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.

Advantageously, 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.

According to yet another aspect, 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.

According to this method, it uses at least two profiles, or chemina, 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.

Finally, 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. Such 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.

According to an advantageous embodiment, 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

Other features and advantages of the invention will appear more clearly on reading the following description of a preferred embodiment of the invention, given as a simple illustrative and nonlimiting example, and the appended drawings in which: 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, and 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, and 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, ...) -

We place ourselves in the context of known generic filtering, described previously. Each NAL is therefore defined by the quadruple! (P, D, T, Q).

The filtering is carried out according to N of the 4 dimensions (N <= 4). We have fallback modes, that is to say, mechanisms that make it possible to favor a path in space (D, T, Q) when the target resolutions can not be reached (for reasons of reduction of flow, of complexity, choice of the user ...).

According to the invention, 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:

SD ^@ 30Hz high ≈> SD ^@ 30Rz low => CIF @ 30Hz high => CIF @ 15Hz high

Film profile: we favor quality with fluidity and spatial resolution: SD @ 30Hz high => SD ^@ 15Hz high ≈> SD@7.5Hz high =>

CIF@7.5Eïz high.

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). The flow of the filtering process, illustrated by the flowchart of FIG. 5, is as follows;

1. 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);

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

On _cibIe, T'_cit> on, Q'_ ible _c);

4. 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);

5. 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.

Each of these steps is detailed later.

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

According to an advantageous embodiment, it is proposed to improve the numbering proposed in the prior art by declaring that each basic level is of priority_id 0 This approach is illustrated by FIG. 4B. It effectively makes it possible to eliminate the points in anomaly between the spatio-temporal resolutions requested and delivered (box in bold of the table of the prior art). 7.3 Establishment of the filtering table

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 ,.

In the table of Figure 6, it can be noted that each series is monotonous in the table, while the curve 61 is not. This is an advantage of the solution of the invention.

A fallback mode corresponds to a descent (arrows 61 and 62) in the table of FIG. 6. For example, we define:

- A sport profile 61, according to which one favors the temporal fluidity CIF @ 30Hz high -> CIF @ 30Hz low => QCIF @ 30Hz high => QCDF®30HzLow> QCJF @ 15Hz high;

a film profile 62, according to which quality is preferred over fluidity and spatial resolution:

CIF @ 30Hz high -> CIF @ 15Hz high => QCtF @ 15Hz high => QCIF @ 7.5Hz high.

The same approach can be defined by evolution of flow ranges, as illustrated by FIG. 8: - sport profile 81: SD @ 30Hz (high to low) => CIP @ 30Hz (hgh to low) => QCIF @ 30Hz (hightolow) ... - film profile 82 ...

In order to define these fallback modes according to the applications, one can imagine for example an XML file of the application profiles of the following type -: -

<? xml veersion = "1.0"? >

<Root xmls: xsi = ^" http: // www .w3.org/2001 / XMLSchema ~ instance" xsi: noNamespaceSchemalocation = "C: \ My Documents \ Patents \ DIH \ SVC Transport \ XML \ Replication." Xsd "^><3DSpace>

<! - Defining operating ranges for typical resolutions ->

<Range id = "1" S = "QCIF" T = "15Hz" Q = "low" PMin = "0" PMax = "0" /> <! --This first range corresponds to QCIF 15hz with PMin = PMax, i.e. a single point "->

<Range id = "2" S = "QCIF" T = "15Hz" "Q =" high "PMin =" 0 "PMax =" 1 "/>

<! --This first beach corresponds to QCIF 15hz with PMin <PMax, several 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" /> <3D Space>

<Myapplications>

<Application name = "application one"> <! - application number one -> <tγpe> sport </ type> <! --Sports-type application ->

<path_preference> time </ path_preference> <RangeOrder> "8 4 2" </ RangeOrder> <! - This path indicates time flow preference - -> <flows> "150 150-300 450 450-900" </ debits>

</ Application>

<Application name = "application two"> <! - application number two -> <type> movie <type> <! --application type movie "->

<path_ _p reference> quality </ path_preference><RangeOrder>"9 6 2"</RangeOrder><! - this path indicates a preference of quality compared to the other axes -><flows>"100-200 400-600 800-900"</debits>

<Application> <Application name = "application three">

<! - my application number three - -><type> mobile </ type><path_preference> resolution </ path _preference> <RangeOrder>"9 6 5"</RangeOrder><debits/></Application></Myapplications><Roct>

An appendix is a complete diagram to validate this example.

Any other means of describing the application profiles is possible, such as a table in a programming language, or an insertion in the video stream (SEI to be defined).

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". Thus on this example, 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.

It should be noted that the 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

Using the example of application profiles as described above, 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. Let p_cible = 3, D_cible≈CIP, T_cible = 30H2, Q_cible = High; 2- During a necessary adaptation, 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). If the constraint is not satisfied, we can then decide to make a withdrawal (selection of the lower range) or recovery (selection of the upper range). The search for the appropriate "range" and "priority_id" can be continued until the constraint is obtained. 7.5 Filtering

This step, conventional in itself, consists of;

• Reject (or adequately handle - for example, high-speed routing) all packets for which (P_paq> P_current) and / or

(S_paq> S_current) and / or (T_ρaq> T_couxant) and / or (Q'_paq> Q_current),

• Treat other packages (transmission, storage, ...). 7.6. EXAMPLE OF APPLICATIONS OF THE INVENTION 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.

The table below describes several examples of typical actions and their possible locations in the network:

7.6.1 Context 1: client-server model (adaptation to resources and user choices)

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 initialization, 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.

This implementation is illustrated by FIG. 9. 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

912 of the client, according to which it filters (913) the elements 914 of the video coding.

Only packets retained, forming the filtered video 915, are transmitted to the client.

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 At initialization, 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

152.

This second implementation is illustrated in FIG. 10. 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,

In the case where the profiles provided by the server are not adapted, 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 initialization, 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.

Pg 162. 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

(11 11), for his personal comfort, to favor a profile with a better fluidity or a profile with a better definition, among those available 1112. For example, the user chooses the profile "sport".

It also has an HMI that will allow it to navigate the levels of quality. In particular, 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.

By considering a user receiving the CIP30 level, and therefore all the intermediate levels, the description of the application profiles makes it possible to find the information providing the best quality. Figure 13 shows an example of this approach. 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.

ANNEX

<? 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"/><! - to define the type of the application profile. eg "sport", "movie", ... -><! - to illustrate the type of fallback strategy used, eg "temporal", "quality", ... ->

<! - defines the operating ranges to be used in order; this element is mandatory ->

<! 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>

<xs: attribute name = name "type =" xs: string "use ⁼ " required "/>

</ xs: complexType>

<! - an application defines a range of flow rate between which to evolve ->

</ xs: element><xs: e lename name = 3D Space "> <xs: complexType>

<Xs: sequence>

<xs: element ref = "Range" maxOccurs = "unbounded" /> </ xs: sequence>

</ Xs: complexType>

<! - a 3D space defines a set of range (Range) that can be used to define application profiles -> </ xs: element>

<xs: element name = "Myapplications"> <xs: complexType>

<xs: element ref = "Application" maxOccurs = "unbounded" />

</ xs: sequence> </ xs: complexType>

<! - contains the list of different application profiles -> </ 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: base restriction = "xs: NMTOKEN"><xs: enumeration value = "CIF"/><xs: enumeration value = "QCIF"/><xs: numerationt value = "SD"/> <xs: enumeration val ue = "HD"/></ xs: restriction></ xs: simpleType>

<! - the S field corresponds to the spatial level - ->

</ xs: attribute>

<xs: attribute name = "T" use = "required"> <xs: simpleType>

<xs: base restriction = "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>

<! - the field T corresponds to the temporal level --->

</ 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>

<! - - the Q field corresponds to the level of quality or complexity ->

</ Xs: attribute> <xs: attribute name = "PMin" type = "xs: nonNegativeInteger" use = "required ^" />

<xs: attribute name = "PMax" type = "xs: nonNegativeInteger" use = "required" /> <! - PMin, PMax define the limits of the operating range ->

</ xs: complexType>

<! - Range defines an operating flow range (defined by Pmin, Pmax) for a given spatio-temporal resolution (defined by S, T, O) ->

</ xs: element> <xs: element name = "Root"> <xs: complexType>

<xs: sequence> <xs: element ref = "3DSpace" />

<xs: element ref = "myapplications" /> <xs: s equence> </ xs: complexType>

<! - 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

<xs: element name = "bitrate" 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

A method of filtering a scalable video stream, organized into blocks of data units each comprising 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 a plurality of quality levels, according to the number and type of raising data units used, characterized in that it comprises a definition step 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 an initial position, each fallback position using at least one unit of data. data of less than the previous position, and a step of selecting one of said paths according to a predetermined criterion taking into account a type of cont said flow and / or at least one information representative of the capabilities of the terminal receiving said flow.

2. A method of filtering a scalable video stream according to claim 1, characterized in that 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.

3. A method of filtering a scalable video stream according to any one of claims 1 and 2, characterized in that 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);

an indicator of dependence, relative to the spatial resolution (D);

a time resolution indicator (T); an indicator of quality and / or complexity (Q).

4. A method of filtering a scalable video stream according to any one of claims 1 to 3, characterized in that said paths are stored in a path file, associating each of said paths to a predetermined application profile.

5. A method of filtering a scalable video stream according to claim 4, characterized in that said path file is a file in XML format.

6. A method of filtering a scalable video stream according to any one of claims 4 and 5, characterized in that said path file is transmitted in said video stream, in the form of at least one data unit of information.

7. A method of filtering a scalable video stream according to any one of claims 1 to 6, characterized in that it comprises the following steps: separation of said raising data units, depending on the selected path, between units data to be used and data units discarded; reconstructing video images using said data units to be used;

storage of said discarded data units.

8. A method of filtering a scalable video stream according to claim 7, characterized in that it comprises a first step of transmission of said data units to be used via a first transmission channel, and a second step of transmission of said data transmission units. data discarded via a second transmission channel.

9. A method of filtering a scalable video stream according to any one of claims 1 to 8, characterized in that it comprises the following steps: detection of at least one data unit to be used missing or damaged;

reconstructing a video from data units corresponding to one of the fallback positions of the selected path.

10. A method of filtering a scalable video stream according to any one of claims 1 to 9, characterized in that it is implemented by at least one of the following elements:

- video stream server; - intermediate node of a transmission network; receiving terminal of a video stream.

11. 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 implementation of at least one step of the method of filtering a scalable video stream according to any one of claims 1 to 10.

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 into blocks of 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 making it possible to define a plurality of quality levels, according to the number and the type of uplift data units used, characterized in that it 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 positions of successive folds, starting from an initial position, each fallback position using at least one data unit less than the previous position, and in that said server and / or an intermediate node of said transmission network implements a step of selecting one of said paths according to a predetermined criterion taking into account a content type of said flow and / or of at least one piece of information representing the capabilities of at least one terminal receiving said stream, and a step of transmitting the selected data units.

13. Transmission method according to claim 12, characterized in that said server and / or said intermediate node implements said selection step based on a selection information transmitted by said terminal.

14. 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 implementation of at least one step of the method of transmitting a scalable video stream according to any one of claims 12 and 13.

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 into blocks of data units each comprising a basic data unit and a data stream. 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 a plurality of quality levels, according to the number and the type of raising data units used, characterized in that at least two distinct profiles or paths for filtering the data units of each block are used, each path defining a series of successive fallback positions, starting from an initial position, each fallback position using at least one data unit less than the previous position, and in that said receiving terminal toreur 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 at least one piece of information representative of the capabilities of the terminal receiving said stream.

16. 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 code instructions program for implementing at least one step of the method of receiving a scalable video stream according to claim 15.

A video stream server comprising means for filtering a scalable video stream, organized into blocks of data units each comprising a basic data unit and a set of distributed enhancement data units according to at least two types. of enhancement data, respectively corresponding to temporal or spatial characteristics, and making it possible to define a plurality of quality levels, according to the number and type of raising data units used, characterized in that said filtering means comprise means 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 an initial position, each fallback position using at least one unit of less than the previous position, and means for selecting one of said paths according to a predefined criterion determined taking into account a content type of said stream and / or at least one information representative of the capabilities of the terminal receiving said stream.

18. An intermediate node of a video stream transmission network comprising filtering means of a scalable video stream, organized into blocks of data units each comprising a basic data unit and a set of data data units. enhancement distributed according to at least two types of enhancement data, respectively corresponding to temporal or spatial characteristics, and making it possible to define a plurality of quality levels, according to the number and type of enhancement data units used, characterized in that said filtering means comprise means for defining at least two distinct profiles, or paths, for filtering the data units of each block, each path defining a series of successive foldback positions, starting from an initial position, each position using at least one less unit of data than the previous position, and means for selecting one of said paths according to a predetermined criterion taking into account a content type of said stream and / or at least one piece of information representative of the capabilities of the terminal receiving said stream.

A video stream receiving terminal comprising means for filtering a scalable video stream, organized into blocks of 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, respectively corresponding to temporal or spatial characteristics, and making it possible to define a plurality of quality levels, according to the number and type of enhancement data units used, characterized in that said filtering means comprise means taking into account 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 an initial position, each fallback position using at least one minus one data unit less than the previous position, and means for selecting one of said paths as a function of u n predetermined criterion taking into account a content type of said stream and / or at least one piece of information representative of the capabilities of the terminal receiving said stream.

20. 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 into blocks of video transmission units. data 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 making it possible to define a plurality of quality levels, according to the number and type of enhancement data units used, characterized in that said signal carries definition data of at least two distinct profiles or paths for filtering the data units of each block, each path defining a series of successive fallback positions, from of an initial position, each fallback position using at least one data unit of less than the previous position, so as to allow selection of one of said paths according to a predetermined criterion taking into account a type of content of said stream and / or at least one piece of information representative of the capabilities of the terminal receiving said stream.

21. Signal according to claim 20, characterized in that it carries on the one hand said data units forming said video stream, and on the other hand said definition data.