FR2889017A1 - Procedes de filtrage, de transmission et de reception de flux video scalables, signal, programmes, serveur, noeud intermediaire et terminal correspondants - Google Patents
Procedes de filtrage, de transmission et de reception de flux video scalables, signal, programmes, serveur, noeud intermediaire et terminal correspondants Download PDFInfo
- Publication number
- FR2889017A1 FR2889017A1 FR0507690A FR0507690A FR2889017A1 FR 2889017 A1 FR2889017 A1 FR 2889017A1 FR 0507690 A FR0507690 A FR 0507690A FR 0507690 A FR0507690 A FR 0507690A FR 2889017 A1 FR2889017 A1 FR 2889017A1
- Authority
- FR
- France
- Prior art keywords
- data
- filtering
- data units
- video stream
- paths
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000001914 filtration Methods 0.000 title claims abstract description 56
- 238000000034 method Methods 0.000 title claims abstract description 46
- 230000002123 temporal effect Effects 0.000 claims abstract description 29
- 230000005540 biological transmission Effects 0.000 claims description 25
- 238000012545 processing Methods 0.000 claims description 19
- 238000004590 computer program Methods 0.000 claims description 11
- 238000004891 communication Methods 0.000 claims description 4
- 238000001514 detection method Methods 0.000 claims description 2
- 238000000926 separation method Methods 0.000 claims 1
- 230000006978 adaptation Effects 0.000 description 18
- 238000004422 calculation algorithm Methods 0.000 description 7
- 230000033001 locomotion Effects 0.000 description 7
- 230000008569 process Effects 0.000 description 6
- 230000011664 signaling Effects 0.000 description 5
- 238000013459 approach Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 4
- 101150012579 ADSL gene Proteins 0.000 description 3
- 102100020775 Adenylosuccinate lyase Human genes 0.000 description 3
- 108700040193 Adenylosuccinate lyases Proteins 0.000 description 3
- 230000009471 action Effects 0.000 description 3
- 238000011084 recovery Methods 0.000 description 3
- 230000009467 reduction Effects 0.000 description 3
- 101100286668 Mus musculus Irak1bp1 gene Proteins 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000000750 progressive effect Effects 0.000 description 2
- 108050005509 3D domains Proteins 0.000 description 1
- 241000763212 Lype Species 0.000 description 1
- 230000002547 anomalous effect Effects 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000001427 coherent effect Effects 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 239000012530 fluid Substances 0.000 description 1
- PCHJSUWPFVWCPO-UHFFFAOYSA-N gold Chemical compound [Au] PCHJSUWPFVWCPO-UHFFFAOYSA-N 0.000 description 1
- 239000010931 gold Substances 0.000 description 1
- 229910052737 gold Inorganic materials 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
- H04N21/234381—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the temporal resolution, e.g. decreasing the frame rate by frame skipping
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
- H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
- H04N21/234354—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering signal-to-noise ratio parameters, e.g. requantization
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
- H04N21/234363—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the spatial resolution, e.g. for clients with a lower screen resolution
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
- H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4621—Controlling the complexity of the content stream or additional data, e.g. lowering the resolution or bit-rate of the video stream for a mobile client with a small screen
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
- H04N21/64784—Data processing by the network
- H04N21/64792—Controlling the complexity of the content stream, e.g. by dropping packets
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
L'invention concerne un procédé de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, comprenant une étape de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
Description
Procédés de filtrage, de transmission et de réception de flux vidéo
scalables, programmes, serveur, noeud intermédiaire et terminal correspondants.
1. domaine de l'invention Le domaine de l'invention est celui du traitement de signaux vidéo, et plus particulièrement de séquences vidéo compressées sous forme échelonnable, ou scalable. Plus précisément, l'invention concerne l'amélioration de l'exploitation d'un flux scalable, notamment, mais non exclusivement, dans le cadre du schéma de codage actuellement développé dans MPEG4-SVC.
Cette technique MPEG4-SVC est notamment présentée dans les documents: JSVM 2.0: Joint Video Team (JVT) of ISO/IEC MPEG & ITU-T VCEG, N7084, Joint Scalable Video Model (JSVM) 2.0 Reference Encoding Algorithm Description, April 2005, Busan (Julien Reichel, Heiko Schwarz, Mathias Wien) ; et - WD: J. Reichel, H. Schwarz, M. Wien Scalable Video Coding Working Draft 2 ISO/IEC JTC1/SC29/WG11, W7084, April 2005, Busan.
2. art antérieur 2.1 les systèmes vidéo scalables (échelonnables) Actuellement, la plupart des codeurs vidéo génèrent un seul flux compressé correspondant à l'intégralité d'une séquence codée. Chaque client souhaitant exploiter le fichier compressé pour décodage et visualisation doit pour cela télécharger (ou streamer ) le fichier compressé complet.
Or, dans un système hétérogène (par exemple Internet), tous les clients ne disposent pas du même type d'accès aux données: la bande passante, les capacités de traitement, les écrans des différents clients peuvent être très différents (par exemple, sur un réseau Internet, l'un des clients pourra disposer d'un débit ADSL à 1024 kb/s et d'un micro-ordinateur (PC) puissant alors que l'autre ne bénéficiera que d'un accès modem et d'un PDA).
Une solution évidente à ce problème consiste à générer plusieurs flux compressés correspondant à différents débits/résolutions de la séquence vidéo: c'est le simulcast. Cette solution est cependant sous-optimale en termes d'efficacité, et suppose de connaître à l'avance les caractéristiques de tous les clients potentiels.
Plus récemment sont apparus des algorithmes de codage vidéo dit scalables (ou échelonnables), c'est-à-dire à qualité adaptable et résolution spatiotemporelle variable, pour lesquels le codeur génère un flux compressé en plusieurs couches, chacune de ses couches étant emboîtée dans la couche de niveau supérieur. Ces algorithmes sont aujourd'hui en cours d'adoption en amendement de MPEG4-AVC (appelé dans la suite de ce document: SVC).
De tels codeurs sont très utiles pour toutes les applications pour lesquelles la génération d'un seul flux compressé, organisé en plusieurs couches de scalabilité, peut servir à plusieurs clients de caractéristiques différentes, par
exemple:
- service de vidéo à la demande, ou VOD (terminaux cibles: UMTS, PC ADSL, TV ADSL...) ; - mobilité de session (reprise sur un PDA d'une session vidéo commencée sur TV; ou sur un mobile UMTS d'une session 20 commencée sur GPRS) ; - continuité de session (partage de la bande passante avec une nouvelle application) ; - TV haute définition (encodage unique pour servir des clients SD "Standard Definition" et HD "High Definition") ; visioconférence (encodage unique pour des clients UMTS/Internet) ; 2.1. 1 Granularité de la scalabilité Un flux vidéo scalable peut être considéré comme un ensemble de sous-flux représentés par des cubes 11 dans un espace tridimensionnel formé des trois 30 dimensions spatiale 12, temporelle 13, et qualité, ou SNR, 14 (S,T,Q), comme illustré schématiquement par la figure 1.
La taille des incréments dans les différentes directions correspond à la "granularité" de la scalabilité: elle peut être fine, moyenne (10% de débit par incrément de scalabilité : MGS) ou grossière (25% de débit par incrément: CGS).
Dans la suite, on considèrera que la scalabilité CGS correspond à un système en couches ( layers dans le document MPEG2005/M12043, Avril 2005. "ISO/MP4 File Format for Storage of Scalable Video",Thomas Rathgen, Peter Amon et Andreas Hutter) et la scalabilité MGS à un système par niveaux ( levels dans ce même document).
2.1.2 Mode de scalabilité fine (MGS) Un train binaire scalable peut être organisé pour supporter une scalabilité fine. On parlera par la suite de scalabilité MGS ( Medium Grain Scalability ) conformément à la règle adoptée dans MPEG. À partir du train binaire, n'importe quel sous-flux cohérent peut être extrait (y compris le niveau de base) et décodé avec la qualité correspondante, c'est-à-dire n'importe quelle combinaison des résolutions supportées (temporelle, spatiale ou SNR) peut être extraite. Les trains binaires MGS permettent la flexibilité la plus élevée.
2.1.3 Mode d'organisation en couches ( Layered Scalability Mode ) Alternativement un train binaire peut être organisé en couches. On parlera alors de flux CGS ( Coarse Grain Scalability ). Une couche contient tous les niveaux de scalabilité nécessaires pour passer à la couche de qualité supérieure. Une couche doit augmenter la qualité dans au moins une direction (temporelle, spatiale ou SNR).
Une représentation CGS permet des opérations simples d'adaptation, notamment au niveau des noeuds du réseau. Les évolutions des informations dans l'espace qualité-résolution spatiale-résolution temporelle sont définis a priori selon les conditions imposées par une application ou par un utilisateur du service.
2.2 MPEG-4 SVC Le JSVM MPEG est décrit dans le document JSVM 2.0 déjà cité. Le modèle qui a été retenu est basé sur un codeur scalable fortement orienté vers des solutions de type AVC, dont la structure schématique d'un encodeur correspondant est présenté à la figure 2. Il s'agit d'une structure pyramidale. Les composantes d'entrée vidéo 20 subissent un sous-échantillonnage dyadique (décimation 2D par 2 référencée 21, décimation 2D par 4 référencée 22). Chacun des flux sous- échantillonnés subit ensuite une décomposition temporelle 23 de type MCTF ("Motion Compensated Temporal Filtering" pour "filtrage temporel compensé en mouvement"). Une version basse résolution de la séquence vidéo est codée 14 jusqu'à un débit donné R_rO_max qui correspond au débit maximum décodable pour la résolution spatiale basse rO (ce niveau de base est compatible AVC).
Les niveaux supérieurs sont ensuite codés 25, 26 par soustraction du niveau précédent reconstruit et sur-échantillonné et codage des résidus sous forme: - d'un niveau de base; - éventuellement d'un ou plusieurs niveaux de rehaussement obtenus par codage multipasse de plans de bits (appelé par la suite FGS pour "Fine Grain Scalability", échelonnabilité à grain fin). Le résidu de prédiction est codé jusqu'à un débit R_ri_max qui correspond au débit maximum décodable pour la résolution ri.
Plus précisément, les blocs de filtrage MCTF 23 réalisent un filtrage en ondelettes temporel, c'est-à-dire qu'ils réalignent les signaux dans le sens du mouvement avant filtrage en ondelettes: ils délivrent des informations de mouvement 27 qui alimentent un bloc de codage de mouvement 24-26, et des informations de texture 28, qui alimentent un module de prédiction 29. Les données prédites, en sortie du module de prédiction 29 servent à réaliser une interpolation 210 depuis le niveau inférieur. Elles alimentent également un bloc 211 de transformation spatiale et de codage entropique, qui travaille sur des niveaux de raffinement du signal. Un module de multiplexage 212 ordonne les différents sous-flux générés dans un flux de données compressé global.
Cette nouvelle approche est capable de fournir des flux scalables à grain moyen dans les dimensions temporelles, spatiale, et en qualité.
Les caractéristiques principales de cette technique sont les suivantes: solution pyramidale avec sous-échantillonnage dyadique des composantes d'entrée; - décomposition temporelle de type MCTF ("Motion Compensated Temporal Filtering" ou filtrage temporel de compensation de mouvement) à chaque niveau; - codage du niveau de base (compatible AVC) ; codage des niveaux supérieurs par soustraction du niveau précédent reconstruit et codage des résidus sous forme: - d'un niveau de base; et -d'un ou plusieurs niveaux de réhaussement obtenus par codage multipasse de plans de bits (par la suite: FGS).
Afin de réaliser une adaptation en débit, les informations de texture sont codées à l'aide d'un schéma progressif à chaque niveau: -codage d'un premier niveau de qualité minimale (appelé Base Layer Couche de Base) ; - codage de niveaux de raffinement progressif (appelés "Enhancement Layer" Couche de Réhaussement).
2.3 Architecture du codeur SVC L'encodeur SVC est basé sur un système en deux couches, comme AVC: - La couche VCL ( "Video Coding Layer") gère l'encodage de la vidéo; - La couche NAL ("Network Abstraction Layer") assure une interface entre la couche VCL et l'extérieur. En particulier, ce niveau organise en AUs ("access units" ou "blocs d'unités de données") les différentes NALU ("NAL Units" ou "unités de données") qui lui sont fournies par la couche VCL.
Une NALU est une unité élémentaire contenant le niveau de base d'une image spatio-temporelle, contenant tout (dans la version courante) ou partie (en cours de discussion pour les versions 30 futures) d'un niveau FGS d'une image spatio-temporelle; Une AU est l'ensemble des NALUs correspondant à un instant temporel.
2.4 Signalisation des modes de scalabilité dans la couche NAL SVC Afin de pouvoir décoder convenablement une NAL SVC, il faut pouvoir signaler son positionnement dans l'espace (S,T,Q) illustré par la figure 1.
Deux modes de signalisation (correspondant sensiblement aux modes CGS et MGS) sont actuellement en cours de discussion dans le JSVM: un mode de signalisation par chemin fixe, et un mode de signalisation par chemin variable.
Un exemple simple est donné par la figure 3, pour un contexte à deux dimensions 2D (T, Q) : un flux vidéo scalable contient les représentations emboîtées de sous-flux en CIF, de résolutions temporelles 15 Hz (31) et 30 Hz (32). Le flux est constitué de quatre NALUs A(0), B(2) , C(1) et D(2). En utilisant ces quatre NALUs on peut obtenir les points de débit distorsion a, b, c, d. La priorité des NALUs est indiquée entre parenthèses.
Sur cet exemple, on voit qu'il y a plusieurs "chemins" 33, 34 et 35, de décodage possible entre les points a et d: (a,b,c,d) mais aussi (a,b,d) ou (a,c,d).
On comprend que certaines applications pourront privilégier un chemin par rapport à l'autre.
Par exemple, il peut être judicieux d'utiliser le chemin (a,c,d) pour obtenir une vidéo fluide en 30 Hz, mais plutôt (a,b,d) si l'on souhaite privilégier la qualité en 15 Hz.
Ce chemin est donc dépendant de l'application et du mode de codage utilisé.
2.5.1 Chemin fixe Ce mode signale un chemin unique dans l'espace 3D pour l'extraction du flux scalable. Il est bien adapté au mode CGS pour certaines applications. Dans l'exemple de la figure 3, un chemin fixe va être choisi, par exemple (a,c,d).
Ce chemin sera toujours utilisé, que l'on décode en 30 ou en 15 Hz.
L'inconvénient majeur qui apparaît alors est que le point b ne sera pas décodé, même en 15 Hz, alors qu'il pourrait être plus intéressant de le décoder pour avoir une meilleure qualité en 15Hz.
Dans ce contexte, un indicateur unique permet de coder ce chemin fixe. 2. 5.2 chemin variable Ce mode propose de laisser à l'application (ou au réseau) le choix du chemin d'extraction. Pour ce faire, on introduit un élément supplémentaire, que l'on appelle l'indicateur de priorité, et qui va permettre de résoudre le problème évoqué plus haut lorsqu'on décode en 30 Hz.
Les deux tableaux suivants montrent respectivement les priorités affectées aux NALUs A, B, C et D dans l'exemple ci-dessus et le résultat du filtrage en 15 Hz et en 30 Hz selon la priorité choisie au décodage (sont décodées/conservées les NALUs qui apparaissent dans le tableau). On notera qu'il est possible en 30 Hz de définir plusieurs chemins différents en fonction de l'indice de priorité affecté aux quatre NALUs.
NAL A B C D
Priorité 0 2 1 3 Priorité au 15Hz 30Hz filtrage 0 A A 1 A A+C 2 A+B A+B+C 3 A+B A+B+C+D Les règles de filtrage utilisées ici sont les suivantes: Pour une résolution temporelle T cible (30 ou 15 Hz) garder toutes les NALs dont la résolution temporelle est inférieure ou égale à la résolution demandée (T_NAL <= T_Cible) et la priorité est inférieure ou égale à la priorité demandée (priorité_NAL<= priorité_ cible).
Le procédé est généralisable à plus de deux dimensions: dans l'exemple illustré par la figure 4A, il y a trois dimensions de scalabilité : - D = Spatial: QCIF/CIF (la dépendance D est un sur-ensemble de la résolution spatiale S) ; T = Temporel: 15 Hz/30 Hz; Q = Qualité/complexité faible/forte ( low/high ).
Un exemple d'association de priorités aux différentes NALUs est précisé 5 sur la figure, et un exemple de filtrage associé est montré dans le tableau ci-dessous. Low
complexity/SNR 0 A A A A 1 A+E A+(B+E) A+(C+E) A+C A+(B*C+q 2 A+E A+(B+E) A+(C+E) A+C A+(B+C+E) +F +G +(D+F+G) 3 A+E A+(B+E) A+(C+E) A+C A+(B+C+E) + F +G +(D+F+G) +H Dans ce contexte, un indicateur double est nécessaire: le "priority field" contient l'indicateur de priorité et le "decodability info" contient les informations de résolution spatiale, temporelle et en qualité. Ces deux indicateurs nécessitent une représentation sur deux octets. Ainsi, dans toute la suite du document, une NAL sera repérée par ses quatre indices (P,D,T,Q) accessibles par exemple dans l'en-tête de fichier où : - P indique la priorité ; - D indique la dépendance (surensemble de la résolution spatiale S) ; - T indique la résolution temporelle; - Q indique la qualité, ou la complexité.
On notera que les cellules en gras du tableau ci-dessus présentent des anomalies par rapport à la résolution spatio-temporelle demandée: en QCIF 30 Hz, il serait souhaitable de bénéficier de la NALU B, et non uniquement de la NALU A qui est à 15 Hz.
L'invention a entre autres comme objectif de pallier ce problème. 3. Inconvénients de la technique antérieure La solution à chemin fixe ne permet pas de servir simultanément des applications différentes, car il n'existe qu'une relation unique de dépendance entre les NALUs issus d'un codeur hiérarchique.
La solution à chemins multiples est plus ouverte que la solution à chemins fixes: elle permet de s'adapter à des applications/résolutions différentes, dans le réseau ou au niveau du décodeur. L'augmentation de complexité reste limitée, mais peut n'être pas adaptée pour une adaptation à très faible complexité comme fait sur certains routeurs de réseaux par exemple.
La solution à chemin fixe ne permet pas de s'adapter au cours du temps à des conditions différentes du côté de l'utilisateur, du réseau ou du serveur: un client ne pourra choisir à un instant de favoriser un axe (par exemple la fluidité temporelle) plutôt qu'un autre (par exemple la qualité SNR) tel que le choix imposé par l'ordonnancement défini par le chemin fixe d'adaptation.
Aucune des deux solutions (fixe ou variable) ne permet de gérer un mode de repli qui permettrait à un utilisateur de réduire la qualité ou la résolution des données reçues selon ses propres préférences.
4. Objectifs de l'invention L'invention a notamment pour objectif de pallier ces inconvénients de l'état de la technique.
Plus précisément, un objectif de l'invention est de fournir une technique de représentation vidéo scalable fine (en couches) des unités de données, ou paquets, ou NALUs, issus d'un codeur vidéo scalable dans le domaine 3D spatial-temporelqualité, qui soit plus efficaces que les techniques connues.
Ainsi, un objectif de l'invention est de permettre de gérer des chemins différents dans cet espace 3D en fonction des caractéristiques de l'application, du réseau ou des besoins du client.
En d'autres termes, un objectif de l'invention est de fournir une telle technique permettant de réaliser des traitements adaptés d'une même vidéo scalable pour des applications différentes.
Un autre objectif de l'invention est de permettre de définir des modes de repli spécifiques dépendants ou indépendants des applications.
L'invention a également pour objectif de permettre de définir des modes de remontée spécifiques dépendants ou indépendants des applications.
Un autre objectif de l'invention est de permettre de varier au cours du temps modes et les points de fonctionnement pour un même flux vidéo.
5. Résumé de l'invention Ces objectifs, ainsi que d'autres qui apparaîtront plus clairement par la suite, sont atteints selon l'invention à l'aide d'un procédé de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées.
Selon l'invention, ce procédé comprend une étape de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
Ainsi, l'invention permet de s'adapter finement à un grand nombre de contextes pour lesquels il est souhaitable de réduire ou augmenter la quantité d'informations transmises ou reçues. Il peut par exemple s'agir d'adapter les données au niveau du serveur, au niveau de noeuds intermédiaires, ou translateurs, placés dans un réseau, ou au niveau du terminal par sélection d'un profil par l'usager.
De façon avantageuse, un premier desdits chemins privilégie une caractéristique représentative de la qualité de chaque image reconstruite par un terminal et un deuxième desdits chemins privilégie une caractéristique représentative de la fluidité de la vidéo.
Il est ainsi possible de privilégier, selon le contenu, la qualité de l'image, par exemple pour un film, ou la fluidité des mouvements, par exemple pour du sport. De nombreux autres chemins (également appelés profils) et variantes peuvent bien sûr être définis.
Préférentiellement, chacune desdites unités de données de réhaussement porte au moins deux indicateurs permettant de définir lesdits chemins, parmi les indicateurs appartenant au groupe comprenant: - un indicateur de priorité (P) ; - un indicateur de dépendance, relatif à la résolution spatiale (D) ; - un indicateur de résolution temporelle (T) ; -un indicateur de qualité et/ou de complexité (Q).
Selon un mode de réalisation avantageux de l'invention, lesdits chemins sont stockés dans un fichier de chemins, associant chacun desdits chemins à un profil applicatif prédéterminé. Ce fichier de chemins peut notamment être un fichier au format XML.
Il peut par exemple être stocké et/ou calculé à la volée par les terminaux. Dans un mode de réalisation préférentiel, ledit fichier de chemins est transmis dans ledit flux vidéo, sous la forme d'au moins une unité de données d'information.
De façon avantageuse, le procédé de filtrage comprend les étapes suivantes: - séparation desdites unités de données de réhaussement, en fonction du chemin sélectionné, entre des unités de données à utiliser et des unités de données écartées; - reconstruction d'images vidéo à l'aide desdites unités de données à utiliser; - mémorisation desdites unités de données écartées.
Cette dernière étape peut correspondre à un stockage, par exemple sur un disque dur, permettant de rejouer plus tard la vidéo avec un autre niveau de qualité, par exemple si la taille d'écran n'est plus la même. Il peut également s'agir d'une mémorisation dans une mémoire tampon, en vue d'une transmission des unités de données écartées sur un autre canal de transmission.
Bien sûr, les unités de données écartées peuvent également être directement supprimées.
Avantageusement, le procédé comprend les étapes suivantes: -détection d'au moins une unité de données à utiliser manquante ou détériorée; reconstruction d'une vidéo à partir d'unités de données correspondant à une des positions de repli du chemin sélectionné.
Ainsi, en cas de perte d'un paquet, on ne perd pas la restitution de la vidéo, mais on passe simplement à une qualité inférieure.
Le procédé de l'invention peut être mis en oeuvre à différents niveaux de la chaîne de transmission, et notamment par au moins un desdits éléments suivants: - serveur de flux vidéo; - noeud intermédiaire d'un réseau de transmission; - terminal récepteur d'un flux vidéo.
L'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre d'au moins une étape du procédé de filtrage décrit ci-dessus.
Selon un autre aspect de l'invention, celle-ci concerne un procédé de transmission d'un flux vidéo scalable par un serveur de flux vidéo vers au moins un terminal récepteur, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées.
Ce procédé comprend une étape de transmission d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente.
Ledit serveur et/ou un noeud intermédiaire dudit réseau de transmission met en oeuvre une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal (ou de plusieurs terminaux) recevant ledit flux, et une étape de transmission des unités de données sélectionnées.
De façon avantageuse, ledit serveur et/ou ledit noeud intermédiaire met en oeuvre ladite étape de sélection en fonction d'une information de sélection émise par ledit terminal. Elle peut également tenir compte d'une synthèse des informations émises par un groupe de terminaux.
L'invention concerne également un produit programme d'ordinateur pour la mise en oeuvre d'au moins une étape de ce procédé de transmission d'un flux vidéo scalable.
Selon encore un autre aspect, l'invention concerne un procédé de réception dans un terminal récepteur d'un flux vidéo scalable transmis par un serveur de flux vidéo, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées.
Selon ce procédé, on utilise au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et ledit terminal récepteur met en oeuvre une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
La notion d'utilisation d'au moins deux profils peut signifier que le terminal a préalablement reçu, du serveur, ces différents profils, et/ou qu'il les a calculé, par exemple à la volée. La sélection d'un chemin peut être automatique (pilotée par le terminal) et/ou à l'initiative de l'utilisateur.
L'invention concerne également un produit programme d'ordinateur pour la mise en oeuvre d'au moins une étape de ce procédé de réception d'un flux vidéo 15 scalable.
L'invention concerne également les serveurs de flux vidéo, les noeuds intermédiaires d'un réseau de transmission et les terminaux récepteurs de flux vidéo comprenant des moyens pour mettre en oeuvre les procédés décrits ci-dessous.
Enfin, l'invention concerne un signal destiné à être transmis depuis un serveur vers au moins un terminal, pour permettre le traitement d'un flux vidéo scalable transmis par ledit serveur de flux vidéo, via un réseau de transmission, ledit flux étant organisé comme détaillé précédemment. Un tel signal porte des données de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente.
Ce signal permet ainsi une sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
Selon un mode de réalisation avantageux, le signal porte d'une part lesdites unités de données formant ledit flux vidéo, et d'autre part lesdites données de définition. Les deux éléments peuvent également être transmis de façons indépendantes.
6. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donnée à titre de simple exemple illustratif et non limitatif, et des dessins annexés parmi lesquels: - la figure 1, déjà commentée en préambule, illustre la structure d'un flux vidéo scalable, dont les sous-flux sont représentés par des cubes dans un espace tridimensionnel formé des trois dimensions spatiale, temporelle, et qualité ; - la figure 2, également commentée en préambule, présente la structure schématique d'un encodeur du flux de la figure 1; - la figure 3, commentée en préambule, est un exemple de structuration d'un flux scalable en deux dimensions, et de trois chemins correspondants; - la figure 4A, également commentée en préambule, illustre un exemple de structuration à trois dimensions de scalabilité, et lafigure 4B présente une une variante de répartition des priorités pour une NAL, selon un aspect de l'invention; - la figure 5 est un organigramme simplifié du principe de l'invention; - la figure 6 illustre un tableau de filtrage présentant deux chemins selon l'invention; - la figure 7 présente les plages de débit correspondant au tableau de la figure 6; - la figure 8 est un autre exemple de tableau de filtrage selon l'invention, utilisant la notion d'indicateur de priorité ; les figures 9 à 11 illustrent trois mises en oeuvre de l'invention, respectivement dans un modèle client-serveur, l'adaptation du débit dans un noeud intermédiaire et l'adaptation à un terminal; la figure 12 illustre les dépendances définies par un profil, et la figure 13 la reconstruction des dépendances pour le repli sur la meilleure qualité possible en cas de perte d'une NALU; les figures 14, 15 et 16 présentent respectivement des schémas simplifiés des serveur, noeud de transmission et terminal selon l'invention. Description d'un mode de réalisation préférentiel de l'invention éléments essentiels de l'invention L'invention propose donc d'utiliser, selon le mode de réalisation décrit par la suite, les champs (P,D,T,Q) de NALUs SVC, afin de gérer des ordres de priorité dépendant des besoins applicatifs spécifiés et utilisable pour faire de l'adaptation d'un flux vidéo côté serveur (régulation de débit, adaptation à la demande), noeuds de transmission (DiffServ, TOS) ou côté client (adaptation en complexité, ...).
On se place dans le contexte du filtrage générique connu, décrit précédemment. Chaque NAL est donc définie par le quadruplet (P,D,T,Q). Le filtrage s'effectue selon N des 4 dimensions (N<=4).
On dispose de modes de repli, c'est-à-dire de mécanismes permettant de privilégier un chemin dans l'espace (D,T,Q) lorsque les résolutions cibles ne peuvent être atteintes (pour des raisons de diminution de débit, de complexité, de choix de l'utilisateur...).
Selon l'invention, un ensemble de profils applicatifs (ou chemins) est défini. Ces profils applicatifs définissent donc des ordres différents de priorité sur les modes de repli, en fonction de critères tels que le type de vidéo (sport ou cinéma par exemple), le type de terminal (capacité de traitement et de mémoire, taille de l'écran) et/ou les capacités du réseau. Par exemple, dans le premier cas, on peut définir deux profils: Profil sport: on privilégie la fluidité temporelle:
-
-
- 7. 7.1
SD@30Hz high => SD@30Hz low => CIF@30Hz high => CIF@ 15Hz high Profil film: on privilégie la qualité à la fluidité et résolution spatiale: SD@30Hz high => SD@ 15Hz high => SD@7.5Hz high => CIF@7.5Hz high.
Un profil applicatif est alors défini par une suite de valeurs (P,D,T,Q)i.
L'ensemble des profils applicatifs peut être stocké dans un fichier, par exemple un fichier XML (ce fichier s'appliquant à une séquence complète ou bien à des segments de la séquence ou encore à un ensemble de séquences). Ce fichier peut être transmis avec le flux vidéo, ou dans un canal séparé. Il doit être disponible avant le début du décodage de la séquence/segment...). Un autre mode de réalisation est le transport ces méta-paramètres dans des NALUs d'information (par exemple NALUs de type SEI).
Le déroulement du procédé de filtrage, illustré par l'organigramme de la figure 5, est le suivant: 1. Lecture 51 du fichier des profils applicatifs contenant les modes de repli et choix 52: a. d'un mode de fonctionnement initial (par exemple sport) (chemins de repli et de remontée) ; b. d'un point de fonctionnement initial (par exemple haut débit CIF@30 Hz) ; Ce point de fonctionnement peut être remis à jour de façon externe (sur une base d'adaptation en débit, en qualité, en complexité...) conformément à une stratégie de repli définie; 2. Lecture 53 des indices de l'unité de vidéo scalable à traiter: on lit dans l'en- tête de la NAL les informations de résolution spatio-temporelles-qualité (P_paq, D_paq, T_paq, Q_paq) (une ou plusieurs des dimensions peuvent être omises) ; 25 3. En fonction du point de fonctionnement (remis à jour ou non par le processus externe) : a. Lecture 55 du mode de fonctionnement (par exemple: sport) associé à un chemin ascendant et descendant permettant de se déplacer dans l'espace de scalabilité ; b. Choix d'un point de fonctionnement (lecture ou calcul de P'_cible D'_cible, T'_cible, Q'_cible) ; 4. Filtrage 56: a. Réduction du débit: suppression des paquets pour lesquels (P_paq, D_paq, T_paq, Q_Paq) ne sont pas conformes à la cible, conformément à la table XML; b. rejet 57 ou utilisation 58 du paquet (ou NALU) ; 5. Modification 54 (éventuelle via un processus externe ou autre) du point de fonctionnement: a. changement du mode de fonctionnement (passer d'une priorité donnée à la fluidité des images à une priorité sur la qualité ou la résolution spatiale) ; b. changement du point de fonctionnement (demande de remontée ou de descente en qualité de service).
La modification 54 tient compte d'un indicateur 59 de mode de repli délivré par un adaptateur de profil 510 contrôlé selon les cas par le terminal client 511, le serveur 512 et le réseau 513.
Chacune de ces étapes est détaillée par la suite.
L'invention s'appuie sur la définition d'une relation entre les champs P, D, T, Q de l'en-tête des NALUs en vue d'organiser le flux vidéo en sortie du procédé conformément aux attentes d'un service particulier, ou d'un groupe de services.
7.2 Signalisation des NALUs On propose, selon un mode de réalisation avantageux, d'améliorer la numérotation proposée dans l'art antérieur en déclarant que chaque niveau de base 30 est de priority_id O. Cette approche est illustrée par la figure 4B. Elle permet 10 efficacement de faire disparaître les points en anomalie entre les résolutions spatiotemporelles demandées et délivrées (case en gras du tableau de l'art antérieur).
7.3 Etablissement du tableau de filtrage Le tableau de filtrage illustré en figure 6 est établi conformément à l'art antérieur. On peut aussi calculer, de manière optionnelle, un débit associé à chaque "case" significative du tableau.
On peut interpréter ce tableau comme un ensemble d'intervalles de résolutions avec des débits recouvrants (ou non). Cette interprétation est illustré par la figure 7. A l'intérieur de chaque intervalle, le débit augmente avec le Priority_id P. Sur le tableau de la figure 6, on peut noter que chaque série est monotone dans le tableau, alors que la courbe 61 ne l'est pas. Cela est un avantage de la solution de l'invention.
Un mode de repli correspond à une descente (flèches 61 et 62) dans le tableau de la figure 6. Par exemple, on définit: un profil sport 61, selon lequel on privilégie la fluidité temporelle CIF@30Hz high => CIF@30Hz low => QCIF@30Hz high => QCIF@30Hz Low > QCIF@ 15Hz high; - un profil film 62, selon lequel on privilégie la qualité à la fluidité et résolution spatiale: CIF @30Hz high => CIF @ 15Hz high =>QCIF @ 15Hz high =>QCIF @7.5Hz high.
La même approche peut être définie par évolution de plages de débit, comme illustré par la figure 8: profil sport 81: SD@30Hz (high to low) => CIF@30Hz (high to low) => QCIF@30Hz (high to low) ...
profil film 82...
Afin de définir ces modes de repli en fonction des applications, on peut imaginer par exemple un fichier XML des profils applicatifs du type suivant: <?xml <Root xmins:x:;i="http://www.w3.org/2001/XMLSchemainstance" 5 xsi:no Name,-.,, C: \Mes Documents\Brevets\DIH\Transport SVC\XML\Repli.xsd"> <Espace3D> <!-- D:n i:=]on de plages le. t:onc.tlonaeTClent z?our des type: . <Range Ld="1" 3="QCIF" T="15Hz" Q="low" PM T PM.._; 0 /> <!--cette première plage correspond à du QCIF 15hz avec PMin =PMax, i. e. un seul pc int "--> <Range ici="2" S=,QCIF" T="15Hz" Q="high" PM:i - ="0" 15 PMax="1"/> <!-- première plage corresponnd à du QCIF 15hz a ec; PMin<PMax, plusieurs points"-> <Range -"3" ii="QCIF" "'="30Hz" >="low" P i n="0" P?M a x= Q " /> <Range c="4" S="QCIF" T="30Hz" Q="high" 4' n=" 7, PMax="3"/> Pnîa _-.. 2 /> PMax="0" /><Range i_e="5" S="CIF" T="15Hz" Q="low" PMin="0" <Range d="6" :'="CIF" T="15Hz" Q="high" PM n="l" < Range i::="7" ,="CIF" T="30Hz" Q "low" P ="0" <Range I="8" S="CIF" T="30Hz" Q="high" PMI n="0" <Range "," CIF" i="30Hz" ç_="high" :'rii </Espace3D> <Mesapplications> <Application -une"application une"> <1-- application numero un--> <type> sport </type> <H-application de type sport"--> path_preference> temporel </path_preference> <RangeOrder> "8 4 2"</RangeOrder> <!-- Ce ch-m_1 i JI ae Inc pr erence d., iihce t m' or le---> <debits>"150 150-300 450 450-900"< /debits> </Application> Application name="appllcatjon deux"> < ion cernera <Lype>film</type> <1 application de type film"--> <path preference> qualité</path_preference> < RangeOrder> "9 6 2"</RangeOrder> <!-- c, chener IngIgne une DrefEilence gualite par 7 1pp(,r es axes --> <debits> "100-200 400-600 800-900"</debits> </Application> <Application name="application trois"> <1 non app'icat-on numero trois--> <type>mobile</type> pathpreference> resolution< /path_preference> <RangeOrder>"9 6 5"</RangeOrder> < debits/> </Application> </Mesapplications> </Root> On présente en annexe un schéma complet permettant de valider cet
exemple.
Tout autre moyen de description des profils applicatifs est possible, tel qu'un tableau dans un langage de programmation, ou une insertion dans le flux vidéo (SEI à définir).
Sur l'exemple de fichier XML ci-dessus, on a défini des plages de fonctionnement (dénommées range ). Ces plages de fonctionnement correspondent à un triplet de valeur (DTQ) et une plage de valeurs de priority_id (Pmin, Pmax).
Cette plage de priority_id permet alors d'offrir une variation en qualité/débit pour une résolution donnée. La disponibilité de différentes plages pour différentes résolutions spatio-temporelles permet alors de définir des profils applicatifs de repli.
Un profil applicatif est alors défini par une suite de range . Ainsi sur cet exemple, le profil sport passe d'une plage de débit en CIF@30Hz puis une plage de débit pour du QCIF@30Hz et enfin pour du QCIF@ 15Hz, privilégiant ainsi une fluidité temporelle lors de l'utilisation de mode de repli.
Il est à noter que les plages de débits proposées dans un mode applicatif peuvent se chevaucher (voir figure 7). Ceci autorise ainsi un phénomène d'hystérésis dans l'algorithme décrit par la suite qui permet alors une plus grande stabilité du système en limitant l'utilisation des modes de repli.
7.4 Algorithme générique d'adaptation En reprenant l'exemple de profils applicatifs tels que décrit ci-dessus, un algorithme d'adaptation fonctionne de la manière suivante: 1- Lecture des profils applicatif. Par exemple le fichier xml décrit ci-dessus: a- sélection d'un mode applicatif. Par exemple profil sport ("application une") ; b- sélection d'un point de fonctionnement initial. Par défaut choix du mode de fonctionnement maximal: Point ayant le priority_id maximum dans le range 9. Soit p_cible=3, D_cible=CIF, T_cible=30Hz, Q_cible=High; 2- Lors d'une adaptation nécessaire, le processus externe fait alors varier la valeur du priority_id dans le range courant (par exemple en utilisant un système de rétro-action, ou bien en utilisant une tabulation priority_id donne débit). Si la contrainte n'est pas satisfaite, on peut alors décider d'opérer un repli (sélection du range inférieur) ou de remontée (sélection du range supérieur). La recherche du range adéquat et du priority_id peut être poursuivi jusqu'à obtention de la contrainte.
7.5 Filtrage Cette étape, classique en soi, consiste à É Rejeter (ou traiter de façon adéquate par exemple par routage haut débit) tous les paquets pour lesquels (P_paq > P_courant) et/ou (S_paq > S_courant) et/ou (T_paq > T_courant) et/ou (Q'_paq > Q_courant), É Traiter les autres paquets (transmission, stockage, ...).
7.6 Exemple d'applications de l'invention L'invention peut prendre en compte un grand nombre de contraintes applicatives et peut se réaliser indifféremment en tout point du réseau placé sur le chemin entre le codeur et le décodeur, dans un processus temps réel ou de traitement en différé.
Le tableau ci-dessous décrit plusieurs exemples d'actions types et leurs localisations possibles dans le réseau: Type d'action Localisation des actions Serveur Noeud Récepteur intermédiaire Réduction débit Sélection des Sélection des NALUs par NALUs par niveau niveau hiérarchique de hiérarchique de débit débit Définition d'un Restreindre les Restreindre les Sélection des chemin d e dépendances au dépendances au dépendances dépendances décodage à un décodage à un autorisant un chemin unique et chemin unique et chemin optimum prédéfini, selon prédéfini, selon de décodage stratégie opérateur stratégie opérateur a d a p t é a u T V et/ou TV et/ou opérateur terminal.
opérateur télécom télécom Pertes de paquets Trouver un chemin T r o u v e r u n de dépendance chemin de pour récupérer la dépendance pour qualité maximale récupérer la quand un paquet qualité maximale est perdu quand un paquet est perdu 7.6.1 Contexte 1: modèle client-serveur (adaptation aux ressources et aux choix de l'utilisateur) La figure 14 présente la structure simplifiée d'un serveur selon l'invention, qui comprend une mémoire M 148, une unité de traitement 146, équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur Pg 147. A l'initialisation, les instructions de code du programme d'ordinateur 147 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 146. L'unité de traitement 146 reçoit en entrée un ensemble de NALUs 141. Le microprocesseur P de l'unité de traitement 146 délivre un flux vidéo filtré 143 en fonction du profil, ou chemin, sélectionné, selon les instructions du programme Pg 147.
Cette mise en oeuvre est illustrée par la figure 9. Le serveur 91 propose (911) au client 92 un choix de profils applicatifs, en fonction d'une demande 921 de flux vidéo.
Le client choisit (922) un mode et un point de fonctionnement.
Le serveur reçoit le mode de fonctionnement et le point de fonctionnement 912 du client, en fonction de quoi il filtre (913) les éléments 914 du codage vidéo. Seuls les paquets conservés, formant la vidéo filtrée 915, sont transmis au client. Les modes et points de fonctionnement peuvent être remis à jour par un processus d'adaptation externe 93 recevant des rapports de l'usager (ou du réseau).
L'adaptateur de profils 93 utilise les éléments "RangeOrder" du fichier XML de profils.
7.6.2 Contexte 2: modèle serveur-réseau-client (adaptation au réseau) La figure 15 présente la structure simplifiée d'un noeud intermédiaire de réseau selon l'invention, qui comprend une mémoire M 154, une unité de traitement 151, équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur Pg 152. A l'initialisation, les instructions de code du programme d'ordinateur 152 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 151. L'unité de traitement 151 reçoit en entrée un flux vidéo 151. Le microprocesseur P de l'unité de traitement 151 filtre le flux vidéo 151, en fonction d'un profil sélectionné, et délivre un flux filtré 153, selon les instructions du programme Pg 152.
Cette deuxième mise en oeuvre est illustrée par la figure 10.
Le serveur 101 envoie dans le réseau un flux (vidéo haut débit) 102 destiné à un groupe de récepteurs acceptant une image haute qualité et avec un débit élevé. Contrairement à l'exemple précédent fonctionnant en point à point, cet exemple fonctionne en multicast.
Le noeud intermédiaire 103 reçoit le même flux 102 que les autres récepteurs placés sur le réseau. Il dispose en interne d'un profil applicatif cible 1031 permettant de piloter l'algorithme de filtrage 1032 pour aboutir au débit cible du flux 1033, par élimination 1034 des paquets hors profil. Le client 104 reçoit cette vidéo filtrée 1033.
Dans le cas où les profils fournis par le serveur ne sont pas adaptés, le noeud intermédiaire peut calculer de nouveaux profils directement par analyse des champs {P,D,T,Q}.
7.6.3 Adaptation du débit aux ressources du terminal La figure 16 présente la structure simplifiée d'un terminal selon l'invention, qui comprend une mémoire M 160, une unité de traitement 161, équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur Pg 162. A l'initialisation, les instructions de code du programme d'ordinateur 162 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 161. L'unité de traitement 161 reçoit en entrée un flux vidéo 163. Le microprocesseur P de l'unité de traitement 161 filtre le flux vidéo 163, en fonction du profil sélectionné, selon les instructions du programme Pg 162. L'unité de traitement 161 délivre en sortie un flux vidéo filtré 164.
La figure 11 donne un exemple de l'adaptation de l'affichage aux ressources d'un terminal 111, par exemple un terminal à ressources limitées. Le transport de la vidéo 112 contient l'ensemble des informations pour tous les terminaux. En fonction de la capacité réduite du terminal, un usager peut choisir (1111), pour son confort personnel, de privilégier un profil avec une meilleure fluidité ou un profil avec une meilleure définition, parmi ceux disponibles 1112. Par exemple, l'utilisateur choisit le profil "sport".
Il dispose en outre d'une IHM qui va lui permettre de naviguer dans les niveaux de qualité. Il peut en particulier choisir d'augmenter ou diminuer le point de fonctionnement.
Les profils applicatifs sont insérés dans les paramètres généraux 1121 de la vidéo, par message SEI, table xml, EPG ou par tout autre moyen.
Le filtrage 1113 est effectué en fonction du profil sélectionné, et le décodeur 1114 reconstruit les images correspondantes.
7.6.4 Récupération de la meilleure qualité en cas de perte de NAL dans un récepteur L'adaptation des NALUs peut varier dans les plages de qualité correspondant à un niveau, comme indiqué par la figure 12, le basculement d'un niveau vers un autre peut s'effectuer aux extrémités de la plage.
En considérant un usager recevant le niveau CIF30, et donc tous les niveaux intermédiaires, la description des profils applicatifs permet de retrouver l'information fournissant la meilleure qualité. La figure 13 montre un exemple de cette approche.
Les NALUs 131, 132 et 133 ont été perdus. L'analyse des champs PDTQ permet de retrouver l'information disponible de meilleure qualité en attendant l'image suivante reçue sans erreur. Les NALUs reçus 134 et 135 correspondent aux niveaux inférieurs manquants ne permettent pas le décodage. On se replie alors sur la NALU 136.
ANNEXE
<?xml v rs ="1.0" .,d rlc:,="UTF-8"?> <xs:schema xmins:x="http://www.w3.org/2001/XMLSchema" rac Le r 1 far. _t="qualified"> <xs:element r._._<< "Application"> < xs:complexType> <xs:sequence> <xs:element rer="type"/> < xs:element rer="path preference"/> <xs:element rei ="RangeOrder" <xs:element ref="debits"/> <1-- pour définir le type du profil
-
<1-- pour illustrer le type de st.rateaie de repli.:., Ils- . e.g. "temporel", "qualité". --> <1-- définit les plages de fonctionnement à. utiliser dans l'ordre; cet element est obligatoire--> <1-- permet de définir les débits associés aux différentes I acres. e. g. "100-300 =00' pour indic.,per que la première pl ue r.e en e 100 et 300, ti)1 5; et.. que.d deuxième plage i un débit de 400 xbit/s --> </xs:sequence> <xs:attribute rame-"narre" type="xs:string" 25,. se="required"/> </xs:complexType> <1- une applicat..:i.on deti..n..i..t. une gamme de plage de débit: en ro lesquels évoluer --> </xs:element> <xs:element 1:cu "Espace3D"> 15 20 25 30 < xs:complexType> <xs:sequence> <xs:element ref="Range" :axi cca r="unbounded" /> </xs:sequence> </xs:complexType> < !-un espace 3D définit un ensemble de plage de définir débits (.:.. Ii<e) SU;i'rj?i.7..C.. .e.S d'erre Ut'..i1bHS pour des profils d'applicatio's --> </xs:element> <xs:element r. ra="Mesapplications"> <xs:complexType> <xs:sequence> < xs:element r f="Application" rr xO_cirs="unbounded"/> < /xs:sequence> </xs:complexType> <1-- contient la liste des différents profils appiicatifs --> </xs:e.l..ement> < xs:element nm' ="Range"> <xs:complexType> <xs:attribute n< une-"id" tvp"xs:positiveInt.eger" t.1se="required"/> <xs:attribute name "S" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration 1="CIF"/> <xs:enumeration alue ="QCIF"/> <xs:enumeration value="SD"/> 10 15 20 25 30 < xs:enumeration vai..ue.="HD"/> </xs:restriction> </xs:simpl. eType> <!-- le champ S erre or. u r__i:au s p </xs:attribute> <xs:attribute naine="T" use="required"> <xs:simpleType> < xs:restriction bese="xs:NMTOKEN"> <xs:enumeration alise="7.5Hz"/> <xs:enumeration value="l5Hz"/> <xs:enumeration valu ="30Hz"/> <xs:enumeration - A...:="60Hz"/> </xs:restriction> < /xs:simpleType> <!-- champ T correspond au niveau temporel --> </xs:attribute> <xs:attribute r e="Q" us'="required"> < xs:simpl.eType> <xs:restriction base="xs:NMTOKEN"> < xs:enumeration va;e="high"/> <xs:enumeration varie="med"/> < xs:enumeration ="low"/> </xs:restriction> </xs:s.impleType> < ! -- le champ Q correspond au niveau dÉ qualité ,on. bien encore de complexité --> </xs:attribute> <xs:attribute name="PMin" "xs:nonNegativelnteqer" use="required"/> <xs:attribute name="PMax" ype="xs:nonNegatrvelnteger" use="required"h> <1-- Min, hMax définissent I.s limites CLÉ.' a plage aE fonctionuement --> < /xs:complexType> <1-- Ra e déf lit une Plage de ddb fonctionnement (dé Ir par Pm. Pmax) pour une résolution. spatio- temporelle donnée (d::ini par S,T,Q) --> </xs:element> <xs:element name="Root"> <xs:complexType> <xs:sequence> <xs:element '-"Espace3D"/> <xs:element r f="Mesapplications"/> < /xs:sequence> </xs:complexType> <1-- Racine de définition du fichier. Doit contenir une défi nitino de plages de débit (Espace3D) , et une liste de profils applidatifs MesApplications) --> < /xs:element> <1-- Définition des types des éléments syntaxiques utilisés --> <xs:element aue="debits" tvoe="xs:string"/> < xs:element r me="RangeOrder" tut) "xs:strine/> <xs: element rann="path preference" tyoe="xs:string" /> <xs:element r,Pr="type" 1p-r-="xs:string"/> </xs:schema>
Claims (21)
1. Procédé de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées, caractérisé en ce qu'il comprend une étape de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
2. Procédé de filtrage d'un flux vidéo scalable selon la revendication 1, caractérisé en ce qu'un premier desdits chemins privilégie une caractéristique représentative de la qualité de chaque image reconstruite par un terminal et un deuxième desdits chemins privilégie une caractéristique représentative de la fluidité de la vidéo.
3. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 et 2, caractérisé en ce que chacune desdites unités de données de réhaussement porte au moins deux indicateurs permettant de définir lesdits chemins, parmi les indicateurs appartenant au groupe comprenant: - un indicateur de priorité (P) ; - un indicateur de dépendance, relatif à la résolution spatiale (D) ; - un indicateur de résolution temporelle (T) ; - un indicateur de qualité et/ou de complexité (Q).
4. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 3, caractérisé en ce que lesdits chemins sont stockés dans un fichier de chemins, associant chacun desdits chemins à un profil applicatif prédéterminé.
5. Procédé de filtrage d'un flux vidéo scalable selon la revendication 4, caractérisé en ce que ledit fichier de chemins est un fichier au format XML.
6. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 4 et 5, caractérisé en ce que ledit fichier de chemins est transmis dans ledit flux vidéo, sous la forme d'au moins une unité de données d'information.
7. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comprend les étapes suivantes: - séparation desdites unités de données de réhaussement, en fonction du chemin sélectionné, entre des unités de données à utiliser et des unités de données écartées; - reconstruction d'images vidéo à l'aide desdites unités de données à utiliser; - mémorisation desdites unités de données écartées.
11. Procédé de filtrage d'un flux vidéo scalable selon la revendication 7, caractérisé en ce qu'il comprend une première étape de transmission desdites unités de données à utiliser via un premier canal de transmission, et une seconde étape de transmission desdites unités de données écartées via un second canal de transmission.
12. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comprend les étapes suivantes: - détection d'au moins une unité de données à utiliser manquante ou détériorée; - reconstruction d'une vidéo à partir d'unités de données correspondant à une des positions de repli du chemin sélectionné.
10. Procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il est mis en oeuvre par au moins un desdits éléments suivants: - serveur de flux vidéo; - noeud intermédiaire d'un réseau de transmission; - terminal récepteur d'un flux vidéo.
11. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre d'au moins une étape du procédé de filtrage d'un flux vidéo scalable selon l'une quelconque des revendications 1 à 10.
12. Procédé de transmission d'un flux vidéo scalable par un serveur de flux vidéo vers au moins un terminal récepteur, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées, caractérisé en ce qu'il comprend une étape de transmission d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et en ce que ledit serveur et/ou un noeud intermédiaire dudit réseau de transmission met en oeuvre une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités d'au moins un terminal recevant ledit flux, et une étape de transmission des unités de données sélectionnées.
13. Procédé de transmission selon la revendication 12, caractérisé en ce que ledit serveur et/ou ledit noeud intermédiaire met en oeuvre ladite étape de sélection en fonction d'une information de sélection émise par ledit terminal.
14. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre d'au moins une étape du procédé de transmission d'un flux vidéo scalable selon l'une quelconque des revendications 12 et 13.
15. Procédé de réception dans un terminal récepteur d'un flux vidéo scalable transmis par un serveur de flux vidéo, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées, caractérisé en ce qu'on utilise au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et en ce que ledit terminal récepteur met en oeuvre une étape de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
16. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre d'au moins une étape du procédé de réception d'un flux vidéo scalable selon la revendication 15.
17. Serveur de flux vidéo comprenant des moyens de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles ou spatiales, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisés, caractérisé en ce que lesdits moyens de filtrage comprennent des moyens de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et des moyens de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
18. Noeud intermédiaire d'un réseau de transmission de flux vidéo comprenant des moyens de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles ou spatiales, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisés, caractérisé en ce que lesdits moyens de filtrage comprennent des moyens de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et des moyens de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
19. Terminal récepteur de flux vidéo comprenant des moyens de filtrage d'un flux vidéo scalable, organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles ou spatiales, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisés, caractérisé en ce que lesdits moyens de filtrage comprennent des moyens de prise en compte d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, et des moyens de sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
20. Signal destiné à être transmis depuis un serveur vers au moins un terminal, pour permettre le traitement d'un flux vidéo scalable transmis par ledit serveur de flux vidéo, via un réseau de transmission, ledit flux étant organisé en blocs d'unités de données comprenant chacun une unité de données de base et un ensemble d'unités de données de réhaussement distribuées selon au moins deux types de données de réhaussement, correspondant respectivement à des caractéristiques temporelles et/ou spatiales et/ou de qualité, et permettant de définir plusieurs niveaux de qualité, selon le nombre et le type d'unités de données de réhaussement utilisées, caractérisé en ce que ledit signal porte des données de définition d'au moins deux profils, ou chemins, distincts de filtrage des unités de données de chaque bloc, chaque chemin définissant une série de positions de repli successives, à partir d'une position initiale, chaque position de repli utilisant au moins une unité de données de moins que la position précédente, de façon à permettre une sélection de l'un desdits chemins en fonction d'un critère prédéterminé tenant compte d'un type de contenu dudit flux et/ou d'au moins une information représentative des capacités du terminal recevant ledit flux.
21. Signal selon la revendication 20, caractérisé en ce qu'il porte d'une part lesdites unités de données formant ledit flux vidéo, et d'autre part lesdites données de définition.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0507690A FR2889017A1 (fr) | 2005-07-19 | 2005-07-19 | Procedes de filtrage, de transmission et de reception de flux video scalables, signal, programmes, serveur, noeud intermediaire et terminal correspondants |
| EP06777838A EP1941734A1 (fr) | 2005-07-19 | 2006-07-18 | Procedes de filtrage, de transmission et de reception de flux video scalables, programmes, serveur, noeud intermediaire et terminal correspondants |
| US11/996,196 US8743950B2 (en) | 2005-07-19 | 2006-07-18 | Method for filtering, transmitting and receiving scalable video streams, and corresponding programs, server, intermediate node and terminal |
| PCT/EP2006/064382 WO2007009996A1 (fr) | 2005-07-19 | 2006-07-18 | Procedes de filtrage, de transmission et de reception de flux video scalables, programmes, serveur, noeud intermediaire et terminal correspondants |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0507690A FR2889017A1 (fr) | 2005-07-19 | 2005-07-19 | Procedes de filtrage, de transmission et de reception de flux video scalables, signal, programmes, serveur, noeud intermediaire et terminal correspondants |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2889017A1 true FR2889017A1 (fr) | 2007-01-26 |
Family
ID=36570538
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0507690A Pending FR2889017A1 (fr) | 2005-07-19 | 2005-07-19 | Procedes de filtrage, de transmission et de reception de flux video scalables, signal, programmes, serveur, noeud intermediaire et terminal correspondants |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US8743950B2 (fr) |
| EP (1) | EP1941734A1 (fr) |
| FR (1) | FR2889017A1 (fr) |
| WO (1) | WO2007009996A1 (fr) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| MX2009004121A (es) * | 2006-10-20 | 2009-06-08 | Nokia Corp | Indicacion generica de trayectos de adaptacion para multimedia escalable. |
| EP2037683A1 (fr) * | 2007-09-17 | 2009-03-18 | Alcatel Lucent | Processus pour administrer à un terminal de média un flux vidéo adapté grâce à un noeud d'accès |
| US8155184B2 (en) * | 2008-01-16 | 2012-04-10 | Sony Corporation | Video coding system using texture analysis and synthesis in a scalable coding framework |
| GB0905184D0 (en) * | 2009-03-26 | 2009-05-06 | Univ Bristol | Encryption scheme |
| US8923403B2 (en) | 2011-09-29 | 2014-12-30 | Dolby Laboratories Licensing Corporation | Dual-layer frame-compatible full-resolution stereoscopic 3D video delivery |
| TWI595770B (zh) | 2011-09-29 | 2017-08-11 | 杜比實驗室特許公司 | 具有對稱圖像解析度與品質之圖框相容全解析度立體三維視訊傳達技術 |
| US20170104701A1 (en) * | 2015-10-08 | 2017-04-13 | Signal Vine, Llc | Systems and methods for providing a two-way, intelligent text messaging platform |
| CN110830762B (zh) * | 2018-08-13 | 2021-06-18 | 视联动力信息技术股份有限公司 | 一种音视频数据的处理方法和系统 |
| US10778938B2 (en) * | 2018-12-20 | 2020-09-15 | Hulu, LLC | Video chunk combination optimization |
| CN110147239B (zh) * | 2019-05-22 | 2023-03-21 | 苏州仙峰网络科技股份有限公司 | 游戏安装包体的多重压缩的方法、设备及存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2000065837A1 (fr) * | 1999-04-26 | 2000-11-02 | Telemedia Systems Limited | Acheminement en reseau de fichiers supports profiles vers des clients |
| US6233017B1 (en) * | 1996-09-16 | 2001-05-15 | Microsoft Corporation | Multimedia compression system with adaptive block sizes |
| WO2002031670A1 (fr) * | 2000-10-12 | 2002-04-18 | Teraglobal Communications Corp. | Procede et systeme de transmission de qualite de service selectionnable par le destinataire sur des reseaux |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5708473A (en) * | 1994-08-30 | 1998-01-13 | Hughes Aircraft Company | Two stage video film compression method and system |
| US5621660A (en) * | 1995-04-18 | 1997-04-15 | Sun Microsystems, Inc. | Software-based encoder for a software-implemented end-to-end scalable video delivery system |
| US5844613A (en) * | 1997-03-17 | 1998-12-01 | Microsoft Corporation | Global motion estimator for motion video signal encoding |
| CA2252170A1 (fr) * | 1998-10-27 | 2000-04-27 | Bruno Bessette | Methode et dispositif pour le codage de haute qualite de la parole fonctionnant sur une bande large et de signaux audio |
| US20020073238A1 (en) * | 2000-11-28 | 2002-06-13 | Eli Doron | System and method for media stream adaptation |
| KR100834748B1 (ko) * | 2004-01-19 | 2008-06-05 | 삼성전자주식회사 | 스케일러블 비디오 스트림 재생 방법 및 장치 |
| KR100834749B1 (ko) * | 2004-01-28 | 2008-06-05 | 삼성전자주식회사 | 스케일러블 비디오 스트림 재생장치 및 그 방법 |
| EP1599046A1 (fr) * | 2004-05-19 | 2005-11-23 | THOMSON Licensing | Procédé de codage des données vidéo d'une séquence d'images |
| WO2006049412A1 (fr) * | 2004-11-01 | 2006-05-11 | Electronics And Telecommunications Research Institute | Procede de codage/decodage d'une sequence video en fonction d'une image b hierarchique au moyen d'une structure de groupe d'images ajustee adaptativement |
| US20060156363A1 (en) * | 2005-01-07 | 2006-07-13 | Microsoft Corporation | File storage for scalable media |
| US7538823B1 (en) * | 2005-09-23 | 2009-05-26 | Cirrus Logic, Inc. | Luminance/chrominance video data separation circuits and methods and video systems utilizing the same |
| US8175149B2 (en) * | 2005-11-21 | 2012-05-08 | Electronics And Telecommunications Research Institute | Method and apparatus for controlling bitrate of scalable video stream |
| FR2894421B1 (fr) * | 2005-12-07 | 2008-01-18 | Canon Kk | Procede et dispositif de decodage d'un flux video code suivant un codage hierarchique |
| FR2899758A1 (fr) * | 2006-04-07 | 2007-10-12 | France Telecom | Procede et dispositif de codage de donnees en un flux scalable |
| EP2060074A1 (fr) * | 2006-09-15 | 2009-05-20 | France Telecom | Procede et dispositif d'adaptation d'un flux de donnees scalable, produit programme d'ordinateur et equipement reseau correspondants |
-
2005
- 2005-07-19 FR FR0507690A patent/FR2889017A1/fr active Pending
-
2006
- 2006-07-18 WO PCT/EP2006/064382 patent/WO2007009996A1/fr active Application Filing
- 2006-07-18 US US11/996,196 patent/US8743950B2/en active Active
- 2006-07-18 EP EP06777838A patent/EP1941734A1/fr not_active Ceased
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6233017B1 (en) * | 1996-09-16 | 2001-05-15 | Microsoft Corporation | Multimedia compression system with adaptive block sizes |
| WO2000065837A1 (fr) * | 1999-04-26 | 2000-11-02 | Telemedia Systems Limited | Acheminement en reseau de fichiers supports profiles vers des clients |
| WO2002031670A1 (fr) * | 2000-10-12 | 2002-04-18 | Teraglobal Communications Corp. | Procede et systeme de transmission de qualite de service selectionnable par le destinataire sur des reseaux |
Non-Patent Citations (4)
| Title |
|---|
| STEVEN MCCANNE ET AL: "Low-Complexity Video Coding for Receiver-Driven Layered Multicast", IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, IEEE SERVICE CENTER, PISCATAWAY, US, vol. 15, no. 6, August 1997 (1997-08-01), XP011054678, ISSN: 0733-8716 * |
| THOMAS RATHGEN ET AL: "ISO/MP4 File Format for Storage of Scalable Video", ISO/IEC JTC1/SC29/WG11 MPEG2005, April 2005 (2005-04-01), Busan, Korea, pages 1 - 27, XP002385303, ISSN: 0000-0001 * |
| TIHAO CHIANG ET AL: "HIERARCHICAL CODING OF DIGITAL TELEVISION", IEEE COMMUNICATIONS MAGAZINE, IEEE SERVICE CENTER,NEW YORK, NY, US, vol. 32, no. 5, 1 May 1994 (1994-05-01), pages 38 - 45, XP000451094, ISSN: 0163-6804 * |
| VAN DER SCHAAR M ET AL: "A novel MPEG-4 based hybrid temporal-SNR scalability for internet video", IMAGE PROCESSING, 2000. PROCEEDINGS. 2000 INTERNATIONAL CONFERENCE ON SEPTEMBER 10-13, 2000, PISCATAWAY, NJ, USA,IEEE, vol. 3, 10 September 2000 (2000-09-10), pages 548 - 551, XP010529525, ISBN: 0-7803-6297-7 * |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1941734A1 (fr) | 2008-07-09 |
| US20080310497A1 (en) | 2008-12-18 |
| WO2007009996A1 (fr) | 2007-01-25 |
| US8743950B2 (en) | 2014-06-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2007009996A1 (fr) | Procedes de filtrage, de transmission et de reception de flux video scalables, programmes, serveur, noeud intermediaire et terminal correspondants | |
| EP1839442B1 (fr) | Dispositifs et procedes de codage et de decodage echelonnables de flux de donnees d'images, signal, programme d'ordinateur et module d'adaptation de qualite d'image correspondants | |
| FR2939593A1 (fr) | Procede et dispositif de codage video | |
| FR2904494A1 (fr) | Procede et dispositif de compression d'image, systeme de telecommunication comportant un tel dispositif et programme mettant en oeuvre un tel procede | |
| FR2931610A1 (fr) | Procede et un dispositif de transmission de donnees d'images | |
| FR2903556A1 (fr) | Procedes et des dispositifs de codage et de decodage d'images, un systeme de telecommunications comportant de tels dispositifs et des programmes d'ordinateur mettant en oeuvre de tels procedes | |
| FR2909474A1 (fr) | Procede et dispositif de codage d'images numeriques et procede et dispositif de decodage d'images numeriques codees | |
| FR2864407A1 (fr) | Procede et dispositif de transmission continue d'une video dans un reseau de communication | |
| EP2052545B1 (fr) | Dispositif et procede de codage et de decodage echelonnables de flux de donnees d'images, signal et programme d'ordinateur correspondants | |
| EP3707900B1 (fr) | Procédé de formation d'une séquence d'images de sortie à partir d'une séquence d'images d'entrée, procédé de reconstruction d'une séquence d'images d'entrée à partir d'une séquence d'images de sortie, dispositifs, equipement serveur, equipement client et programmes d'ordinateurs associés | |
| FR2820255A1 (fr) | Procedes de codage et de decodage d'images, dispositifs, systemes, signaux et applications correspondants | |
| FR2932050A1 (fr) | Procede et dispositif de transmission de donnees video | |
| FR2959636A1 (fr) | Procede d'acces a une partie spatio-temporelle d'une sequence video d'images | |
| WO2009138656A2 (fr) | Transmission d'un flux video code par codage hierarchique | |
| FR2913163A1 (fr) | Procede et dispositif de transmission de donnees video | |
| WO2016046483A1 (fr) | Génération et codage d'images intégrales résiduelles | |
| EP2633686B1 (fr) | Codage video echelonnable a partir d'un epitome hierarchique | |
| EP2060074A1 (fr) | Procede et dispositif d'adaptation d'un flux de donnees scalable, produit programme d'ordinateur et equipement reseau correspondants | |
| WO2017085421A1 (fr) | Procédé de traitement de données codées, procédé de réception de données codées, dispositifs, et programmes d'ordinateurs associés | |
| 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 | |
| FR3041851A1 (fr) | Procede d'allocation de debit, dispositif, codeur et programme d'ordinateur associes | |
| Ramzan et al. | Scalable and Adaptable Media Coding Techniques for Future Internet. | |
| FR2913844A1 (fr) | Procede et dispositif d'allocation de debit dans une sequence video | |
| FR3153178A1 (fr) | Procédé et dispositif de codage et décodage de séquences d’images. | |
| EP3481069A1 (fr) | Procédé et système de traitement d'un contenu multimédia dans un réseau de zone métropolitaine |