EP2281395A2 - Transmission d'un flux video code par codage hierarchique - Google Patents

Transmission d'un flux video code par codage hierarchique

Info

Publication number
EP2281395A2
EP2281395A2 EP09745975A EP09745975A EP2281395A2 EP 2281395 A2 EP2281395 A2 EP 2281395A2 EP 09745975 A EP09745975 A EP 09745975A EP 09745975 A EP09745975 A EP 09745975A EP 2281395 A2 EP2281395 A2 EP 2281395A2
Authority
EP
European Patent Office
Prior art keywords
packets
stream
transmission
transmitted
packet
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
EP09745975A
Other languages
German (de)
English (en)
Inventor
Bertrand Berthelot
Stéphanie RELIER
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 EP2281395A2 publication Critical patent/EP2281395A2/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/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
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]

Definitions

  • the PES packets thus encoded at the output of the encoder are multiplexed, at a multiplexer 12, according to the MPEG-2 TS protocol in order to provide packets, called TS packets, all of the same length, which can easily be encapsulated in IP packets to be transmitted in an IP network. More precisely, the MPEG-2 TS standard makes it possible to multiplex one or more programs in a single data stream.
  • the data contained in the basic stream is sufficient to reconstruct the original video / audio stream on reception, the data carried in the enhancement streams serving to improve certain aspects of this basic stream.
  • These enhancement streams indeed make it possible to improve the quality or the spatial resolution, or the temporal frequency of the video stream concerned, but they remain optional in view of the basic data flow alone allowing the decoding and presentation of the transported data.
  • the bandwidth when the bandwidth is too small to be able to transmit the base stream with the corresponding enhancement streams, it may be advantageous to filter data from certain enhancement streams to reduce the amount of data transmitted and thereby transmit a certain amount of data. amount of data adapted to the available bandwidth.
  • each IP packet here can potentially comprise TS packets of any layer enhancement stream and any coding dimension. Therefore, in order to perform a relevant filtering, it is then required to perform a de-encapsulation analysis of each IP packet to potentially detect TS packets relating to the enhancement data stream that is to be filtered.
  • the present invention improves the situation.
  • the first series of coded packets may be derived from encoding according to an MPEG-4 SVC type protocol followed by multiplexing according to an MPEG-2 TS type protocol, and the determined transmission protocol may correspond to the IP protocol.
  • the flow indication may correspond to the TOS (for Type Of Service) field.
  • a second aspect of the present invention proposes a transmission adaptation method, in a packet transmission network according to a determined transmission protocol, of a video stream coded in a hierarchical manner at least in the form of a basic stream. and at least one enhancement stream in one dimension; each packet transmitted in the network being obtained by applying a predefined transmission method; said adaptation method comprising the following steps at an adaptation entity:
  • Each transmitted packet may advantageously include a flow indication relative to the base flow or enhancement stream to which it belongs, and step 121 may then be implemented based on said flow indication.
  • a third aspect of the present invention provides a transmission entity adapted for carrying out the transmission method according to the first aspect of the present invention.
  • a fourth aspect of the present invention provides a transmission matching entity adapted for carrying out the transmission matching method according to the second aspect of the present invention.
  • a fifth aspect of the present invention provides a system for transmitting a hierarchically encoded video stream at least in the form of a base stream and at least one one-dimensional enhancement stream; comprising a transmission entity according to the third aspect of the present invention and an adaptation entity according to the fourth aspect of the present invention.
  • a sixth aspect of the present invention provides a computer program including instructions for implementing the transmission method according to the first aspect of the present invention, when the program is executed by a processor.
  • a seventh aspect of the present invention provides a computer program including instructions for implementing the transmission adaptation method according to the second aspect of the present invention, when the program is executed by a processor.
  • FIG. 1 illustrates a conventional architecture of a video stream transmission coded according to the MPEG-4 AVC protocol and transmitted over IP according to the MPEG-2 TS protocol ;
  • Figure 2 illustrates the main steps of a method of transmitting a data stream according to an embodiment of the present invention;
  • FIG. 3 illustrates an image processing system adapted for implementing a transmission method according to an embodiment of the present invention;
  • FIG. 4 illustrates the application of a data stream transmission method according to an embodiment of the present invention;
  • Figure 5 illustrates a transmission entity and a transmission adaptation entity according to an embodiment of the present invention.
  • an embodiment of the present invention may advantageously be implemented in a hierarchical coded data transmission which makes it possible to distinguish between basic data and optional data, the basic data. being required at least to allow a decoding of the transmitted data, the optional data complementing this basic data to improve certain aspects such as spatial resolution, or the temporal resolution or the quality of the decoded transmitted data.
  • Figure 2 illustrates the main steps of a method of transmitting a video stream according to an embodiment of the present invention. These steps are performed after the coding of the data to be transmitted and before the effective transmission of coded data on the transmission network used for this purpose.
  • the transmission network used is an IP network and the multiplexing of the coded data transmitted over IP is carried out according to the MPEG-2 TS protocol.
  • a first series of coded packets is received from a coding step according to a hierarchical coding protocol, for example according to the MPEG-4 SVC protocol.
  • a hierarchical coding protocol for example according to the MPEG-4 SVC protocol.
  • Such a coding protocol makes it possible to code data according to a basic data stream and one or more enhancement data streams, per dimension considered, that is to say either by quality, or by spatial resolution, or by temporal resolution.
  • this is particularly the case in an existing data coding architecture based on an MPEG-2 TS transmission protocol.
  • this first series of coded packets can correspond to what is obtained in an architecture as illustrated in FIG. 1 when the encoder applies MPEG-4 SVC coding.
  • these packets are packets of MPEG-2 TS type.
  • step 21 there is therefore a first set of ordered packets in a first order.
  • a second set of coded second order packets is obtained.
  • This second series of coded packets is obtained by browsing in the first order the first series of packets and successively grouping the packets of this series by a homogeneous group of packets.
  • the term "homogeneous group of packets" is understood here to mean a group of packets that are all related to the same type of coded data stream.
  • the different types of streams correspond in particular to a basic stream or to a raising stream of a given level, or to an audio stream.
  • Packets in the first set that do not belong to either a base stream or an enhancement stream are associated with a base stream and thereby grouped into groups of base stream packets. This is the case, for example, for audio stream packets.
  • a homogeneous group of packets consists of packets that all come from the same type of stream, base stream, including audio streams, or enhancement streams, of the same level of layer and a coding according to the same dimension.
  • This architecture is based on an encoder 31 which is in charge of coding audio and video data according to a hierarchical coding protocol such as the MPEG-4 SVC coding protocol. Then, at the output of the encoder, the data is supplied to a multiplexer 32 of the MPEG-2 TS type.
  • the flow MPEG-2 TS multiplexed at the output of multiplexer 32 contains elementary video and audio streams. It is possible to adjust by dimension, that is to say for the spatial resolution, or the time frequency, or the quality, the number of enhancement layers and the parameterization of these layers at the level of the encoder 31 depending on the video and / or audio application (s) and the transmission context.
  • the audio content can be encoded in an audio coding format such as the MPEG-2 audio format for example.
  • This multiplexer 32 is adapted to provide the first set of coded packets.
  • Video and audio content thus compressed according to the MPEG-4 SVC protocol can be decoded at different bit rates on the basis of temporal adaptability (or scalability), or according to different spatial resolutions on the basis of spatial adaptability. , or according to different levels of quality on the basis of quality adaptability.
  • the base layer for the base streams is compatible with an MPEG-4 AVC / H.264 encoding format.
  • Such a coded stream consists of a series of access units or AU (for 'Access Units' in English), each corresponding to compressed data relating to an image of the video sequence at a given instant.
  • An AU is split into one or more NALUs (for Network Abstraction Layer Units) for packet transmission management on the transmission network thereby facilitating the transport mechanisms on that network.
  • the NALUs can be of the 'data' type, referenced VCL (for 'Video Coding Layer' in English) or of the 'signaling' type, in particular referenced SEI (for 'Supplemental Enhancement Information' in English), SPS (for 'Sequence Parameter Set' in English), or PPS (for 'Picture Parameter Set' in English).
  • VCL for 'Video Coding Layer' in English
  • SEI for 'Supplemental Enhancement Information' in English
  • SPS for 'Sequence Parameter Set' in English
  • PPS for 'Picture Parameter Set' in English
  • a NALU header according to the MPEG-4 SVC protocol consists of bytes which contain in particular fields indicating a 'Priorityjd' priority level, a Dependencyjd dependency level, a Temporaljevel time reference, a quality level. 'Qualityjevel. These fields make it possible to identify layer levels and coding dimensions to which a considered NALU belongs.
  • the field 'Temporaljevel' allows him to indicate an image frequency.
  • the 'Qualityjevel' field indicates a progressive quantization level, and thus allows to control a bit rate against a quality level and / or a complexity level.
  • the 'layer_basejlag' field indicates a data syntax compatible with AVC encoding.
  • the elementary streams consist of AU.
  • the encoded data is packaged PES (for 'Packetized Elementary Streams').
  • PES Packetized Elementary Streams'
  • a PES packet consists of a header followed by a payload as described above.
  • TS packets also consist of a header and a payload.
  • the header of a TS packet contains in particular:
  • PID field for 'Packet Identifier'
  • a continuity index ('continuity_counter' or 'ce') to guarantee continuity of the data transmitted in the stream; and an indication field (payload_unit_start_indicator) indicating whether or not the payload contains the beginning of a PES packet.
  • the stream thus obtained corresponds to the first set of coded packets.
  • this stream obtained at the output of the multiplexer 32 is provided at the input of a transmission entity 33 according to one embodiment of the present invention.
  • This transmission entity 33 is adapted to perform step 22 and step 23 of the method according to an embodiment of the present invention.
  • this transmission entity 33 is located at a gateway in charge of receiving an MPEG-2 TS stream from the multiplexer 32 and transmitting it in the IP network to receivers 34 which they are able to to process this MPEG-2 TS over IP stream on reception.
  • a stream of multiplexed coded packets at the output of multiplexer 32 may comprise packets TS originating from the different multiplexed elementary streams and packets indicating tables containing information. necessary to be able to demultiplex this received stream.
  • the different tables present in a transport stream to allow such a demultiplexing may notably be the following:
  • PAT for 'Program Association table'
  • PMT for 'Progam Map Table'
  • an indication of the type of the elementary stream such as the type of encoding (MPEG-2 video, MPEG-2 audio, MPEG-4 AVC);
  • a PMT table also contains a field indicating the PID number of packets carrying a time reference.
  • an MPEG-2 TS stream it is possible to have packets belonging to a single program (a single pair ⁇ program number, PID number ⁇ in the PAT). In this case we speak of a SPTS (Single Program Transport Stream). It is also possible to have several programs in the same TS stream (several pairs ⁇ program number, PID number ⁇ in the PAT table). In this case the stream contains all the packets of all programs, and we are talking about a MPTS (Multiple Program Transport Stream) stream.
  • SPTS Single Program Transport Stream
  • the demultiplexing and decoding of a program consists, for each elementary component, after having identified the PID numbers of these various elementary components, to reconstruct the PES packets transported in the TS packets.
  • the PID field is then used to collect the packets of the same elementary stream in order to reconstruct this elementary stream before it is decoded.
  • the continuity counters (field 'continuity_counter') make it possible to check the integrity of the elementary stream and thus detect any packet losses.
  • the boundaries of the PES packets distributed over the different TS packets of the same PID are indicated by the field 'payload_unit_start_indicator'.
  • the AUs present in the payload of the PES packets are extracted. Then, these different AUs are decoded at times indicated in the headers of the PES packets. The AUs are finally presented at times also indicated in the headers of the PES packets. It can be predicted that for each AU supplied by an MPEG-4 SVC type encoder, the NALUs are separated according to their dependency_id layer index and encapsulated in separate PES packets but which have the same values of time stamps. These packets are subsequently encapsulated in TS packets whose PID value makes it possible to distinguish different elementary substreams from the original MPEG-4 SVC stream.
  • adaptability (or scalability) layers can be provided to be transported in separate (PID) channels to maintain compatibility with MPEG-4 AVC receivers and demultiplexers. that are not suitable for receiving MPEG-4 SVC coded data.
  • the first series of packets is again scanned from the first packet of the series that has not been selected to belong to the first group of packets.
  • the first packet of the second group of packets is an SVCi type packet having a continuity field value equal to 3.
  • the other packets selected to belong to group G2 are the next packets.
  • SVC 1 which have continuity field values that grow in the first set of packets.
  • the group G2 consists of packets SVCi which respectively have the values ce equal to 3, 4, 5, 6, 7, 8 and 9.
  • the third group of G3 packets is formed in the same way.
  • the first package is the first of the first series to have not yet been selected to belong to an already formed group.
  • this first packet of the group G3 corresponds to an SVC packet 2 with a continuity field value equal to 1.
  • the next six SVC packets 2 which have increasing continuity field values are then selected in the first set to belong to the group G3.
  • the packet group G3 consists of SVC packets 2 having continuity field values of 1, 2, 4, 5, 6, 7 and 8, respectively.
  • the transmission network comprises an IP gateway which receives an MPEG-2 TS stream and which is in charge of encapsulating it in an IP stream
  • IP IP
  • Such an IP gateway is then adapted to receive MPEG-2 TS streams and to encapsulate them in IP streams according to one embodiment of the present invention so as to obtain homogeneous IP packets in the sense of the basic and enhancement flows considered.
  • IP packets obtained according to one embodiment of the present invention No limitation is attached to the method used to thereby mark these IP packets obtained according to one embodiment of the present invention.
  • a field for classifying IP packets such as the TOS (Type of Service) field. It is also easy to predict the different types of IP packets on the basis of different respective LJDP addresses and / or on the basis of different broadcast ports.
  • IP IP.
  • IP packet payload By thus marking the IP packets that pass through the network, it is easy to implement data filtering without having to extract and analyze the different MPEG-2 TS packets contained in the IP packet payload.
  • an adaptation entity 35 which is adapted to filter the data, or packets, transmitted in the network. IP based on the types of flows to which they belong. This adaptation entity may be located at any point in the transmission network between the transmission entity and the receiver to which the flow is intended.
  • this adaptation entity is in charge of filtering TS packets according to one embodiment as a function of their membership in the different basic elementary or enhancement streams and according to various constraints and filtering criteria such as the available bandwidth, or capabilities of the terminal, or rights to access the contents of a user of the terminal.
  • an MPEG-2 TS stream transmitted according to an embodiment of the present invention can be encoded at a rate of 6 Mb / s, while the available bandwidth between the adaptation entity 35 and the final receiver 34 is only 4 Mb / s.
  • the adaptation entity 35 performs a filtering based on the type of tagging used to indicate a packet type for each IP packet of the stream in question.
  • the filtering performed at the adaptation module is based on the control of the value of this field in the IP packets of the stream. considered. It is thus possible to consider deleting all the IP packets for which the value of the TOS field is greater than that corresponding to the base stream.
  • the marking of the IP packet type is based on the LJDP protocol and more precisely on the use of certain ports respectively for the different types of packets, it is possible to filter, at the level of the adaptation module, all the LJDP packets. broadcast on port numbers greater than the one on which the base stream is broadcast, in order to transmit only LJDP packets of the base stream.
  • the marking of the IP packet type is based on the use of the SSRC fields in an RTP packet stream
  • the receiver will receive an IP stream at a rate less than the available bandwidth, containing TS packets for decoding the base stream.
  • Fig. 5 illustrates a transmission entity 33 according to an embodiment of the present invention. She understands :
  • a reception unit 52 adapted to receive from an encoder, a first series ordered according to a first order of coded packets relating to both the base stream and the upstream stream; a re-multiplexing unit 53 adapted to obtain a second series of packets coded in a second order by grouping said packets encoded by a group of N packets, by traversing in the first order the coded packets of the first set, said N packets of the same group being either all relative to the base stream or all relating to the enhancement stream, N being an integer determined according to the transmission network and the size of the coded packets; and
  • a packet obtaining unit 54 for transmitting adapted to compose packets to be transmitted according to the determined transmission protocol, said packets comprising respectively as payload groups of N successive packets of the second series of coded packets.
  • a decision unit 55 adapted to decide to adapt the transmission of the video stream according to specific criteria
  • a filtering unit 56 adapted to suppress transmitted packets grouping coded packets relating to the enhancement stream.
  • the filter unit 52 may then be based on said flow indication.

Landscapes

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

Abstract

On transmet, via un réseau de transmission par paquet selon un protocole de transmission déterminé, un flux vidéo codé de manière hiérarchique au moins sous la forme d'un flux de base et d'au moins un flux de rehaussement selon une dimension. Au niveau d'une entité de transmission, on reçoit (21 ), depuis un encodeur, une première série ordonnée selon un premier ordre de paquets codés relatifs à la fois au flux de base et au flux de rehaussement. Puis, on obtient (22) une seconde série de paquets codés selon un second ordre par regroupement desdits paquets codés par groupe de N paquets, en parcourant selon le premier ordre les paquets codés de la première série, lesdits N paquets d'un même groupe étant soit tous relatifs au flux de base soit tous relatifs au flux de rehaussement, N étant un nombre entier déterminé en fonction du réseau de transmission et de la taille des paquets codés. Ensuite, on compose (23) des paquets à transmettre selon le protocole de transmission déterminé, lesdits paquets comprenant respectivement en tant que charge utile les groupes de N paquets successifs de la seconde série de paquets codés.

Description

TRANSMISSION D'UN FLUX VIDEO CODE PAR CODAGE HIERARCHIQUE
La présente invention concerne la transmission de flux de type vidéo via un réseau de transmission IP, et plus précisément dans le cas où les flux de type vidéo sont codés selon un codage hiérarchique.
Afin d'être transmises, des données vidéo et audio sont généralement compressées selon un protocole de compression comme par exemple selon le protocole MPEG-4 AVC/H.264 (pour 'Moving Pictures Expert Group' et 'Advanced Video Coding' en anglais). Des données ainsi compressées peuvent ensuite être transmises selon le protocole MPEG-2 TS (pour Transport Stream') (ISO/IEC 13818-1 ), défini par la RFC2250, dans des paquets IP (pour 'Internet Protocol') à travers un réseau de transmission IP.
La figure 1 illustre une architecture de l'art antérieur qui permet un tel traitement de flux de données audio et vidéo.
En premier lieu, le flux de données est encodé au niveau d'un encodeur 1 1 selon le protocole MPEG-4 AVC. L'encodeur 1 1 fournit alors en sortie des paquets de type PES (pour 'Packetized Elementary Streams'). Un paquet PES comprend un champ d'en-tête et une charge utile. Le champ d'en- tête permet d'identifier un type de flux élémentaire auquel appartient le paquet correspondant. Un flux élémentaire peut être de type vidéo, ou audio, ou encore peut correspondre à un flux relatif à des sous-titres par exemple. Un ensemble de flux élémentaires forment un programme.
Les paquets PES ainsi encodés en sortie de l'encodeur sont multiplexes, au niveau d'un multiplexeur 12, selon le protocole MPEG-2 TS afin de fournir des paquets, dits paquets TS, tous de même longueur, qui peuvent aisément être encapsulés dans des paquets IP pour être transmis dans un réseau IP. Plus précisément, la norme MPEG-2 TS permet de multiplexer un ou plusieurs programmes dans un flux de données unique.
Une autre norme de compression, la norme de compression MPEG-2 SVC (pour 'Scalable Video Coding'), en cours de normalisation au sein du groupe de normalisation ISO/MPEG développée conjointement par le comité de normalisation MPEG et par l'ITU (pour 'International Télécommunication Union' en anglais), correspond à une modification de la norme MPEG-2 AVC qui permet de coder de manière hiérarchique des données vidéo.
Un tel codage MPEG-4 SVC repose sur une structure hiérarchique en couches. Ainsi, grâce à un tel codage, un flux élémentaire peut être structuré d'une part, en un flux de base qui correspond à la couche de base du codage hiérarchique, et d'autre part, en un ou plusieurs flux de rehaussement correspondant à des couches supérieures du codage hiérarchique. Une telle structure hiérarchique peut être mise en œuvre selon différentes dimensions. Il est ainsi prévu une telle structure hiérarchique dans une dimension temporelle, dans une dimension spatiale, ou encore dans une dimension de qualité.
Dans une telle structure, les données contenues dans le flux de base sont suffisantes pour reconstruire le flux vidéo/audio d'origine en réception, les données transportées dans les flux de rehaussement servant à améliorer certains aspects de ce flux de base. Ces flux de rehaussement permettent en effet d'améliorer la qualité ou encore la résolution spatiale, ou la fréquence temporelle du flux vidéo concerné mais ils restent optionnels au regard du flux de données basique permettant à lui seul le décodage et la présentation des données transportées.
Sur la base d'une telle structure hiérarchique, il est alors prévu de pouvoir adapter le flux vidéo ainsi obtenu en fonction de certaines contraintes relatives par exemple à la bande passante disponible pour transmettre un tel flux ou encore aux capacités du récepteur de flux.
Ainsi, par exemple, lorsque la bande passante est trop faible pour pouvoir transmettre le flux de base avec les flux de rehaussement correspondant, il peut être avantageux de filtrer des données de certains flux de rehaussement pour réduire la quantité de données transmises et ainsi transmettre une quantité de données adaptée à la bande passante disponible.
On peut ici prévoir de mettre en œuvre la norme MPEG-4 SVC au niveau de l'encodeur 1 1 , dans le contexte de l'architecture telle qu'illustrée à la figure 1 . Dans ce cas, des paquets PES obtenus par application de la norme MPEG-4 SVC peuvent être fournis en sortie de l'encodeur 1 1 , puis ils peuvent être regroupés dans des paquets TS selon le protocole MPEG-2 TS au niveau du multiplexeur 12, avant d'être encapsulés dans des paquets IP en vue de leur transmission dans le réseau IP.
Il convient de noter que, comme l'ordre dans lequel les paquets TS sont fournis en sortie du multiplexeur 12 n'est pas en relation avec les différentes couches de flux correspondant à la structure hiérarchisée telle que définie par la norme MPEG-4 SVC, un paquet IP regroupant des paquets TS peut comprendre à la fois des paquets TS du flux de base et des paquets TS de flux de rehaussement. De plus, des paquets TS correspondant au codage MPEG-4 SVC selon différentes dimensions peuvent également se trouver regroupés dans un même paquet IP.
Dans ces conditions, la mise en œuvre d'un filtrage quelconque pour répondre à certaines contraintes, telle que par exemple une contrainte de bande passante, peut s'avérer complexe et coûteuse. En effet, chaque paquet IP peut ici potentiellement comprendre des paquets TS de flux de rehaussement de couche et de dimension de codage quelconques. Par conséquent, afin d'effectuer un filtrage pertinent, il est alors requis d'effectuer une analyse de désencapsulation de chaque paquet IP pour y détecter potentiellement des paquets TS relatifs au flux de données de rehaussement que l'on souhaite filtrer.
La présente invention vient améliorer la situation.
Un premier aspect de la présente invention propose un procédé de transmission, via un réseau de transmission par paquet, d'un flux de paquets à transmettre à partir d'un flux codé de manière hiérarchique sous la forme d'un flux de base et d'au moins un flux de rehaussement selon une dimension ; ledit procédé de transmission comprenant les étapes suivantes :
/a/ recevoir, depuis un encodeur sous la forme d'un premier flux, une première série ordonnée selon un premier ordre de paquets codés relatifs à la fois au flux de base et au flux de rehaussement ;
IbI obtenir, sous la forme d'un second flux, une seconde série de paquets codés selon un second ordre par regroupement desdits paquets codés par groupe de N paquets, en parcourant selon le premier ordre les paquets codés de la première série, lesdits N paquets d'un même groupe étant d'un même type, soit tous relatifs au flux de base soit tous relatifs au flux de rehaussement, N étant un nombre entier déterminé en fonction du réseau de transmission et de la taille des paquets codés ; et
Ici composer des paquets à transmettre, lesdits paquets comprenant respectivement en tant que charge utile les groupes de N paquets successifs de la seconde série de paquets codés.
Grâce à ces dispositions, les paquets à transmettre sont avantageusement des paquets homogènes, c'est-à-dire des paquets qui ne contiennent que des paquets codés d'un même type. Un éventuel filtrage de flux adapté au codage hiérarchique utilisé est ensuite aisé à mettre en place. Procédé de transmission selon la revendication 1 , dans lequel la première série de paquets codés est issue d'un encodage selon un protocole de type MPEG-4 SVC suivi d'un multiplexage selon un protocole de type MPEG-2 TS, et le protocole de transmission déterminé est le protocole IP.
La première série de paquets codés peut être issue d'un encodage selon un protocole de type MPEG-4 SVC suivi d'un multiplexage selon un protocole de type MPEG-2 TS, et le protocole de transmission déterminé peut correspondre au protocole IP.
Aucune limitation n'est attachée à la présente invention au regard de la méthode appliquée pour que le type des paquets à transmettre puisse être aisément identifié au cours de leur transmission dans le réseau.
Dans un mode de réalisation de la présente invention, chaque paquet à transmettre comprend une indication du type de paquets qu'il comprend.
Dans ce cas, lorsque le procédé de transmission déterminé est le protocole IP, l'indication de flux peut correspondre au champ TOS (pour Type Of Service').
Lorsque le procédé de transmission déterminé est le protocole RTP, l'indication de flux peut correspondre à un champ parmi le champ SSRC et le champ CSRD.
On peut également prévoir que le protocole de transmission déterminé est le protocole UDP, alors les paquets à transmettre dont la charge utile est un groupe de paquets relatifs au flux de base peuvent être transmis sur une même première adresse IP et/ou un même premier port et les paquets à transmettre dont la charge utile est un groupe de paquets relatifs au flux de rehaussement peuvent être transmis sur une même seconde adresse IP et/ou un même second port.
Toutes ces méthodes permettent d'identifier très facilement directement au niveau des paquets transmis le type de paquets codés transportés sans avoir à desencapsuler les paquets transmis.
Un deuxième aspect de la présente invention propose un procédé d'adaptation de transmission, dans un réseau de transmission par paquet selon un protocole de transmission déterminé, d'un flux vidéo codé de manière hiérarchique au moins sous la forme d'un flux de base et d'au moins un flux de rehaussement selon une dimension ; chaque paquet transmis dans le réseau étant obtenu par application d'un procédé de transmission prédéfini ; ledit procédé d'adaptation comprenant les étapes suivantes au niveau d'une entité d'adaptation :
/1/ décider d'adapter la transmission du flux vidéo en fonction de critères spécifiques ; et
121 supprimer les paquets transmis regroupant des paquets codés relatifs au flux de rehaussement.
Grâce à ces dispositions, on est en mesure d'adapter facilement et efficacement un flux transmis en fonction de contraintes spécifiques directement sur la base des paquets transmis puisque ces derniers présentent une homogénéité quant à leur appartenance à un niveau de couche de codage.
Les critères spécifiques peuvent correspondre aux critères de filtrage listés ci-après.
Chaque paquet transmis peut avantageusement comprendre une indication de flux relative au flux de base ou au flux de rehaussement auquel il appartient, et l'étape 121 peut alors être mise en œuvre sur la base de ladite indication de flux.
Lorsque les paquets à transmettre dont la charge utile est un groupe de paquets relatifs au flux de base sont transmis sur une même première adresse IP et/ou un même premier port et les paquets à transmettre dont la charge utile est un groupe de paquets relatifs au flux de rehaussement sont transmis sur une même seconde adresse IP et/ou un même second port, alors l'étape 12! peut avantageusement être mise en œuvre sur la base desdit premier et second port et desdites première et seconde adresses IP.
Un troisième aspect de la présente invention propose une entité de transmission adaptée pour la mise en œuvre du procédé de transmission selon le premier aspect de la présente invention.
Un quatrième aspect de la présente invention propose une entité d'adaptation de transmission adaptée pour la mise en œuvre du procédé d'adaptation de transmission selon le deuxième aspect de la présente invention.
Un cinquième aspect de la présente invention propose un système de transmission d'un flux vidéo codé de manière hiérarchique au moins sous la forme d'un flux de base et d'au moins un flux de rehaussement selon une dimension ; comprenant une entité de transmission selon le troisième aspect de la présente invention et une entité d'adaptation selon le quatrième aspect de la présente invention.
Un sixième aspect de la présente invention propose un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de transmission selon le premier aspect de la présente invention, lorsque ce programme est exécuté par un processeur.
Un septième aspect de la présente invention propose un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d'adaptation de transmission selon le deuxième aspect de la présente invention, lorsque ce programme est exécuté par un processeur.
D'autres aspects, buts et avantages de l'invention apparaîtront à la lecture de la description d'un de ses modes de réalisation.
L'invention sera également mieux comprise à l'aide des dessins, sur lesquels : la figure 1 illustre une architecture classique d'une transmission de flux vidéo codé selon le protocole MPEG-4 AVC et transmis sur IP selon le protocole MPEG-2 TS ; la figure 2 illustre les principales étapes d'un procédé transmission d'un flux de données selon un mode de réalisation de la présente invention ; la figure 3 illustre un système de traitement d'images adapté pour la mise en œuvre d'un procédé de transmission selon un mode de réalisation de la présente invention ; la figure 4 illustre l'application d'un procédé de transmission de flux de données selon un mode de réalisation de la présente invention ; et la figure 5 illustre une entité de transmission et une entité d'adaptation de transmission selon un mode de réalisation de la présente invention.
La présente invention est décrite ci-après dans son application à la transmission selon un protocole de type MPEG-2 TS sur un réseau IP de données codées selon un codage de type MPEG-4 SVC.
Toutefois, cette description est faite à titre illustratif et ne limite en rien d'autres applications de la présente invention. Il convient de noter à cet effet qu'un mode de réalisation de la présente invention peut avantageusement être mis en œuvre dans une transmission de données codées selon un codage hiérarchique qui permet de distinguer des données de base et des données optionnelles, les données de base étant requises au minimum pour permettre un décodage des données transmises, les données optionnelles venant compléter ces données de base pour améliorer certains aspects comme la résolution spatiale, ou la résolution temporelle ou encore la qualité des données transmises décodées.
En effet, dans le contexte d'un codage hiérarchique de données, il est avantageux de mettre en œuvre un mode de réalisation de la présente invention afin de permettre une mise en œuvre simple d'un éventuel filtrage des flux transmis de données obtenues par codage hiérarchique.
La figure 2 illustre les principales étapes d'un procédé de transmission d'un flux vidéo selon un mode de réalisation de la présente invention. Ces étapes sont réalisées après le codage des données à transmettre et avant la transmission effective des données codées sur le réseau de transmission utilisé à cet effet.
Dans un exemple de réalisation, le réseau de transmission utilisé est un réseau IP et le multiplexage des données codées transmises sur IP est effectué selon le protocole MPEG-2 TS.
A une étape 21 , on reçoit une première série de paquets codés provenant d'une étape de codage selon un protocole de codage hiérarchique, comme par exemple selon le protocole MPEG-4 SVC. Un tel protocole de codage permet de coder des données selon un flux de données de base et un ou plusieurs flux de données de rehaussement, par dimension considérée, c'est-à-dire soit par qualité, soit par résolution spatiale, soit encore par résolution temporelle.
Cette série de paquets comprend de ce fait des paquets relatifs à la fois au flux de données de base et aux flux de données de rehaussement éventuels. Dans cette première série de paquets, ces paquets sont ordonnés selon un premier ordre. Ce premier ordre ne tient a priori pas compte du type de flux de données auquel appartiennent les paquets de la première série de paquets.
En effet, tel est le cas notamment dans une architecture existante de codage de données basé sur un protocole de transmission de type MPEG-2 TS. Ainsi, cette première série de paquets codés peut correspondre à ce qui est obtenu dans une architecture telle qu'illustrée en figure 1 lorsque l'encodeur applique un codage de type MPEG-4 SVC. Dans ce cas, ces paquets sont des paquets de type MPEG-2 TS.
Ainsi, à l'issue de l'étape 21 , on dispose donc d'une première série de paquets ordonnés selon un premier ordre.
A une étape /22/, on obtient une seconde série de paquets codés selon un second ordre. Cette seconde série de paquets codés est obtenue en parcourant selon le premier ordre la première série de paquets et en regroupant successivement les paquets de cette série par groupe homogène de paquets. On entend ici par les termes 'groupe homogène de paquets', un groupe de paquets qui sont tous relatifs au même type de flux de données codées. Les différents types de flux correspondent notamment à un flux de base ou encore à un flux de rehaussement d'un niveau donné, ou à un flux audio.
Ainsi, on regroupe par groupe de paquets, en parcourant dans l'ordre la première série de paquets, des paquets qui appartiennent soit au flux de données de base soit encore à un même flux de rehaussement.
Les paquets de la première série qui n'appartiennent ni à un flux de base ni à un flux de rehaussement sont associés à un flux de base et de ce fait regroupés dans des groupes de paquets de flux de base. Il en est ainsi par exemple pour les paquets de flux audio.
Lorsque le codage hiérarchique est effectué selon plusieurs dimensions, il convient de préciser qu'un groupe homogène de paquets est constitué de paquets qui proviennent tous d'un même type de flux, flux de base, y compris flux audio, ou flux de rehaussement, d'un même niveau de couche et d'un codage selon une même dimension.
On obtient alors une seconde série de paquets codés ordonnés de manière différente, dans laquelle se succèdent des groupes homogènes de N paquets codés. N est un nombre entier qui est déterminé en fonction de la taille des paquets codés de la première série de paquets et en fonction de la taille des paquets à transmettre selon le protocole de transmission déterminé.
Ensuite, à une étape 23, des paquets à transmettre sont composés à partir de la seconde série de paquets. Plus précisément, ces paquets à transmettre sont composés selon le protocole de transmission utilisé dans le réseau de transmission des flux considérés. La charge utile de chacun de ces paquets à transmettre est composée d'un groupe homogène de paquets constituant la seconde série de paquets. Successivement, on compose les paquets à transmettre avec les groupes successifs de paquets ainsi formés.
La figure 3 illustre une architecture adaptée pour la mise en œuvre d'un procédé de transmission de flux vidéo selon un mode de réalisation de la présente invention.
Cette architecture repose sur un encodeur 31 qui a en charge de coder des données audio et vidéo selon un protocole de codage hiérarchique tel que le protocole de codage MPEG-4 SVC. Puis, en sortie de l'encodeur les données sont fournies à un multiplexeur 32 de type MPEG-2 TS. Le flux MPEG-2 TS multiplexe en sortie du multiplexeur 32 contient des flux élémentaires vidéo et audio. Il est possible de régler par dimension, c'est-à- dire pour la résolution spatiale, ou la fréquence temporelle, ou encore la qualité, le nombre de couches de rehaussement ainsi que le paramétrage de ces couches au niveau de l'encodeur 31 selon la ou les applications vidéo et/ou audio et le contexte de transmission. Par exemple, on peut prévoir que pour encoder et transmettre une source vidéo au format HD, c'est-à-dire avec un niveau de résolution spatiale élevé, on encode d'une part un flux de base correspondant à un codage de type MPEG-4 AVC, c'est-à-dire avec un niveau de résolution spatiale de type SD, et on encode une couche de rehaussement avec un niveau de résolution spatiale élevé, au format HD comme la source vidéo correspondante.
Le contenu audio, lui, peut être encode dans un format de codage audio tel que le format MPEG-2 audio par exemple.
Ce multiplexeur 32 est adapté pour fournir la première série de paquets codés.
Un contenu vidéo et audio ainsi compressé selon le protocole MPEG-4 SVC peut être décodé à différents débits sur la base d'une adaptabilité (ou 'scalability' en anglais) temporelle, ou selon différentes résolutions spatiales sur la base d'une adaptabilité spatiale, ou encore selon différents niveaux de qualité sur la base d'une adaptabilité de qualité.
Dans un flux compressé MPEG-4 SVC, la couche de base pour les flux de base est compatible avec un format de codage de type MPEG-4 AVC/H.264.
Un tel flux codé est constitué d'une suite d'unités d'accès ou AU (pour 'Access Units' en anglais), chacune correspondant à des données compressées relatives à une image de la séquence vidéo à un instant donné. Une AU est découpée en une ou plusieurs NALU (pour 'Network Abstraction Layer Units' en anglais) pour une gestion de la transmission par paquet sur le réseau de transmission facilitant ainsi les mécanismes de transport sur ce réseau. Les NALU peuvent être de type 'donnée', référencées VCL (pour 'Video Coding Layer' en anglais) ou de type 'signalisation', notamment référencées SEI (pour 'Supplemental Enhancement Information' en anglais), SPS (pour 'Séquence Parameter Set' en anglais), ou PPS (pour 'Picture Parameter Set' en anglais). Chaque NALU de données correspond donc à une partie d'image.
Un en-tête de NALU selon le protocole MPEG-4 SVC est constitué d'octets qui contiennent notamment de champs indiquant un niveau de priorité 'Priorityjd', un niveau de dépendance 'Dependencyjd', une référence temporelle Temporaljevel', un niveau de qualité 'Qualityjevel'. Ces champs permettent d'identifier des niveaux de couche et des dimensions de codage auxquels appartient une NALU considérée.
Plus précisément, le champ Oependency_id', qui peut prendre une valeur comprise entre 0 à 7, permet de connaître le niveau de résolution spatiale d'un niveau hiérarchique de codage. Ce niveau peut aussi permettre de contrôler la qualité relative au rapport de signal sur bruit, ou SNR (pour 'Signal Noise Ratio' en anglais) ou l'adaptation temporelle dans le cadre d'un codage en couche (i.e. pour un nombre de points de fonctionnement discret).
Le champ 'Temporaljevel' permet, lui, d'indiquer une fréquence d'image. Le champ 'Qualityjevel' indique un niveau de quantification progressive, et, de ce fait, permet de contrôler un niveau de débit par rapport à un niveau de qualité et/ou un niveau de complexité.
Le champ 'layer_basejlag' indique une syntaxe de données compatible avec un codage de type AVC.
Comme énoncé ci-avant, en sortie d'encodage les flux élémentaires sont constitués d'AU. Puis, les données encodées sont mises en paquet PES (pour 'Packetized Elementary Streams'). Un paquet PES est constitué d'un entête suivi d'une charge utile comme décrit ci-avant.
Puis, les paquets PES de taille variable sont regroupés dans des paquets TS de longueur fixe. Ces paquets TS des différents médias sont ensuite multiplexer et synchroniser dans un flux unique. Les paquets TS sont eux aussi constitués d'un en-tête et d'une charge utile. L'en-tête d'un paquet TS contient notamment:
- un champ PID (pour 'Packet Identifier') permettant d'identifier le contenu des données présentes dans la charge utile du paquet, une même valeur de PID étant attribuée à des paquets transportant des données issues d'un seul et même flux élémentaire ;
- un indice de continuité ('continuity_counter' ou 'ce') permettant de garantir une continuité des données transmises dans le flux ; et un champ d'indication (payload_unit_start_indicator) indiquant si la charge utile contient ou non le début d'un paquet PES. Le flux ainsi obtenu correspond donc à la première série de paquets codés.
Puis, ce flux obtenu en sortie du multiplexeur 32 est fourni en entrée d'une entité de transmission 33 selon un mode de réalisation de la présente invention.
Cette entité de transmission 33 est adaptée pour effectuée l'étape 22 et l'étape 23 du procédé selon un mode de réalisation de la présente invention.
On peut prévoir que cette entité de transmission 33 soit située au niveau d'une passerelle en charge de recevoir un flux MPEG-2 TS depuis le multiplexeur 32 et de le transmettre dans le réseau IP jusqu'à des récepteurs 34 qui eux sont en mesure de traiter ce flux MPEG-2 TS sur IP en réception.
Un flux de paquets codés multiplexes en sortie du multiplexeur 32, c'est-à-dire un flux correspondant à la première série de paquets codés, peut comprendre des paquets TS issus des différents flux élémentaires multiplexes et des paquets indiquant des tables contenant des informations nécessaires pour pouvoir démultiplexer ce flux reçu. Les différentes tables présentes dans un flux de transport pour permettre un tel démultiplexage peuvent notamment être les suivantes:
- une table d'association de programme, ou PAT (pour 'Program Association table') contenant, pour chaque programme inclus dans le flux multiplexe considéré, un numéro de programme ainsi que le numéro de PID des paquets transportant le contenu d'une table de correspondance de programme décrivant le programme, ces tables PAT étant en général transportées dans les paquets ayant la valeur de PID égale à ; ou - une table de correspondance de programme, ou PMT (pour 'Progam Map Table') contenant pour un programme donné et pour chaque composante élémentaire contenue dans le programme:
• une indication de type du flux élémentaire, comme le type de codage (MPEG-2 vidéo, MPEG-2 audio, MPEG-4 AVC) ;
• le numéro de PID des paquets transportant les données du flux élémentaire ; et
• des données optionnelles de description donnant des informations supplémentaires sur les flux élémentaires.
Une table PMT contient également un champ indiquant le numéro de PID des paquets transportant une référence temporelle.
Dans un flux MPEG-2 TS, il est possible d'avoir des paquets appartenant à un seul et unique programme (un seul couple {numéro de programme, numéro de PID} dans la table PAT). Dans ce cas on parle d'un SPTS (Single Program Transport Stream). Il est également possible d'avoir plusieurs programmes dans un même flux TS (plusieurs couples {numéro de programme, numéro de PID} dans la table PAT). Dans ce cas le flux contient tous les paquets de tous les programmes, et on parle d'un flux MPTS (Multiple Program Transport Stream).
Le démultiplexage et décodage d'un programme consiste, pour chaque composante élémentaire, après avoir identifié les numéros de PID de ces différentes composantes élémentaires, à reconstituer les paquets PES transportés dans les paquets TS. Le champ PID est alors utilisé pour collecter les paquets d'un même flux élémentaire afin de reconstruire ce flux élémentaire avant son décodage. Les compteurs de continuité (champ 'continuity_counter') permettent de s'assurer de l'intégrité du flux élémentaire et d'ainsi détecter les éventuelles pertes de paquets. Les frontières des paquets PES répartis sur les différents paquets TS d'un même PID sont indiquées par le champ 'payload_unit_start_indicator'.
Puis, les AUs présentes dans la charge utile des paquets PES sont extraites. Ensuite, on décode ces différentes AUs à des instants indiqués dans les en-têtes des paquets PES. Les AUs sont enfin présentées à des instants également indiqués dans les en-têtes des paquets PES. On peut prévoir que pour chaque AU fournie par un encodeur de type MPEG-4 SVC, les NALU sont séparées selon leur indice de couche 'dependency_id' et encapsulés dans des paquets PES distincts mais qui ont les même valeurs d'estampilles temporelles. Ces paquets sont par la suite encapsulés dans des paquets TS dont la valeur de PID permet de distinguer différents sous-flux élémentaires issus du flux MPEG-4 SVC d'origine.
Dans un mode de réalisation de la présente invention, on peut prévoir que les couches d'adaptabilité (ou de 'scalabilité') soient transportées dans des voies (PID) distinctes afin de conserver une compatibilité avec les récepteurs et les démultiplexeurs MPEG-4 AVC qui ne sont pas adaptés à la réception de données codées selon MPEG-4 SVC.
On peut également prévoir de transporter des couches d'adaptabilité différentes dans des voies PID distinctes afin de faciliter le filtrage des couches de rehaussement qui peut alors être aisément basé sur un filtrage des flux élémentaires par contrôle du numéro de voie (PID) dans l'en-tête des paquets TS.
Dans un flux MPEG-2 TS sur IP tel que spécifié par I1I ETF dans la RFC2250 (RTP Payload Format MPEG1 /MPEG2 Video), la charge utile d'un paquet RTP correspond à un nombre entier de paquets TS. Le nombre de paquets TS est déterminé par la taille maximale d'une trame IP selon le type de réseau utilisé au-delà de laquelle un paquet IP est fragmenté par des équipements du réseau au cours de transmission, augmentant ainsi le risque des perdre des données plus importantes. Par exemple, pour un réseau de type Ethernet, le nombre de paquets TS inclus dans un paquet RTP peut être égal à 7.
La figure 4 illustre un procédé de transmission de flux de données selon un mode de réalisation de la présente invention appliqué à une première série de paquets codés selon MPEG-4 SVC et multiplexes selon MPEG-2 TS pour obtenir une seconde série de paquets adaptés pour une transmission sur un réseau IP, de type Ethernet.
Dans l'exemple illustré, les données sont codées selon un flux de base, dont les paquets sont référencés 'AVC, et des premier et second flux de rehaussement, dont les paquets sont référencés respectivement 'SVCi' et 'SVC2', selon une seule dimension qui peut donc être temporelle, spatiale ou encore de qualité. Toutefois, il convient de noter qu'il est aisé d'étendre cet exemple illustré à des données codées selon un flux de base et un nombre entier quelconque de flux de rehaussement par dimension, selon une pluralité de dimensions, comme cela est possible par application d'un codage de type MPEG-4 SVC.
Comme illustrée à la figure 5, une première série de paquets TS 41 comprend un premier type de paquets TS appartenant à un flux de base, un deuxième type de paquets TS appartenant à un premier flux de rehaussement et un troisième type de paquets TS appartenant à un second flux de rehaussement. Le premier type de paquets TS peut correspondre soit à une table d'association de programme (ou PAT) ou une table de correspondance de programmes (PMT), soit encore à des paquets référencés AVC puisque le codage MPEG-4 AVC correspond au codage MPEG-4 SVC pour le flux de base, soit également aux paquets issus du flux de type audio, référencés A.
Le deuxième type de paquets TS correspond aux paquets référencés SVCi et le troisième type de paquets TS correspond aux paquets référencés SVC2.
Par application d'un procédé de transmission selon un mode de réalisation de la présente invention à cette première série de paquets TS, on obtient une seconde série de paquets codés 52.
L'exemple illustré correspond à une transmission des données dans des paquets RTP. Par conséquent le nombre N, comme défini précédemment, est égal à 7. Ainsi, on parcourt les paquets TS de la première série de paquets codés et, au fil de ce parcours, on réordonne ces paquets selon un autre ordre qui permet d'obtenir des groupes de N paquets codés successifs homogènes, c'est-à-dire des groupes de paquets comprenant chacun des paquets codés issus du même type de flux selon la même dimension.
Ainsi, pour former un premier groupe de 7 paquets G1 , on parcourt les paquets de la première série. Le premier paquet TS est un paquet PAT du premier type de paquet. Par conséquent, le groupe G1 est un groupe de paquets appartenant au flux de base et de manière plus générale, de paquets n'appartenant à aucun flux de rehaussement, comme par exemple des paquets d'un flux audio. Ainsi le premier groupe de paquets G1 est complété par tous les paquets du premier type qui suivent le paquet PAT dans la première série de paquets TS 41 .
En outre, dans cet exemple, les différents groupes de paquets sont formés en prenant en compte la valeur du champ de continuité ce indiquée dans chaque paquet TS de la première série de paquets. Cette valeur de champ est utilisée afin de pouvoir regrouper des paquets TS qui sont non seulement issus du même type de flux, mais également qui se suivent.
Ainsi, G1 comprend en outre un paquet AVC avec une valeur de champ de continuité égale à 5. Puis, les paquets SVCi et SVC2 qui suivent ce paquet AVC ne sont pas sélectionnés pour faire partie de ce groupe G1 puisqu'ils ne sont pas du même type de paquet.
Un paquet AVC ayant une valeur de champ de continuité égale à 6 est ensuite sélectionné pour appartenir au groupe G1 . Puis, un paquet PMT ayant une valeur de champ de continuité égale à 0, un paquet A issu d'un flux de type audio ayant une valeur de champ de continuité égale à 13, un paquet AVC ayant une valeur de champ de continuité égale à 7, et enfin un paquet AVC ayant une valeur de champ de continuité égale à 8 sont enfin sélectionnés pour faire partie de groupe de 7 paquets G1 .
Puis, pour former le deuxième groupe de paquets G2, on parcourt à nouveau la première série de paquets à partir du premier paquet de la série qui n'a pas été sélectionné pour appartenir au premier groupe de paquets. Dans l'exemple illustré à la figure 5, le premier paquet du deuxième groupe de paquets est un paquet de type SVCi ayant une valeur de champ de continuité égale à 3. Puis, les autres paquets sélectionnés pour appartenir au groupe G2 sont les prochains paquets SVC1 qui ont des valeurs de champ de continuité qui croissent dans la première série de paquets. Ainsi, le groupe G2 est constitué des paquets SVCi qui ont respectivement les valeurs ce égales à 3, 4, 5, 6, 7, 8 et 9.
Le troisième groupe de paquets G3 est formé de la même manière. Le premier paquet est le premier de la première série à ne pas encore avoir été sélectionné pour appartenir à un groupe déjà formé. Ici, ce premier paquet du groupe G3 correspond à un paquet SVC2 avec une valeur de champ de continuité égale à 1 . Puis, les six prochains paquets SVC2 qui ont des valeurs de champs de continuité croissantes sont ensuite sélectionnés dans la première série pour appartenir au groupe G3. Ainsi, le groupe de paquets G3 est constitué des paquets SVC2 ayant des valeurs de champ de continuité respectivement égales à 1 , 2, 4, 5, 6, 7 et 8.
Aucune limitation n'est attachée à la mise en œuvre d'un tel procédé de transmission visant à re-multiplexer les paquets TS après leur traitement par un encodeur de type MPEG-2 TS.
On peut notamment envisager de mettre en œuvre ce re-multiplexage directement au niveau de la sortie du multiplexeur MPEG-2 TS.
Lorsque le réseau de transmission comprend une passerelle IP qui reçoit un flux MPEG-2 TS et qui est en charge de l'encapsuler dans un flux IP, il peut être avantageux de prévoir de mettre en œuvre ce re-multiplexage au sein de cette passerelle IP. Une telle passerelle IP est alors adaptée pour recevoir des flux MPEG-2 TS et pour les encapsuler dans des flux IP selon un mode de réalisation de la présente invention de façon à obtenir des paquets IP homogènes au sens des flux de base et de rehaussement considérés.
On obtient donc des paquets IP dont la charge utile est constituée d'un groupe de paquets homogènes selon un mode de réalisation de la présente invention. On obtient ici un premier paquet IP (RTP) 43 qui a pour charge utile le premier groupe de paquets, un deuxième paquet IP (RTP) 44 qui a pour charge utile le deuxième groupe de paquets, et un troisième paquet IP (RTP) 45 qui a pour charge utile le troisième groupe de paquets
On peut avantageusement prévoir d'indiquer dans l'en-tête de chaque paquet IP à quelle couche de codage il appartient. Une telle indication permet par la suite de mettre en place de manière simple un filtrage sur le type de flux SVC.
Aucune limitation n'est attachée à la méthode utilisée pour marquer ainsi ces paquets IP obtenus selon un mode de réalisation de la présente invention. A cet effet, on peut notamment prévoir d'utiliser un champ permettant la classification de paquets IP, comme le champ TOS (pour Type Of Service' en anglais). On peut également aisément prévoir de distinguer les différents types paquets IP sur la base de différentes adresse LJDP respectives et/ou sur la base de différents ports de diffusion. Ainsi, tous les paquets IP d'un même type peuvent être transmis à destination d'une même adresse IP et/ou d'un même port IP, cette même adresse IP et/ou ce même port IP étant différent selon le type de paquets IP.
Il est également facile de prévoir d'indiquer pour chaque paquet IP à quel type il appartient en utilisant un champ présent dans l'en-tête des paquets RTP, tels les champs SSRC ou CSRC.
En marquant ainsi les paquets IP qui transitent dans le réseau, on peut aisément mettre en œuvre un filtrage des données sans avoir à extraire et à analyser les différents paquets MPEG-2 TS contenus dans la charge utile des paquets IP.
Afin de pouvoir adapter le flux de données transmission par l'entité de transmission selon un mode de réalisation de la présente invention, il convient de prévoir une entité d'adaptation 35 qui est adaptée pour filtrer les données, ou paquets, transmises dans le réseau IP sur la base des types de flux auxquels ils appartiennent. Cette entité d'adaptation peut être localisée à un quelconque endroit dans le réseau de transmission entre l'entité de transmission et le récepteur auquel le flux est destiné.
Plus précisément, cette entité d'adaptation est en charge de filtrer des paquets TS selon un mode de réalisation en fonction de leur appartenance aux différents flux élémentaires de base ou de rehaussement et selon différentes contraintes et critères de filtrage tels que la bande passante disponible, ou des capacités du terminal, ou encore des droits d'accès aux contenus d'un utilisateur du terminal.
Ainsi, par exemple, un flux de type MPEG-2 TS transmis selon un mode de réalisation de la présente invention peut être encodé à un débit de 6 Mb/s, alors que la bande passante disponible entre l'entité d'adaptation 35 et le récepteur final 34 n'est que de 4 Mb/s. Dans ce cas, on prévoit, au niveau de l'entité d'adaptation 35 de filtrer le flux considéré de façon à supprimer des paquets TS appartenant au flux de rehaussement qui correspond par exemple au contenu de résolution spatial de niveau élevé et de n'envoyer que les paquets TS permettant de reconstituer et décoder le flux de base correspondant au contenu de résolution de niveau basique, encodé à un débit inférieur de 4 Mb/s.
L'entité d'adaptation 35 effectue un filtrage sur la base du type de marquage utilisé pour indiquer un type de paquet pour chaque paquet IP du flux considéré.
Ainsi, lorsque le marquage du type de paquet IP est basé sur l'utilisation du champ TOS dans les paquets IP, le filtrage effectué au niveau du module d'adaptation repose sur le contrôle de la valeur de ce champ dans les paquets IP du flux considéré. On peut ainsi envisager de supprimer tous les paquets IP pour lesquels la valeur du champ TOS est supérieure à celle qui correspond au flux de base.
Lorsque le marquage du type de paquet I P est basé sur le protocole LJDP et plus précisément sur l'utilisation de certains ports respectivement pour les différents types de paquets, on peut envisage de filtrer, au niveau du module d'adaptation, tous les paquets LJDP diffusés sur des numéros de port supérieur à celui sur lequel est diffusé le flux de base, afin de ne transmettre que les paquets LJDP du flux de base.
Dans le cas où le marquage du type de paquets IP repose sur l'utilisation des champs SSRC dans un flux de paquets RTP, on peut prévoir, au niveau du module d'adaptation, de filtrer le flux MPEG-2 TS en supprimant tous les paquets RTP ayant une valeur de champ SSRC supérieur à celle contenue dans les paquets RTP du flux de base.
Ainsi, le récepteur ne recevra qu'un flux IP à un débit inférieur à la bande passante disponible, contenant les paquets TS permettant de décoder le flux de base.
La figure 5 illustre une entité de transmission 33 selon un mode de réalisation de la présente invention. Elle comprend :
- une unité de réception 52 adaptée pour recevoir depuis un encodeur, une première série ordonnée selon un premier ordre de paquets codés relatifs à la fois au flux de base et au flux de rehaussement ; - une unité de re-multiplexage 53 adaptée pour obtenir une seconde série de paquets codés selon un second ordre par regroupement desdits paquets codés par groupe de N paquets, en parcourant selon le premier ordre les paquets codés de la première série, lesdits N paquets d'un même groupe étant soit tous relatifs au flux de base soit tous relatifs au flux de rehaussement, N étant un nombre entier déterminé en fonction du réseau de transmission et de la taille des paquets codés ; et
- une unité d'obtention 54 de paquets à transmettre adaptée pour composer des paquets à transmettre selon le protocole de transmission déterminé, lesdits paquets comprenant respectivement en tant que charge utile les groupes de N paquets successifs de la seconde série de paquets codés.
La figure 5 illustre également une entité d'adaptation de transmission 35 selon un mode de réalisation de la présente invention. Elle comprend :
-une unité de décision 55 adaptée pour décider d'adapter la transmission du flux vidéo en fonction de critères spécifiques ; et
-une unité de filtrage 56 adaptée pour supprimer les paquets transmis regroupant des paquets codés relatifs au flux de rehaussement.
Lorsque chaque paquet transmis comprend une indication de flux relative au flux de base ou au flux de rehaussement auquel il appartient, l'unité de filtrage 52 peut alors se baser sur ladite indication de flux.
Puis, lorsque les paquets à transmettre dont la charge utile est un groupe de paquets relatifs au flux de base sont transmis sur une même première adresse IP et/ou un même premier port et les paquets à transmettre dont la charge utile est un groupe de paquets relatifs au flux de rehaussement sont transmis sur une même seconde adresse IP et/ou un même second port, l'unité de filtrage 52 peut alors se baser sur lesdits premier et second ports et lesdites première et seconde adresses IP.

Claims

REVENDICATIONS
1 . Procédé de transmission, via un réseau de transmission (IP) par paquet, d'un flux de paquets à transmettre à partir d'un flux codé de manière hiérarchique sous la forme d'un flux de base et d'au moins un flux de rehaussement selon une dimension ; ledit procédé de transmission comprenant les étapes suivantes :
/a/ recevoir, depuis un encodeur sous la forme d'un premier flux, une première série ordonnée selon un premier ordre de paquets codés relatifs à la fois au flux de base et au flux de rehaussement ;
/b/ obtenir, sous la forme d'un second flux, une seconde série de paquets codés selon un second ordre par regroupement desdits paquets codés par groupe de N paquets, en parcourant selon le premier ordre les paquets codés de la première série, lesdits N paquets d'un même groupe étant d'un même type, soit tous relatifs au flux de base soit tous relatifs au flux de rehaussement, N étant un nombre entier déterminé en fonction du réseau de transmission et de la taille des paquets codés ; et
Ici composer des paquets à transmettre, lesdits paquets comprenant respectivement en tant que charge utile les groupes de N paquets successifs de la seconde série de paquets codés.
2. Procédé de transmission selon la revendication 1 , dans lequel le premier flux est obtenu par application d'un multiplexage de type MPEG-2 TS.
3. Procédé de transmission selon la revendication 1 , dans lequel chaque paquet à transmettre comprend une indication du type de paquets qu'il comprend.
4. Procédé de transmission selon la revendication 1 , dans lequel le réseau de transmission est basé sur le protocole UDP, et dans lequel les paquets à transmettre regroupant des paquets d'un même type sont transmis sur une même adresse IP et/ou un même port.
5. Procédé d'adaptation de transmission, via un réseau de transmission (IP) par paquet, d'un flux de paquets à transmettre, ledit flux étant relatif à des types différents ; chaque paquet transmis dans le réseau étant obtenu par application d'un procédé de transmission selon la revendication 1 ; ledit procédé d'adaptation comprenant les étapes suivantes :
/1/ décider d'adapter la transmission du flux vidéo en fonction de critères spécifiques ; et
121 supprimer les paquets transmis d'au moins un type déterminé.
6. Procédé d'adaptation de transmission selon la revendication 5, dans lequel chaque paquet transmis inclus une indication du type de paquets qu'il comprend ; et dans lequel l'étape /2/ est mise en œuvre sur la base de ladite indication du type de paquets.
7. Procédé d'adaptation de transmission selon la revendication 5, dans lequel les paquets à transmettre regroupant des paquets relatifs à un même type sont transmis sur une même adresse IP et/ou un même port, et dans lequel l'étape 121 est mise en œuvre sur la base de l'adresse et/ou du port des paquets transmis.
8. Entité de transmission (33) adaptée pour la mise en œuvre d'un procédé de transmission selon la revendication 1 .
9. Entité d'adaptation (35) de transmission adaptée pour la mise en œuvre d'un procédé d'adaptation de transmission selon la revendication 5.
10. Entité d'adaptation (35) selon la revendication 9, dans laquelle, chaque paquet transmis comprenant une indication du type de paquets, l'unité de filtrage (56) se base sur ladite indication.
1 1 . Entité d'adaptation (35) selon la revendication 9, dans laquelle, les paquets à transmettre regroupant des paquets relatifs à un même type sont transmis sur une même adresse IP et/ou un même port, l'unité de filtrage (56) se base sur l'adresse et/ou le port des paquets transmis.
12. Système de transmission d'un flux de paquets via un réseau de transmission; comprenant une entité de transmission selon la revendication 8 et une entité d'adaptation selon la revendication 9.
13. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de transmission selon la revendication 1 , lorsque ce programme est exécuté par un processeur.
14. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d'adaptation de transmission selon la revendication 5, lorsque ce programme est exécuté par un processeur.
EP09745975A 2008-04-29 2009-04-21 Transmission d'un flux video code par codage hierarchique Ceased EP2281395A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0852902 2008-04-29
PCT/FR2009/050742 WO2009138656A2 (fr) 2008-04-29 2009-04-21 Transmission d'un flux video code par codage hierarchique

Publications (1)

Publication Number Publication Date
EP2281395A2 true EP2281395A2 (fr) 2011-02-09

Family

ID=40010475

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09745975A Ceased EP2281395A2 (fr) 2008-04-29 2009-04-21 Transmission d'un flux video code par codage hierarchique

Country Status (3)

Country Link
US (1) US20110038386A1 (fr)
EP (1) EP2281395A2 (fr)
WO (1) WO2009138656A2 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IT1398195B1 (it) * 2009-06-25 2013-02-14 St Microelectronics Srl "procedimento e sistema per la distribuzione di contenuti informativi, relativo prodotto informatico"
US9386063B2 (en) * 2011-09-19 2016-07-05 Comcast Cable Communications, Llc Content storage and identification
US9848217B2 (en) * 2012-01-20 2017-12-19 Korea Electronics Technology Institute Method for transmitting and receiving program configuration information for scalable ultra high definition video service in hybrid transmission environment, and method and apparatus for effectively transmitting scalar layer information
US20130318251A1 (en) * 2012-05-22 2013-11-28 Alimuddin Mohammad Adaptive multipath content streaming
WO2017190329A1 (fr) * 2016-05-05 2017-11-09 华为技术有限公司 Procédé et dispositif de transmission de service de vidéo
US10153917B1 (en) 2017-07-21 2018-12-11 Huawei Technologies Co., Ltd. Frequency/phase-shift-keying for back-channel serdes communication
US10484044B1 (en) 2018-05-01 2019-11-19 Huawei Technologies Co., Ltd. Differential termination modulation for back-channel communication
CN115883011B (zh) * 2021-09-30 2025-09-02 中国石油化工股份有限公司 一种基于北斗卫星的油气录井数据传输方法及发送端

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3193947B2 (ja) * 1997-01-08 2001-07-30 株式会社ディジタル・ビジョン・ラボラトリーズ データ送信システム及びデータ送信方法
US6148005A (en) * 1997-10-09 2000-11-14 Lucent Technologies Inc Layered video multicast transmission system with retransmission-based error recovery
JP2000078573A (ja) * 1998-09-03 2000-03-14 Hitachi Ltd 階層符号化データ配信装置
JP3766259B2 (ja) * 2000-06-01 2006-04-12 株式会社日立製作所 パケット転送装置
US20050021806A1 (en) * 2001-12-15 2005-01-27 Richardson John William System and method for delivering data streams of multiple data types at diffferent priority levels
US20080310451A1 (en) * 2005-12-23 2008-12-18 Koninklijke Philips Electronics N.V. Splitting of a Data Stream
KR101029854B1 (ko) * 2006-01-11 2011-04-15 노키아 코포레이션 스케일러블 비디오 코딩에서 픽쳐들의 역방향-호환 집합

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2009138656A2 *

Also Published As

Publication number Publication date
WO2009138656A2 (fr) 2009-11-19
WO2009138656A3 (fr) 2010-01-07
US20110038386A1 (en) 2011-02-17

Similar Documents

Publication Publication Date Title
EP2281395A2 (fr) Transmission d'un flux video code par codage hierarchique
AU2009211932B2 (en) Method and device for reordering and multiplexing multimedia packets from multimedia streams pertaining to interrelated sessions
US9253240B2 (en) Providing sequence data sets for streaming video data
JP6649404B2 (ja) 画像コーディング・デコーディングのための装置、方法およびコンピュータ・プログラム
US9485546B2 (en) Signaling video samples for trick mode video representations
FR2864869A1 (fr) Methode de transmission de services numeriques sur un reseau et appareil mettant en oeuvre la methode
KR20080092420A (ko) 스케일러블 비디오 코딩에서 픽쳐들의 역방향-호환 집합
KR101421390B1 (ko) 트릭 모드 비디오 표현물에 대한 비디오 샘플의 시그널링
JP2009105970A (ja) 漸進的デコーダリフレッシュに基づくストリーム切り換え
CN103283248A (zh) 具有开环统计复用器的svc至avc重写器
EP2052545B1 (fr) Dispositif et procede de codage et de decodage echelonnables de flux de donnees d'images, signal et programme d'ordinateur correspondants
CN105960804B (zh) 用于提供特技播放服务的信号发送、接收方法及装置
FR2932050A1 (fr) Procede et dispositif de transmission de donnees video
EP2410749A1 (fr) Procédé d'encodage adaptatif d'un flux vidéo numérique, notamment pour diffusion sur ligne xDSL
FR2888424A1 (fr) Dispositif et procede de codage et de decodage de donnees video et train de donnees
FR2889017A1 (fr) Procedes de filtrage, de transmission et de reception de flux video scalables, signal, programmes, serveur, noeud intermediaire et terminal correspondants
EP4602807A1 (fr) Appareil et procédé d'intégration d'informations d'amélioration supplémentaires post-filtre de réseau de neurones avec un format de fichier multimédia de base iso
FR2923970A1 (fr) Procede et dispositif de formation, de transfert et de reception de paquets de transport encapsulant des donnees representatives d'une sequence d'images
FR2911235A1 (fr) Procedes et dispositifs de decodage et de codage d'un flux de donnees scalable,produits programmes d'ordinateur, support de donnees et signal correspondants
EP2297961A2 (fr) Carte electronique de compression/decompression d'un signal video, procede et modificateur de taux de compression utilisant cette carte

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

AK Designated contracting states

Kind code of ref document: A2

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

AX Request for extension of the european patent

Extension state: AL BA RS

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20130405

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

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