FR2949283A1 - Procede et installation pour marquer en temps reel un flux video compose d'une succession d'images video codees selon la norme mpeg-2. - Google Patents

Procede et installation pour marquer en temps reel un flux video compose d'une succession d'images video codees selon la norme mpeg-2. Download PDF

Info

Publication number
FR2949283A1
FR2949283A1 FR0955705A FR0955705A FR2949283A1 FR 2949283 A1 FR2949283 A1 FR 2949283A1 FR 0955705 A FR0955705 A FR 0955705A FR 0955705 A FR0955705 A FR 0955705A FR 2949283 A1 FR2949283 A1 FR 2949283A1
Authority
FR
France
Prior art keywords
video stream
macroblocks
image
bytes
modified
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.)
Granted
Application number
FR0955705A
Other languages
English (en)
Other versions
FR2949283B1 (fr
Inventor
Nicolas Belin
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.)
Neotion SA
Original Assignee
Neotion 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 Neotion SA filed Critical Neotion SA
Priority to FR0955705A priority Critical patent/FR2949283B1/fr
Publication of FR2949283A1 publication Critical patent/FR2949283A1/fr
Application granted granted Critical
Publication of FR2949283B1 publication Critical patent/FR2949283B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835Generation of protective data, e.g. certificates
    • H04N21/8358Generation of protective data, e.g. certificates involving watermark
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46Embedding additional information in the video signal during the compression process
    • H04N19/467Embedding additional information in the video signal during the compression process characterised by the embedded information being invisible, e.g. watermarking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/48Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using compressed domain processing techniques other than decoding, e.g. modification of transform coefficients, variable length coding [VLC] data or run-length data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing 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/2389Multiplex stream processing, e.g. multiplex stream encrypting
    • H04N21/23892Multiplex stream processing, e.g. multiplex stream encrypting involving embedding information at multiplex stream level, e.g. embedding a watermark at packet level
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4385Multiplex stream processing, e.g. multiplex stream decrypting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/44Receiver circuitry for the reception of television signals according to analogue transmission standards

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

Le principe de l'invention consiste à remplacer une image ou une partie d'image par une autre image ou une autre partie d'image, à la volée, c'est-à-dire sans décoder d'image. Ceci peut typiquement être utilisé pour insérer un code permettant d'identifier l'image à la manière d'une empreinte digitale : c'est le « fingerprinting ». Plus particulièrement, l'invention concerne un procédé pour marquer un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2, lesdites images codées étant constituées de plusieurs tranches de macroblocs organisées sous forme de lignes, ledit procédé étant caractérisé en ce qu'il consiste à : a) coder une information d'identification sous la forme d'un ou plusieurs macroblocs, b) identifier à la volée, dans le flux vidéo, au moins une image qui comporte un ou plusieurs macroblocs ne servant pas de référence pour le décodage des images suivantes et/ou précédentes dudit flux vidéo, c) sélectionner un ou plusieurs desdits macroblocs ne servant pas de référence, d) remplacer le ou les macroblocs ne servant pas de référence par le ou les macroblocs codant l'information d'identification.

Description

Procédé et installation pour marquer en temps réel un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2 Description Domaine technique de l'invention. L'invention a principalement pour objet un procédé et une installation permettant de marquer en temps réel, ou à la volée, un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2.
15 L'invention se rapporte au domaine technique général du traitement de données d'images vidéo codées selon la norme MPEG-2. Elle concerne plus précisément les techniques de marquage connues sous les termes anglais de fingerprinting ou watermarking , permettant de lutter contre le piratage et la contrefaçon de vidéos numériques. 20 État de la technique. Pour être transmise de façon efficace (transmission par satellite, 25 terrestre, ou câble), une vidéo numérique est compressée (ou codée) avec un standard de compression optimisé pour la vidéo par exemple selon les normes MPEG-2. Classiquement, le flux vidéo est composé d'une succession d'images vidéo codées selon la norme MPEG-2, lesdites images étant constituées de 10 2949283 -2
plusieurs tranches (ou slices en anglais) de macroblocs organisées sous forme de lignes.
Le développement des réseaux de communication (télévision numérique, 5 téléphonie mobile, Internet, ...) favorise la transmission et la diffusion de flux vidéo numériques vers une grande quantité d'unités de réception (téléviseur, téléphone mobile, ordinateur, ...). Cette augmentation des échanges s'accompagne hélas d'une augmentation des actes de contrefaçon et de piratage. Il est en effet courant qu'un utilisateur réceptionne ou télécharge à titre privé des données vidéo (typiquement un film, une émission de télévision, ...), et fasse une copie illicite de ces données qu'il distribuera ultérieurement à des personnes non autorisées. Il est également possible que l'utilisateur réceptionne à titre privé un contenu vidéo qu'il diffusera illégalement vers d'autres unités de réception. Il apparaît donc nécessaire de contrôler et de sécuriser la transmission et la diffusion des flux vidéo de façon à en protéger les auteurs.
Les techniques de marquage d'images vidéo numériques plus connues sous les termes anglais fingerprinting ou watermarking , permettent d'insérer une marque (ou une empreinte digitale ) sur une ou plusieurs images afin d'identifier leur provenance lorsqu'elles sont diffusées sur un réseau de communication. La marque peut être perceptible ou imperceptible lorsque la vidéo est jouée. On utilise ce marquage lorsque l'on souhaite pouvoir tracer une vidéo susceptible d'être diffusée illégalement, et plus spécifiquement pour identifier le contrefacteur présumé, c'est-à-dire le premier utilisateur qui a initialement reçu la vidéo et qui l'a ensuite diffusée de manière illégale. La marque insérée dans la vidéo numérique va dépendre de l'utilisateur qui la réceptionne, et il y aura autant de versions différentes d'une même vidéo qu'il y aura d'utilisateurs légitimes. Si ces utilisateurs légitimes diffusent par la suite illégalement la vidéo, l'analyse des marques permettra de facilement remonter jusqu'à eux. 2949283 -3 On connaît par les documents brevets EP 0.777.946 (MACROVISION), US 2005/0213826 (INTEL), WO 2005/114571 (THOMSON), GB 2.438.907 (SONY) ou encore WO 2007/098296 (VOBILE) diverses techniques permettant 5 d'insérer des données d'identification d'origine dans un signal vidéo. Ces méthodes de marquage connues de l'art antérieur apparaissent être complexes à mettre en oeuvre.
En tout état de cause, le marquage d'un flux vidéo codé en MPEG-2 est 10 dans la plupart des cas réalisé lorsque ledit flux est décompressé (ou décodé). En effet, il faut souvent décoder tout le flux pour accéder à un seul macrobloc correspondant à un endroit bien précis de l'image à modifier. De plus, le marquage à la volée d'un flux compressé apparaît être plus délicat et plus complexe, car la modification d'une image codée selon la norme MPEG-2 peut 15 être néfaste si elle sert de référence pour le décodage des images suivantes et/ou précédentes dudit flux. C'est pour ces raisons qu'il est plus courant de marquer une image décodée plutôt qu'une image codée.
Face à cet état des choses, le principal objectif de l'invention est de 20 proposer un procédé permettant de modifier rapidement et simplement certains éléments d'un flux vidéo codé selon la norme MPEG2 afin de marquer certaines images originelles à la volée, c'est-à-dire sans qu'il soit nécessaire de décoder ledit flux. Un autre objectif de l'invention est de proposer un procédé permettant de 25 sélectionner rapidement une image originelle du flux vidéo qui ne sert pas de référence pour le décodage des images suivantes et/ou précédentes dudit flux afin de la remplacer entièrement ou partiellement par l'information d'identification servant au marquage. Encore un autre objectif de l'invention est de proposer un procédé 30 permettant de marquer une image originelle du flux vidéo qui sert à priori de référence pour le décodage des images suivantes et/ou précédentes dudit flux. 2949283 -4
L'invention a en outre pour objectif de proposer une installation permettant de facilement et rapidement mettre en oeuvre ce procédé. 5 Divulgation de l'invention. La solution proposée par l'invention est un procédé pour marquer un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2, lesdites images codées étant constituées de plusieurs tranches de 10 macroblocs organisées sous forme de lignes, ledit procédé étant caractérisé en ce qu'il consiste à : a) coder une information d'identification sous la forme d'un ou plusieurs macroblocs, b) identifier à la volée, dans le flux vidéo, au moins une image qui 15 comporte un ou plusieurs macroblocs ne servant pas de référence pour le décodage des images suivantes et/ou précédentes dudit flux vidéo, c) sélectionner un ou plusieurs desdits macroblocs ne servant pas de référence, d) remplacer le ou les macroblocs ne servant pas de référence par le 20 ou les macroblocs codant l'information d'identification. Le principe de l'invention consiste à remplacer une image ou une partie d'image par une autre image ou une autre partie d'image, à la volée, c'est-à-dire sans décoder d'image. Ceci peut typiquement être utilisé pour insérer un code permettant d'identifier l'image à la manière d'une empreinte digitale : c'est 25 le fingerprinting . Plus particulièrement, l'invention consiste à analyser les images du flux vidéo pour identifier les macroblocs ne servant pas de référence. Le marquage est réalisé en modifiant ces derniers ou uniquement certains d'entre eux. L'analyse des macroblocs pouvant être réalisée à la volée, il est ainsi possible de marquer le flux vidéo sans avoir à le décoder. 30 - 5
Pour simplifier l'analyse des images, en cas de paquétisation du flux vidéo, on ne sélectionne préalablement que les données utiles à la vidéo.
Selon un premier mode de réalisation de l'invention, on sélectionne et on remplace seulement une partie d'une image qui n'est pas une image de référence pour le décodage des images suivantes et/ou précédentes du flux vidéo. Dans ce cas, l'étape b) est avantageusement réalisée en identifiant les images qui, dans l'ordre de décodage, ne sont pas utilisées ultérieurement comme référence, c'est-à-dire : • les images de type B, • et/ou les images de type P si, dans l'ordre de décodage, l'image suivante est de type I et la deuxième image suivante n'est pas de type B, • et/ou les images de type I si, dans l'ordre de décodage, l'image suivante est de type I et la deuxième image suivante n'est pas de type B.
Le marquage pourra alors être réalisé en remplaçant certains des macroblocs d'une image identifiée à l'étape b) par les macroblocs codant l'information d'identification.
Selon un second mode de réalisation de l'invention, on sélectionne et on remplace seulement une partie d'une image qui est une image de référence, c'est-à-dire une image qui comporte un ou plusieurs macroblocs servant de référence pour le décodage des images suivantes et/ou précédentes du flux vidéo. Dans ce cas, l'étape b) est avantageusement réalisée en identifiant sur l'image à marquer, un ou plusieurs macroblocs dont les pixels ne sont pas utilisés comme référence par les macroblocs des images suivantes. Le marquage pourra alors être réalisé en remplaçant les macroblocs identifiés, par les macroblocs codant l'information d'identification. - 6
Que ce soit le premier ou le second mode de réalisation de l'invention : - si le nombre de bits générés par les macroblocs codant l'information d'identification et générés par d'éventuels macroblocs de synchronisation, est égal au nombre de bits générés par les macroblocs remplacés, - et si les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre normatif d'octets, - alors les données du nouveau flux vidéo marqué peuvent rester paquetisées dans des paquets de transport ayant le même nombre normatif d'octets, et : • seuls les paquets de transport comportant des octets de données utiles modifiés, sont modifiés, • et seules les données utiles de ces paquets de transport modifiés sont modifiées.
De même : - si le nombre de bits générés par les macroblocs codant l'information d'identification et générés par d'éventuels macroblocs de synchronisation, est inférieur au nombre de bits générés par les macroblocs remplacés, - et si les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre normatif d'octets, - alors les données du nouveau flux vidéo marqué peuvent rester paquetisées dans des paquets de transport ayant le même nombre normatif d'octets, et : • chaque paquet de transport contenant des octets de données utiles modifiés, est modifié, • on rajoute à chaque paquet de transport modifié, un nombre adéquat d'octets de champs d'adaptation, de manière à obtenir un paquet de transport ayant le même nombre normatif d'octets.
En outre : - 7
- si le nombre de bits générés par les macroblocs codant l'information d'identification et générés par d'éventuels macroblocs de synchronisation, est supérieur au nombre de bits générés par les macroblocs remplacés, - et si les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre normatif d'octets, - alors les données du nouveau flux vidéo marqué peuvent rester paquetisées, les paquets de transport contenant des octets de données utiles modifiés étant enlevés et remplacés par de nouveaux paquets de transport ayant le même nombre normatif d'octets générés à partir desdits octets modifiés. Et si le nombre de paquets de transports générés est différent du nombre de paquets enlevés, alors tous les paquets de transports suivants seront modifiés de façon à ce qu'il n'y ait pas de discontinuité et que le nouveau flux vidéo marqué reste cohérent.
Que ce soit le premier ou le second mode de réalisation de l'invention, le paramètre incrément_adresse_macrobloc du premier macrobloc codant l'information d'identification ainsi que le paramètre incrément_adresse_macrobloc du premier macrobloc codé suivant le dernier macrobloc codant ladite information d'identification, pourront éventuellement être modifiés de façon à ce qu'ils permettent d'indiquer d'éventuels macroblocs sautés disposés de part et d'autre desdits macroblocs codant l'information d'identification.
Que ce soit le premier ou le second mode de réalisation de l'invention, un ou plusieurs macroblocs de synchronisation pourront éventuellement être rajoutés juste après les macroblocs codant l'information d'identification, lesdits macroblocs de synchronisation étant codés de sorte que les macroblocs suivant lesdits macroblocs codant l'information d'identification possèdent les mêmes données de prédiction qu'avant modification.30 - 8
Selon un troisième mode de réalisation de l'invention, on sélectionne et on remplace une image entière qui n'est pas une image de référence pour le décodage des images suivantes et/ou précédentes du flux vidéo. Dans ce cas : - l'étape a) est réalisée en codant l'information d'identification sous la forme d'une image vidéo codée en MPEG-2, - l'étape d) est réalisée en remplaçant l'image identifiée à l'étape b) par l'image codant l'information d'identification.
Dans le cas du troisième mode de réalisation : - si le nombre de bits générés par la nouvelle image codant l'information d'identification est égal au nombre de bits générés par l'image identifiée à l'étape b), - et si les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre normatif d'octets, - alors les données du nouveau flux vidéo marqué restent paquetisées dans des paquets de transport ayant le même nombre normatif d'octets, et : • seuls les paquets de transport comportant des octets de données utiles modifiés, sont modifiés, • et seules les données utiles de ces paquets de transport modifiés 20 sont modifiées.
De même : - si le nombre de bits générés par la nouvelle image codant l'information d'identification est inférieur au nombre de bits générés par l'image 25 identifiée à l'étape b), - et si les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre normatif d'octets, - alors les données du nouveau flux vidéo marqué restent paquetisées dans des paquets de transport ayant le même nombre normatif d'octets, et : 30 • chaque paquet de transport contenant des octets de données utiles modifiés, est modifié, - 9
• on rajoute à chaque paquet de transport modifié, un nombre adéquat d'octets de champs d'adaptation, de manière à obtenir un paquet de transport ayant le nombre normatif d'octets.
En outre : - si le nombre de bits générés par la nouvelle image codant l'information d'identification est supérieur au nombre de bits générés par l'image identifiée à l'étape b), - et si les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre normatif d'octets, - alors les données du nouveau flux vidéo marqué restent paquetisées, les paquets de transport contenant des octets de données utiles modifiés étant enlevés et remplacés par de nouveaux paquets de transport ayant le même nombre normatif d'octets générés à partir des octets modifiés.
En tout état de cause, si le nombre de paquets de transports générés est différent du nombre de paquets enlevés, alors on modifie tous les paquets de transports suivants de façon à ce qu'il n'y ait pas de discontinuité et que le nouveau flux vidéo marqué reste cohérent.
Un autre aspect de l'invention concerne un programme comportant des instructions exécutables par un processeur agencé dans une installation apte à recevoir un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2, lesdites instructions permettent de mettre en oeuvre le procédé conforme à l'invention pour marquer ledit flux vidéo.
Encore un autre aspect de l'invention concerne une carte d'extension configurée pour être insérée dans le port d'interface commune d'un récepteur de télévision numérique, ledit récepteur étant configuré pour recevoir un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2. Cette carte comporte avantageusement : 2949283 -10-
- une zone-mémoire dans laquelle est stocké un programme comportant des instructions permettant de mettre en oeuvre le procédé conforme à l'invention, - un processeur configuré pour exécuter les instructions dudit 5 programme pour marquer ledit flux vidéo.
Encore un autre aspect de l'invention concerne une installation pour marquer en temps réel un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2, ladite installation étant remarquable en ce 10 qu'elle comporte : - un moyen pour recevoir le flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2, - un décodeur configuré pour décoder ledit flux vidéo, - une zone-mémoire dans laquelle est stocké un programme 15 comportant des instructions permettant de mettre en oeuvre le procédé objet de l'invention, - un processeur configuré pour exécuter les instructions dudit programme et marquer ledit flux vidéo avant décodage.
20 L'installation est plus particulièrement un récepteur de télévision numérique équipé : - d'un moyen pour recevoir le flux vidéo, - d'un décodeur configuré pour décoder le flux vidéo, - d'un port d'interface commune configuré pour recevoir une carte 25 d'extension par laquelle transite ledit flux vidéo avant décodage. Conformément à l'invention, la carte comporte une zone-mémoire dans laquelle est stocké le programme comportant des instructions permettant de mettre en oeuvre le procédé conforme aux caractéristiques et un processeur configuré pour exécuter lesdites instructions pour marquer le flux vidéo avant 30 décodage. 2949283 -11-
Selon une autre caractéristique avantageuse de l'invention, le processeur de la carte d'extension est activé à distance par un code de commande intégré dans le flux vidéo lors de l'émission dudit flux vers le récepteur de télévision numérique. Description des figures.
D'autres objectifs, avantages et caractéristiques de l'invention 10 apparaîtront mieux à la lecture de la description d'un mode de réalisation préféré qui va suivre, en référence aux dessins annexés, réalisés à titre d'exemples indicatifs et non limitatifs et sur lesquels : - la figure 1 représente schématiquement la structure d'un flux vidéo codé selon la norme MPEG-2, 15 - la figure 2 schématise un exemple de relation entre des images d'un flux vidéo codé selon la norme MPEG-2, - la figure 3 montre un exemple de paquétisation du flux vidéo ainsi que la sélection des données utiles à la vidéo, - les figures 4a à 4d schématisent les différentes étapes permettant de 20 remplacer des macroblocs originels par des macroblocs codant l'information d'identification, - les figures 5a à 5d schématisent les différentes étapes permettant de remplacer des macroblocs originels, dont certains sont sautés, par des macroblocs codant l'information d'identification, 25 - la figure 6 est un organigramme représentant différentes étapes du premier mode de réalisation du procédé objet de l'invention, - la figure 7 un organigramme représentant différentes étapes du troisième mode de réalisation du procédé objet de l'invention, - la figure 8 schématise une installation conforme à l'invention. 5 30 2949283 -12- Modes de réalisation de l'invention. 1. Le standard MPEG-2. 5 Pour toute information détaillée sur la norme MPEG-2, l'homme du métier se reportera au document ITU-T-Recommandation H.262-ISO/IEC 13818-2 la décrivant.
La figure 1 donne un exemple de structure d'image utilisée. Dans le 10 standard MPEG-2, une séquence vidéo SEQ est composée de plusieurs groupes GOP d'images IM se succédant dans le temps. Chaque image IM est composée de plusieurs lignes horizontales L1, L2, ..., Ln, avec généralement n=36 pour un flux SD PAL. Chaque ligne est constituée d'une ou plusieurs tranches S regroupant des macroblocs M alignés de gauche à droite sans 15 recouvrement. Les tranches de macroblocs sont usuellement désignées par le terme anglais slice . Les macroblocs M sont des pavés de 16 pixels de largeur par 16 pixels de hauteur en luminance et de 8 pixels de largeur par 8 pixels de hauteur en chrominance. Les images IM sont donc composées de tranches S qui sont elles-mêmes composées de macroblocs M. 20 Dans la norme MPEG-2, on peut définir trois types principaux d'images : - les images I (ou Intra) : ce sont des images qui sont codées en utilisant seulement leur propre information. Ce sont des images codées indépendamment de leur contexte, c'est-à-dire que l'on ne tient compte que du 25 contenu de l'image elle-même et non des images environnantes. - les images P (ou Prédictive) : ce sont des images qui sont codées en utilisant leur propre information ainsi que les informations d'une image référence précédente. Elles utilisent la compensation de mouvement pour un meilleur taux de compression. 30 - les images B (ou Bi-prédictive) : ce sont des images qui sont codées en utilisant leur propre information ainsi que les informations de l'image 2949283 -13-
référence précédente et de l'image référence suivante. Elles ne sont jamais utilisées comme référence, contrairement aux images I et P.
La figure 2 donne un exemple de relation entre plusieurs images : 5 - l'image P4 utilise les informations de la première image référence précédente, c'est-à-dire de l'image 11 ; l'image P8 utilise les informations de la première image référence précédente, c'est-à-dire de l'image P4 ; - l'image B2 utilise les informations de la première image référence précédente, c'est-à-dire l'image de 11 et de la première image référence 10 suivante, c'est-à-dire de l'image P4 ; de même, l'image B3 utilise les informations de l'image 11 et de l'image P4 ; également, les images B5, B6 et B7 utilisent les informations de l'image P4 et de l'image P8. La figure 2 schématise en fait l'ordre d'affichage des images. Toutefois, l'ordre de décodage de ces images est différent puisqu'on comprend que pour 15 décoder l'image B2 par exemple, il faut d'abord décoder les images I1 et P4. En pratique, si l'ordre d'affichage des images est : I1-B2-B3-P4-B5-B6-B7-P8 alors l'ordre de décodage est le suivant : I1-P4-B2-B3-P8-B5-B6-B7.
Dans chaque tranche, les macroblocs sont encodés les uns après les 20 autres à l'aide de plusieurs procédés ou algorithmes permettant d'utiliser peu de bits. Les principaux procédés sont les suivants : - l'utilisation de la transformation DCT (pour Discrete Cosinus Transform en anglais), de la quantification, ainsi que d'une linéarisation spécifique des coefficients permettent généralement d'enlever les détails les 25 moins importants pour l'ceil humain et ainsi avoir moins d'information à encoder. - l'utilisation de la compensation de mouvement permet à partir de l'image précédente et/ou suivante (temporellement parlant) ainsi qu'à l'aide de données supplémentaires telles que les vecteurs de mouvement, de prédire la texture du macrobloc courant. Il suffit alors de coder la différence à l'aide du 30 procédé précédent. Le principe de ce codage repose d'une part, sur la compensation de mouvement : où se trouve le macrobloc dans l'image à t+1, 2949283 - 14 -
ressemblant le plus à un macrobloc donné à l'instant t, et d'autre part, sur le codage des erreurs entre les deux blocs correspondants, qui ne peuvent être parfaitement identiques. Ainsi, une fois calculés les vecteurs déplacement, un codeur s'en sert pour calculer les différences entre le macrobloc actuel et le 5 macrobloc de référence, pixel à pixel. - l'utilisation de codes de tailles variables (VLC) pour coder certains paramètres du macrobloc. Ainsi, pour chaque paramètre, les valeurs les plus fréquemment rencontrées sont codées en utilisant peu de bits et inversement les valeurs rarement rencontrées sont codées avec beaucoup de bits. 10 Dans les images I, seuls des macroblocs intra sont codés (pas de compensation de mouvement). Dans les images P, des macroblocs intra ou utilisant la prédiction de mouvement peuvent être codés. Lorsque le macrobloc est codé en utilisant la prédiction de mouvement, il utilise la compensation de 15 mouvement à l'aide de l'image référence précédente temporellement parlant. Dans les images B, des macroblocs intra, ou utilisant la prédiction de mouvement peuvent être codés. Lorsque les macroblocs sont codés en utilisant la prédiction de mouvement, celle-ci peut alors utiliser les informations de l'image référence précédente et/ou suivante temporellement parlant. Certains 20 macroblocs dans les images P et B peuvent être prédits sans qu'il soit nécessaire d'ajouter d'information supplémentaire. Ils peuvent alors être sautés (ou skipped en anglais).
25 2. Principe du procédé objet de l'invention. Le procédé objet de l'invention permet de marquer en temps réel, ou à la volée, un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2, lesdites images codées étant constituées de plusieurs 30 tranches de macroblocs organisées sous forme de lignes. Ce procédé consiste à: 2949283 -15-
a) coder une information d'identification sous la forme d'un ou plusieurs macroblocs, b) identifier à la volée, dans le flux vidéo, au moins une image qui comporte un ou plusieurs macroblocs ne servant pas de référence pour le 5 décodage des images suivantes et/ou précédentes dudit flux vidéo, c) sélectionner un ou plusieurs desdits macroblocs ne servant pas de référence, d) remplacer le ou les macroblocs ne servant pas de référence par le ou les macroblocs codant l'information d'identification. 10 Le codage de l'information d'identification sous forme d'un ou plusieurs macroblocs est réalisé au moyen d'un algorithme connu de l'homme du métier et par exemple un algorithme du type décrit précédemment. Typiquement, l'information d'identification se présente sous la forme d'un code binaire 15 permettant de visualiser un texte, une image, une suite de chiffres et/ou de lettres ou toute autre marque équivalente, lorsque la vidéo est décodée et jouée sur un écran. En particulier, l'information d'identification pourra être une suite de chiffres et/ou de lettres associée au numéro de série d'une unité de réception du flux vidéo ou associée à l'identité de son propriétaire. 20 Les autres étapes du procédé sont décrites plus en détail dans la suite de la description selon le cas d'espèce, sachant que ce procédé permet notamment de : - sélectionner et remplace seulement une partie d'une image qui n'est 25 pas une image de référence, - ou sélectionner et remplacer seulement une partie d'une image qui est une image de référence, - ou sélectionner et remplacer une image entière qui n'est pas une image de référence. 30 2949283 -16-
2.1. Cas où les données du flux vidéo sont initialement paquétisées dans des paquets de transport.
Lorsque le flux est paquétisé en utilisant, par exemple, la paquétisation 5 TS (pour Transport Stream en anglais), le flux est analysé afin de traiter uniquement les données MPEG2 utiles à la vidéo. Les entêtes et les données qui ne sont pas utiles à la vidéo sont ignorées. La paquétisation est décrite par le standard Transport Stream H.222. Pour plus d'information sur cette technique, l'homme du métier pourra se reporter au document ITU-T 10 Recommandation H.222.0 1 ISO/IEC 13818-1 . La paquétisation qui est utilisée ci-après dans les exemples de la présente invention, peut être décrite simplement en se rapportant à la figure 3 : chaque paquet PQ1, PQ2, PQ3 possède normalement 188 octets. Il est composé d'une en-tête, respectivement ET1, ET2, ET3, d'au moins quatre 15 octets regroupant des informations sur la paquétisation, d'un nombre variable d'octets de donnée utile, respectivement DU1, DU2, DU3, ainsi que d'éventuels octets de champs d'adaptation (ou adaptation field en anglais), respectivement CA1, CA2, CA3. Pour la paquétisation selon la norme H222, il est aisé de parcourir rapidement le flux vidéo est de sauvegarder uniquement les données 20 utiles DU1, DU2, DU3.
2.2. 1er mode : sélection et remplacement d'une partie d'une image qui n'est pas une image de référence. 25 Lorsque des données MPEG2 sont analysées, des séquences spécifiques de quatre octets appelées codes de début ou startcodes en anglais, sont recherchées. Les trois premiers octets d'un startcode ont pour valeur 0, 0 et 1. Le quatrième octet donne le type de startcode : code de début 30 d'image (ou picture_start_code en anglais), code de début de tranche (ou slice_start_code en anglais), code de fin de séquence (ou sequence_end_code 2949283 -17-
en anglais), etc. Les valeurs de ce quatrième octet sont données dans le document ITU-T-Recommandation H.262-ISO/IEC 13818-2 .
Lorsque le startcode est identifié, les informations suivants ce startcode 5 sont analysées et certaines stockées jusqu'à ce que l'on trouve un autre startcode. Ces informations stockées peuvent porter sur des données globales concernant la séquence entière ou seulement l'image suivante à décoder, etc.
Lorsque le startcode trouvé est un code de début d'image, les 10 informations suivants ce startcode sont analysées et certaines stockées temporairement dans une mémoire tampon, jusqu'à ce que l'on trouve un autre startcode relatif à un code de début d'image. Le stockage temporaire des informations est induit par les éventuelles relations bi-directionnelles des images : sauf pour les images de type B, on ne peut pas prédire si une image 15 va être utilisée comme référence sans avoir analysé les images précédentes et les images suivantes. Grâce aux informations analysées, on peut récupérer les données de toute une image et définir quel est son type (I, P ou B). En pratique, certaines informations suivant un code de début d'image comportent un code permettant d'identifier les types d'image (I, P ou B). 20 Pour réaliser l'étape b) du procédé objet de l'invention, on cherche alors à savoir si, dans l'ordre de décodage, l'image courante analysée ne va pas être utilisée comme référence pour les images suivantes. On connaît par exemple trois cas pour lesquels on sait que, dans l'ordre de décodage, les images ne 25 seront pas utilisées ultérieurement comme référence : • les images de type B, • et/ou les images de type P si, dans l'ordre de décodage, l'image suivante est de type I et la deuxième image suivante n'est pas de type B, • et/ou les images de type I si, dans l'ordre de décodage, l'image 30 suivante est de type 1 et la deuxième image suivante n'est pas de type B. 2949283 -18-
Le marquage de l'image identifiée est alors réalisé en remplaçant certains de ses macroblocs originels par les macroblocs codant l'information d'identification. Dans un but de simplification, l'étape c) du procédé objet de l'invention est avantageusement réalisée de la façon suivante : lorsqu'il est 5 déterminé que l'image entière ne sera pas utilisée comme référence, les startcodes relatifs aux slice_start_codes sont particulièrement recherchés : valeur des octets 0, 0, 1 puis numéro du slice compris entre 1 et OxAF (cf. le document ITU-T-Recommandation H.262-ISO/IEC 13818-2 ). L'analyse des slice_start_codes permet de sélectionner la tranche sur laquelle on va agir et 10 informe sur la position de ladite tranche dans l'image c'est-à-dire la valeur de la ligne dans laquelle elle est située. L'analyse des slice_start_codes permet en outre de savoir si ce qui suit est une autre tranche. Deux slice_start_codes vont plus précisément être recherchés. Le premier slice_start_code ayant pour numéro de tranche : tranche_voulue , 15 une valeur définie à l'avance par l'utilisateur, et le premier slice_start_code ayant pour numéro de tranche : tranche_voulue +1 . On stocke alors dans une mémoire tampon, les positions des octets de début (premier octet du premier startcode recherché) et de fin (dernier octet avant le deuxième startcode recherché). On connaît ainsi la position du premier octet et du dernier 20 octet de la ligne entière de macrobloc dans l'image donnée.
Il a ainsi été délimité une ligne entière donnée de macroblocs dans une image donnée. Toutefois, dans le cas où la ligne comporte plusieurs tranches, il est possible d'appliquer le raisonnement qui va suivre sur une seule de ces 25 tranches, et même sur une succession de macroblocs de cette tranche. Les paramètres de chaque macrobloc de cette ligne peuvent alors être analysés sans que ceux-ci n'aient besoin d'être reconstruits. Il est en effet inutile d'utiliser des procédés de quantifications, de DCT inverse, de compensation de mouvement ou autres, qui peuvent être habituellement 30 nécessaires pour reconstruire l'image. Cela permet de savoir simplement à quel octet précis et quel bit précis du flux vidéo, chaque macrobloc codé de la ligne 2949283 -19-
sélectionnée débute et/ou finit. Il est ainsi possible de garder les octets et bits des macroblocs dont le numéro est inférieur ou égal à une valeur définie à l'avance par l'utilisateur : macrobloc_stop, ajouter à la suite de ces données un nombre défini de macroblocs codant l'information d'identification ainsi que dans 5 certains cas (par exemple lorsque le décodage des nouveaux macroblocs ne donne pas les mêmes prédictions que les macroblocs originaux), un ou plusieurs macroblocs de synchronisation, puis ajouter à la suite des données des macroblocs de la ligne d'origine dont les numéros sont supérieurs ou égaux à une valeur définie à l'avance par l'utilisateur : macrobloc_start. 10 Les figures 4a à 4d illustrent un exemple de remplacement de macroblocs. On a délimité une ligne entière Lx de macroblocs M. On souhaite insérer les macroblocs codant l'information d'identification entre les macroblocs originels 7 et 14 : macrobloc_stop = 7 et macrobloc_start = 14. En se rapportant à la figure 4b, on a ainsi délimité trois parties P1, P2 et P3 dans la ligne Lx en 15 identifiant dans le flux vidéo analysé la fin du macrobloc originel 7 et le début du macrobloc originel 14. Conformément aux figures 4c et 4d, les bits codant les macrobloc originels 8, 9, 10, 11, 12 et 13 de la partie P2 sont enlevés et remplacés par les bits codant les macroblocs rajoutés 8', 9', 10', 11', 12' et 13'. Conformément à l'invention, la méthode consiste donc à remplacer un 20 certain nombre de macroblocs originels par un nombre défini de macroblocs codant l'information d'identification.
Dans le cas particulier du remplacement des macroblocs dès le premier macrobloc de la tranche, alors il n'y a pas de partie P1. Il n'y a donc pas besoin 25 de chercher le dernier macrobloc de la partie P1. Dans l'autre cas particulier où les macroblocs remplacés sont les derniers macroblocs de la ligne, alors, il n'y a pas de partie P3. Il n'y a donc pas besoin de chercher le premier macrobloc de la partie P3, ni d'utiliser des macroblocs de synchronisation. Dans un autre cas particulier où la ligne entière de macroblocs est remplacée, alors il n'y a pas 30 besoin d'analyser ladite ligne. Il suffit juste de remplacer cette dernière par la 2949283 - 20 -
ligne de macroblocs codant l'information d'identification. Et il n'est pas nécessaire d'utiliser des macroblocs de synchronisation.
Le paramètre incrément_adresse_macrobloc (ou 5 macroblock_address_increment en anglais) est une variable représentative de la différence entre la position absolue d'un macrobloc donné et la position absolue du dernier macrobloc non sauté. L'homme du métier pourra se rapporter au document ITU-T-Recommandation H.262-ISO/IEC 13818-2 pour une définition précise de ce paramètre. Le 10 paramètre macroblock_address_increment du premier macrobloc codant l'information d'identification (partie P2) ainsi que le paramètre macroblock_address_increment du premier macrobloc codé suivant le dernier macrobloc codant ladite information d'identification (partie P3), pourront éventuellement être modifiés de façon à ce qu'ils permettent d'indiquer 15 d'éventuels macroblocs sautés (ou skipped en anglais) disposés de part et d'autre desdits macroblocs codant l'information d'identification. Les figures 5a à 5d illustrent un exemple de remplacement de macroblocs dans une ligne comportant des macroblocs sautés. On a délimité une ligne entière Lx de macroblocs M. Les macroblocs 2, 5, 6, 7, 8, 12, 13, 14, 20 15 et 16 sont sautés. On souhaite insérer les macroblocs codant l'information d'identification entre les macroblocs originels 7 et 14 : macrobloc_stop = 7 et macrobloc_start = 14. En se rapportant à la figure 5b, on a ainsi délimité trois parties P1, P2 et P3 dans la ligne Lx en identifiant dans le flux vidéo analysé : - le dernier macrobloc codé 4 précédent le macrobloc sauté 7, 25 - et le premier macrobloc codé 17 suivant le macrobloc sauté 14. Conformément aux figures 5c et 5d, les bits codant les macroblocs originels 9, 10 et 11 de la partie P2 sont enlevés (les autres macroblocs de la partie P2 étant sautés) et remplacés par les bits codant les macroblocs rajoutés 8', 9', 10', 11', 12' et 13'. Les paramètres macroblock_address_increment des 30 macroblocs codés 8 et 17 sont modifiés pour tenir compte du nombre de macroblocs sautés précédents. 2949283 - 21 - Il est également possible de rajouter un ou plusieurs macroblocs de synchronisation, lorsqu'ils sont nécessaires, à la fin de la partie P2, lesdits macroblocs de synchronisation étant codés de telle manière que les 5 macroblocs 17 et 18 de la partie P3 possèdent les mêmes données de prédiction qu'avant modification, c'est-à-dire lorsque la ligne Lx n'avait pas été modifiée et que les macroblocs originels 9, 10 et 11 étaient encore présents. Cela concerne par exemple les prédictions du mouvement, la prédiction du coefficient DCT dans un macrobloc intra, le pas de quantification, etc. 10 Il peut être nécessaire d'analyser une ou plusieurs autres lignes supplémentaires. En effet, lorsqu'une ligne de macroblocs, ou une partie seulement, est modifiée, la taille horizontale de l'image modifiée peut aller de 16 pixels à la largeur de l'image (modulo 16). La hauteur de l'image modifiée 15 n'est que de 16 pixels. Pour avoir une hauteur plus grande, il faut analyser la ou les lignes de macroblocs suivantes et effectuer à nouveau la procédure décrite précédemment. La taille de l'information d'identification à rajouter n'est pas forcément un multiple de 16 en nombre de pixels. On détermine donc le nombre de lignes à analyser ainsi que le nombre de macroblocs à remplacer pour 20 chaque ligne de macroblocs de la manière suivante : - pour une valeur donnée de la hauteur de l'information d'identification à rajouter, on détermine la valeur supérieure ou égale à celle-ci qui est multiple de 16. On divise alors la valeur trouvée par 16 et cela donne le nombre de ligne à analyser ; 25 - pour une valeur donnée de la hauteur de l'information d'identification à rajouter, on détermine la valeur supérieure ou égale à celle-ci qui est multiple de 16. On divise alors la valeur trouvée par 16 et cela donne le nombre de macroblocs à remplacer.
30 Il est probable que le nombre de bits utilisés pour coder les macroblocs de l'information d'identification et les macroblocs de synchronisation éventuels, 2949283 - 22 -
ne soit pas le même que le nombre de bits utilisés pour coder les macroblocs originels remplacés. Trois cas sont possibles : soit le nombre de bits est égal, soit le nombre de bits est inférieur, soit le nombre de bits est supérieur. La modification possible du paramètre macroblock_address_increment à plusieurs 5 endroits de la ligne doit être également prise en compte dans le nombre de bits ajoutés ou enlevés à la ligne. Dans le cas où le nombre de bits générés par les macroblocs rajoutés est égal au nombre de bits générés par les macroblocs enlevés, alors les octets modifiés remplacent les octets originaux. Dans l'exemple où les données du 10 flux vidéo sont initialement paquétisées dans des paquets de transport ayant un nombre normatif d'octets (en pratique 188 octets normatifs pour la norme H222), alors les données du nouveau flux vidéo marqué peuvent rester paquetisées dans des paquets de transport ayant le même nombre normatif d'octets, et : 15 • seuls les paquets de transport comportant des octets de données utiles modifiés, sont modifiés, • et seules les données utiles de ces paquets de transport modifiés sont modifiées : pas de modifications des entêtes ni du champ d'adaptation (ou adaptation field en anglais). 20 Dans le cas où le nombre de bits générés par les macroblocs rajoutés est inférieur au nombre de bits générés par les macroblocs enlevés, alors les octets modifiés remplacent les octets originaux. Dans l'exemple où les données du flux vidéo sont paquétisées dans des paquets de transport ayant un nombre 25 normatif d'octets (en pratique 188 octets normatifs pour la norme H222), alors les données du nouveau flux vidéo marqué peuvent rester paquetisées dans des paquets de transport ayant le même nombre normatif d'octets, et : • chaque paquet de transport contenant des octets de données utiles modifiés, est modifié, 2949283 - 23 -
• on rajoute à chaque paquet de transport modifié, un nombre adéquat d'octets de champs d'adaptation, de manière à obtenir un paquet de transport ayant le même nombre normatif d'octets. Chaque paquet de transport contenant des octets de donnée utile 5 modifiés se voit donc modifié. En pratique, chaque paquet qui contenait avant modification des données utiles sera composé d'au moins un octet de donnée utile ainsi qu'un nombre adéquat d'octets de champs d'adaptation permettant d'obtenir un paquet de transport de 188 octets normatif. Il se peut que certains paquets n'aient pas besoin d'adaptation field. 10 Cette technique permet d'avoir au final le même nombre de paquets de transport possédant de la donnée utile qu'avant transformation. Ces paquets de transports obtenus remplacent alors purement et simplement les paquets de transport originaux.
15 Dans le cas où le nombre de bits générés par les macroblocs rajoutés est supérieur au nombre de bits générés par les macroblocs enlevés, alors les octets modifiés remplacent les octets originaux. Dans l'exemple où les données sont paquétisées dans des paquets de transport ayant un nombre normatif d'octets (en pratique 188 octets normatifs pour la norme H222), alors les 20 données du nouveau flux vidéo marqué peuvent rester paquetisées, les paquets de transport contenant des octets de données utiles modifiés étant enlevés et remplacés par de nouveaux paquets de transport ayant le même nombre normatif d'octets générés à partir desdits octets modifiés. Et si le nombre de paquets de transports générés est différent du nombre de paquets 25 enlevés, alors tous les paquets de transports suivants seront modifiés de façon à ce qu'il n'y ait pas de discontinuité et que le nouveau flux vidéo marqué reste cohérent. Il faut en effet dans certains cas modifier le paramètre compteur de continuité (ou continuity_counter en anglais) de manière à ce qu'il n'y ait pas de discontinuités ainsi que d'autres valeurs, comme le marquage temporel PTS 30 inclus dans le flux vidéo de manière à ce que celui-ci reste cohérent. En 2949283 - 24 -
pratique, on ne modifie pas les données utiles, mais uniquement les entêtes et les champs d'adaptation.
Les deux premiers cas (nombre de bits générés par les macroblocs 5 rajoutés est inférieur ou égal au nombre de bits générés par les macroblocs enlevés), sont, dans beaucoup de situations, plus simples à gérer que le troisième cas (nombre de bits générés par les macroblocs rajoutés est supérieur au nombre de bits générés par les macroblocs enlevés). Il existe plusieurs techniques permettant de réduire le nombre de bits des macroblocs 10 rajoutés dont : - utiliser une valeur de quantification grande, - en cas de codage de macroblocs intra, utiliser un coefficient DC proche de la prédiction, ledit coefficient DC correspondant à la luminance moyenne du bloc, 15 - utiliser des informations d'identification dont on sait qu'elles ne génèrent pas beaucoup de coefficient AC. Dans le cas où l'on voudrait écrire un texte, une police particulièrement adaptée peut être utilisée, par exemple une police type code-barre qui est particulièrement adaptée à la compression. Des formes simples et ne générant pas beaucoup de coefficients AC peuvent 20 également être utilisées : codes-barres, carrés, macroblocs de couleur unie (tout noir), etc.
La figure 6 est un organigramme récapitulatif représentant différentes étapes possibles du procédé objet de l'invention, dans le cas du premier mode 25 de réalisation décrit précédemment. Le flux vidéo F à marquer peut être initialement paquétisé P ou non paquétisé NP. Dans le cas où le flux est paquétisé, on analyse préalablement la paquétisation afin de ne traiter que les données utiles MPEG-2 (étape El). Après cette étape préalable, ou lorsque le flux n'est pas paquétisé, on recherche des startcodes et on sauvegarde des 30 données utiles (étape E2). Une image non référence à modifier a ainsi été sélectionnée. On recherche ensuite deux startcodes de tranches permettant de 2949283 - 25 -
localiser une ligne entière de macroblocs (étape E3). On analyse cette ligne en recherchant le dernier macrobloc codé de la partie P1 et le premier macrobloc codé de la partie P3 (étape E4). Lorsque ces deux macroblocs sont localisés, les macroblocs originels situés entre la partie P1 et la partie P3 sont 5 remplacés pas les macroblocs codant l'information d'identification et éventuellement par des macroblocs de synchronisation (étape E5). On obtient alors un flux non paquétisé modifié FNP'. Dans le cas où le flux était initialement paquétisé, on modifie les paquets contenant des données utiles modifiées (étape E6). Si cela est nécessaire, on ajoute des paquets et on 10 modifie des données de paquétisation dans les paquets suivants. On obtient alors un flux paquétisé modifié FP'.
2.3. 2nd mode : sélection et remplacement d'une partie d'une image qui est 15 une image de référence.
Dans le cas où une image à marquer est une image référence, c'est-à-dire une image qui comporte un ou plusieurs macroblocs servant de référence pour le décodage des images suivantes et/ou précédentes du flux vidéo alors, 20 l'ensemble des étapes décrites aux paragraphes précédents s'applique à ce cas particulier. Seule l'étape b) du procédé objet de l'invention diffère.
En pratique, on identifie sur l'image, un ou plusieurs macroblocs dont les pixels ne sont pas utilisés comme référence par les macroblocs des images 25 suivantes. On peut réaliser cela en analysant les valeurs de référence et de vecteurs de mouvement de chaque macrobloc de l'image suivante. Le marquage pourra alors être réalisé en remplaçant les macroblocs identifiés, par les macroblocs codant l'information d'identification. 30 2949283 - 26 -
2.4. 3eme mode : sélection et remplacement d'une image entière qui n'est pas une image de référence.
Dans ce cas, l'étape a) du procédé objet de l'invention est réalisée en 5 codant l'information d'identification sous la forme d'une image vidéo codée en MPEG-2, c'est-à-dire sous la forme d'un ensemble de macroblocs arrangés en tranches et en lignes.
De la même façon que décrite aux paragraphes précédents, pour réaliser 10 l'étape b) du procédé objet de l'invention, on cherche à savoir si, dans l'ordre de décodage, l'image courante analysée ne va pas être utilisée comme référence pour les images suivantes. Dans l'ordre de décodage, les images ne seront pas utilisées ultérieurement comme référence si : • les images de type B, 15 • et/ou les images de type P si, dans l'ordre de décodage, l'image suivante est de type I et la deuxième image suivante n'est pas de type B, • et/ou les images de type I si, dans l'ordre de décodage, l'image suivante est de type I et la deuxième image suivante n'est pas de type B.
20 Le marquage de l'image identifiée est alors réalisé en remplaçant l'ensemble des macroblocs originels par les macroblocs codant l'information d'identification (étapes c) et d)).
La nouvelle image remplaçant l'image d'origine peut par exemple 25 contenir deux types de macroblocs : - les macroblocs utilisant la prédiction de mouvement et faisant référence à une image précédemment décodée. Ils peuvent contenir des données telles qu'une valeur de vecteur de mouvement, des coefficients résiduels, ..., ou tout simplement être sautés, 2949283 - 27 -
- les macroblocs codant l'information d'identification se présentant sous forme d'image. Ils contiennent les données nécessaires à ce que, une fois l'image décodée, ils affichent le marquage.
5 Voici un exemple simple où le flux vidéo contient une image marquée : l'image remplaçant l'image sélectionnée contient uniquement des macroblocs sautés hormis aux endroits où l'on veut afficher l'image voulue par le marquage. Ces macroblocs peuvent être intra par exemple et coder une image totalement différente de la référence utilisée par les macroblocs sautés. Ainsi la nouvelle 10 image sera identique à l'image de référence utilisée sauf aux endroits ou les macroblocs ne seront pas sautés.
Il est ici également probable que le nombre de bits utilisés pour coder la nouvelle image ne soit pas le même que le nombre de bits utilisés pour l'image 15 originale. Trois cas sont possibles : soit le nombre de bits générés par la nouvelle image est égal au nombre de bits générés par l'image enlevée, soit le nombre de bits générés est inférieur, soit le nombre de bits est supérieur.
Dans le cas où le nombre de bits générés par la nouvelle image est égal 20 au nombre de bits générés par l'image enlevée, les octets modifiés remplacent les octets originaux. Dans l'exemple où les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre normatif d'octets (en pratique 188 octets normatifs pour la norme H222), alors les données du nouveau flux vidéo marqué restent paquetisées dans des 25 paquets de transport ayant le même nombre normatif d'octets, et : • seuls les paquets de transport comportant des octets de données utiles modifiés, sont modifiés, • et seules les données utiles de ces paquets de transport modifiés sont modifiées : pas de modifications des entêtes ni du champ d'adaptation (ou 30 adaptation field en anglais). 2949283 - 28 -
Dans le cas où le nombre de bits générés par la nouvelle image est inférieur au nombre de bits générés par l'image enlevée, les octets modifiés remplacent les octets originaux. Dans l'exemple où les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre 5 normatif d'octets (en pratique 188 octets normatifs pour la norme H222), alors les données du nouveau flux vidéo marqué restent paquetisées dans des paquets de transport ayant le même nombre normatif d'octets, et : • chaque paquet de transport contenant des octets de données utiles modifiés, est modifié, 10 • on rajoute à chaque paquet de transport modifié, un nombre adéquat d'octets de champs d'adaptation, de manière à obtenir un paquet de transport ayant le nombre normatif d'octets. Il se peut toutefois que certains paquets n'aient pas besoin de champs d'adaptation. Cette technique permet d'avoir au final le même nombre de paquets de 15 transport possédant de la donnée utile qu'avant transformation. Ces paquets de transports obtenus remplacent alors purement et simplement les paquets de transport originaux.
Dans le cas où le nombre de bits générés par la nouvelle image est 20 supérieur au nombre de bits générés par l'image enlevée, les octets modifiés remplacent les octets originaux. Dans l'exemple où les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre normatif d'octets (en pratique 188 octets normatifs pour la norme H222), alors les données du nouveau flux vidéo marqué restent paquetisées, les paquets de 25 transport contenant des octets de données utiles modifiés étant enlevés et remplacés par de nouveaux paquets de transport ayant le même nombre normatif d'octets générés à partir des octets modifiés. En tout état de cause, si le nombre de paquets de transports générés est différent du nombre de paquets enlevés, alors on modifie tous les paquets de 30 transports suivants de façon à ce qu'il n'y ait pas de discontinuité et que le nouveau flux vidéo marqué reste cohérent. Il faut en effet dans certains cas 2949283 - 29 -
modifier le paramètre continuity_counter de manière à ce qu'il n'y ait pas de discontinuités ainsi que d'autres valeurs comme le PTS inclus dans le flux vidéo de manière à ce que celui-ci reste cohérent. En pratique, on ne modifie pas les données utiles, mais uniquement les entêtes et les champs d'adaptation. 5 La figure 7 est un organigramme récapitulatif représentant différentes étapes possibles du procédé objet de l'invention, dans le cas du troisième mode de réalisation décrit précédemment. Le flux vidéo F à marquer peut être initialement paquétisé P ou non paquétisé NP. Dans le cas où le flux est 10 paquétisé, on analyse préalablement la paquétisation afin de ne traiter que les données utiles MPEG-2 (étape E10). Après cette étape préalable, ou lorsque le flux n'est pas paquétisé, on recherche et on sauvegarde des données utiles de manière à sélectionner une image non référence (étape E20). On remplace alors toute l'image par la nouvelle image (étape E30). On obtient alors un flux 15 non paquétisé modifié FNP'. Dans le cas où le flux était initialement paquétisé, on modifie les paquets contenant des données utiles modifiées (étape E40). Si cela est nécessaire, on ajoute des paquets et on modifie des données de paquétisation dans les paquets suivants. On obtient alors un flux paquétisé modifié FP'. 20
3. Autres aspects de l'invention et diverses mises en oeuvre du procédé objet de l'invention. 25 Il est possible d'envisager un programme comportant des instructions exécutables par un processeur agencé dans une installation apte à recevoir un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2, lesdites instructions permettent de mettre en oeuvre le procédé conforme à l'invention pour marquer ledit flux vidéo. 30 Plus particulièrement, on peut prévoir une carte d'extension, par exemple du type carte PCMCIA, configurée pour être insérée dans le port d'interface 2949283 - 30 -
commune d'un récepteur de télévision numérique, ledit récepteur étant configuré pour recevoir un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2. Cette carte comportera avantageusement : - une zone-mémoire dans laquelle est stocké un programme 5 comportant des instructions permettant de mettre en oeuvre le procédé conforme à l'invention, - un processeur configuré pour exécuter les instructions dudit programme pour marquer ledit flux vidéo.
10 Il est en outre particulièrement avantageux de prévoir une installation pour marquer en temps réel un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2. Cette installation pourra comporter : - un moyen pour recevoir le flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2, 15 - un décodeur configuré pour décoder ledit flux vidéo, - une zone-mémoire dans laquelle est stocké un programme comportant des instructions permettant de mettre en oeuvre le procédé objet de l'invention, - un processeur configuré pour exécuter les instructions dudit 20 programme et marquer ledit flux vidéo avant décodage.
En se rapportant à la figure 8, l'installation est préférentiellement un récepteur de télévision numérique équipé : - d'un moyen 10 pour recevoir le flux vidéo F, 25 - d'un décodeur 15 configuré pour décoder le flux vidéo F, - d'un port d'interface commune P configuré pour recevoir une carte d'extension C par laquelle transite ledit flux vidéo avant décodage. Conformément à l'invention, la carte C comporte une zone-mémoire 13 dans laquelle est stocké le programme permettant de mettre en oeuvre le 30 procédé objet de l'invention et un processeur 14 configuré pour exécuter les instructions dudit programme pour marquer le flux vidéo F avant décodage. 2949283 - 31 - En pratique, le récepteur de télévision est équipé d'une antenne, et/ou d'une parabole et/ou d'un câble, ou tout autre moyen 10 permettant de recevoir un signal de télévision numérique. Le signal reçu est alors dirigé vers un 5 syntoniseur 11 (ou tuner en anglais) permettant de sélectionner dans ledit signal, un flux vidéo spécifique modulé et codé selon la norme MPEG-2. A la sortie du syntoniseur 11, le flux vidéo sélectionné est démodulé via un démodulateur 12. Le flux démodulé transite alors par la carte d'extension C insérée dans le port d'interface commune P avant d'être décodé par le 10 décodeur 15 pour être joué sur l'écran du récepteur. La particularité de l'invention est que la carte C est configurée pour marquer le flux vidéo F avant décodage. Il est ainsi possible de marquer en temps réel le flux avant décodage, le marquage étant réalisé au même niveau que le contrôle d'accès dans un module indépendant du module de décodage.
15 Selon une autre caractéristique avantageuse de l'invention, le processeur 14 de la carte C est activé à distance par un code de commande intégré dans le flux vidéo lors de l'émission dudit flux vers le récepteur de télévision numérique. En pratique, un opérateur, lors de l'émission du signal de 20 télévision numérique, pourra intégrer dans ledit signal un code de commande qui activera ultérieurement le processeur 14 lorsque le flux vidéo sélectionné sera reçu par la carte C.

Claims (20)

  1. Revendications1. Procédé pour marquer un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2, lesdites images codées étant constituées de plusieurs tranches de macroblocs organisées sous forme de lignes, ledit procédé étant caractérisé en ce qu'il consiste à : a) coder une information d'identification sous la forme d'un ou plusieurs macroblocs, b) identifier à la volée, dans le flux vidéo, au moins une image qui comporte un ou plusieurs macroblocs ne servant pas de référence pour le décodage des images suivantes et/ou précédentes dudit flux vidéo, c) sélectionner un ou plusieurs desdits macroblocs ne servant pas de référence, d) remplacer le ou les macroblocs ne servant pas de référence par le ou les macroblocs codant l'information d'identification.
  2. 2. Procédé selon la revendication 1, dans lequel en cas de paquétisation du flux vidéo, on ne sélectionne préalablement que les données utiles à la vidéo.
  3. 3. Procédé selon l'une des revendications précédentes, dans lequel l'étape b) est réalisée en identifiant les images qui, dans l'ordre de décodage, ne sont pas utilisées ultérieurement comme référence, c'est-à-dire : • les images de type B, • et/ou les images de type P si, dans l'ordre de décodage, l'image suivante est de type I et la deuxième image suivante n'est pas de type B, 2949283 -33- • et/ou les images de type I si, dans l'ordre de décodage, l'image suivante est de type I et la deuxième image suivante n'est pas de type B. 5
  4. 4. Procédé selon l'une des revendications 1 ou 2, dans lequel si une image à marquer comporte un ou plusieurs macroblocs servant de référence pour le décodage des images suivantes et/ou précédentes du flux vidéo, l'étape b) est réalisée en identifiant sur ladite image, un ou plusieurs macroblocs dont les pixels ne sont pas utilisés comme référence par les 10 macroblocs des images suivantes.
  5. 5. Procédé selon l'une des revendications 3 ou 5 prises en combinaison avec la revendication 2, dans lequel : - si le nombre de bits générés par les macroblocs codant l'information 15 d'identification et générés par d'éventuels macroblocs de synchronisation, est égal au nombre de bits générés par les macroblocs remplacés, - et si les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre normatif d'octets, - alors les données du nouveau flux vidéo marqué restent paquetisées 20 dans des paquets de transport ayant le même nombre normatif d'octets, et : • seuls les paquets de transport comportant des octets de données utiles modifiés, sont modifiés, • et seules les données utiles de ces paquets de transport modifiés sont modifiées. 25
  6. 6. Procédé selon l'une des revendications 3 ou 5 prises en combinaison avec la revendication 2, dans lequel : - si le nombre de bits générés par les macroblocs codant l'information d'identification et générés par d'éventuels macroblocs de synchronisation, 30 est inférieur au nombre de bits générés par les macroblocs remplacés, 2949283 - 34 - - et si les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre normatif d'octets, - alors les données du nouveau flux vidéo marqué restent paquetisées dans des paquets de transport ayant le même nombre normatif d'octets, et : 5 • chaque paquet de transport contenant des octets de données utiles modifiés, est modifié, • on rajoute à chaque paquet de transport modifié, un nombre adéquat d'octets de champs d'adaptation, de manière à obtenir un paquet de transport ayant le même nombre normatif d'octets. 10
  7. 7. Procédé selon l'une des revendications 3 ou 5 prises en combinaison avec la revendication 2, dans lequel : - si le nombre de bits générés par les macroblocs codant l'information d'identification et générés par d'éventuels macroblocs de synchronisation, 15 est supérieur au nombre de bits générés par les macroblocs remplacés, - et si les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre normatif d'octets, - alors les données du nouveau flux vidéo marqué restent paquetisées, les paquets de transport contenant des octets de données utiles modifiés étant 20 enlevés et remplacés par de nouveaux paquets de transport ayant le même nombre normatif d'octets générés à partir desdits octets modifiés.
  8. 8. Procédé selon la revendication 7, dans lequel si le nombre de paquets de transports générés est différent du nombre de paquets enlevés, 25 alors tous les paquets de transports suivants sont modifiés de façon à ce qu'il n'y ait pas de discontinuité et que le nouveau flux vidéo marqué reste cohérent.
  9. 9. Procédé selon l'une des revendications 3 ou 5, dans lequel le 30 paramètre incrément_adresse_macrobloc du premier macrobloc codant l'information d'identification ainsi que le paramètre 2949283 - 35 - incrément_adresse_macrobloc du premier macrobloc codé suivant le dernier macrobloc codant ladite information d'identification, sont modifiés de façon à ce qu'ils permettent d'indiquer d'éventuels macroblocs sautés disposés de part et d'autre desdits macroblocs codant l'information d'identification. 5
  10. 10. Procédé selon l'une des revendications 3 ou 5, dans lequel un ou plusieurs macroblocs de synchronisation sont rajoutés juste après les macroblocs codant l'information d'identification, lesdits macroblocs de synchronisation étant codés de sorte que les macroblocs suivant lesdits 10 macroblocs codant l'information d'identification possèdent les mêmes données de prédiction qu'avant modification.
  11. 11. Procédé selon la revendication 3, dans lequel : - l'étape a) est réalisée en codant l'information d'identification sous la 15 forme d'une image vidéo codée en MPEG-2, - l'étape d) est réalisée en remplaçant l'image identifiée à l'étape b) par l'image codant l'information d'identification.
  12. 12. Procédé selon la revendication 11 prise en combinaison avec la 20 revendication 2, dans lequel : - si le nombre de bits générés par la nouvelle image codant l'information d'identification est égal au nombre de bits générés par l'image identifiée à l'étape b), - et si les données du flux vidéo sont initialement paquetisées dans des 25 paquets de transport ayant un nombre normatif d'octets, - alors les données du nouveau flux vidéo marqué restent paquetisées dans des paquets de transport ayant le même nombre normatif d'octets, et : • seuls les paquets de transport comportant des octets de données utiles modifiés, sont modifiés, 30 • et seules les données utiles de ces paquets de transport modifiés sont modifiées. 2949283 - 36 -
  13. 13. Procédé selon la revendication 11 prise en combinaison avec la revendication 2, dans lequel : - si le nombre de bits générés par la nouvelle image codant l'information 5 d'identification est inférieur au nombre de bits générés par l'image identifiée à l'étape b), - et si les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre normatif d'octets, - alors les données du nouveau flux vidéo marqué restent paquetisées 10 dans des paquets de transport ayant le même nombre normatif d'octets, et : • chaque paquet de transport contenant des octets de données utiles modifiés, est modifié, • on rajoute à chaque paquet de transport modifié, un nombre adéquat d'octets de champs d'adaptation, de manière à obtenir un paquet de 15 transport ayant le nombre normatif d'octets.
  14. 14. Procédé selon la revendication 11 prise en combinaison avec la revendication 2, dans lequel : - si le nombre de bits générés par la nouvelle image codant l'information 20 d'identification est supérieur au nombre de bits générés par l'image identifiée à l'étape b), - et si les données du flux vidéo sont initialement paquetisées dans des paquets de transport ayant un nombre normatif d'octets, - alors les données du nouveau flux vidéo marqué restent paquetisées, les 25 paquets de transport contenant des octets de données utiles modifiés étant enlevés et remplacés par de nouveaux paquets de transport ayant le même nombre normatif d'octets générés à partir des octets modifiés.
  15. 15. Procédé selon la revendication 14, dans lequel si le nombre de 30 paquets de transports générés est différent du nombre de paquets enlevés, alors on modifie tous les paquets de transports suivants de façon à ce qu'il 2949283 - 37 - n'y ait pas de discontinuité et que le nouveau flux vidéo marqué reste cohérent.
  16. 16. Programme comportant des instructions exécutables par un 5 processeur agencé dans une installation apte à recevoir un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2, caractérisé en ce que lesdites instructions permettent de mettre en oeuvre le procédé conforme à l'une des revendications 1 à 15 pour marquer ledit flux vidéo. 10
  17. 17. Carte d'extension configurée pour être insérée dans le port d'interface commune d'un récepteur de télévision numérique, ledit récepteur étant configuré pour recevoir un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2, caractérisée en ce qu'elle 15 comporte : - une zone-mémoire dans laquelle est stocké un programme comportant des instructions permettant de mettre en oeuvre le procédé conforme à l'une des revendications 1 à 15, - un processeur configuré pour exécuter les instructions dudit programme 20 pour marquer ledit flux vidéo.
  18. 18. Installation pour marquer en temps réel un flux vidéo composée d'une succession d'images vidéo codées selon la norme MPEG-2, caractérisée en ce qu'elle comporte : 25 - un moyen pour recevoir un flux vidéo composé d'une succession d'images vidéo codées selon la norme MPEG-2, - un décodeur configuré pour décoder ledit flux vidéo, - une zone-mémoire dans laquelle est stocké un programme comportant des instructions permettant de mettre en oeuvre le procédé conforme à l'une 30 des revendications 1 à 15, 2949283 - 38 - - un processeur configuré pour exécuter les instructions dudit programme pour marquer ledit flux vidéo avant décodage.
  19. 19. Récepteur de télévision numérique équipé : 5 - d'un moyen (10) pour recevoir un flux vidéo (F) composé d'une succession d'images vidéo codées selon la norme MPEG-2, - d'un décodeur (15) configuré pour décoder le flux vidéo, - d'un port d'interface commune (P) configuré pour recevoir une carte d'extension (C) par laquelle transite ledit flux vidéo avant décodage, 10 caractérisée en ce que ladite carte comporte une zone-mémoire (13) dans laquelle est stocké un programme comportant des instructions permettant de mettre en oeuvre le procédé conforme à l'une des revendications 1 à 15 et un processeur (14) configuré pour exécuter lesdites instructions pour marquer ledit flux vidéo avant décodage. 15
  20. 20. Récepteur selon la revendication 19, dans lequel le processeur est activé à distance par un code de commande intégré dans le flux vidéo lors de l'émission dudit flux vers ledit récepteur de télévision numérique.
FR0955705A 2009-08-19 2009-08-19 Procede et installation pour marquer en temps reel un flux video compose d'une succession d'images video codees selon la norme mpeg-2. Expired - Fee Related FR2949283B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0955705A FR2949283B1 (fr) 2009-08-19 2009-08-19 Procede et installation pour marquer en temps reel un flux video compose d'une succession d'images video codees selon la norme mpeg-2.

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0955705A FR2949283B1 (fr) 2009-08-19 2009-08-19 Procede et installation pour marquer en temps reel un flux video compose d'une succession d'images video codees selon la norme mpeg-2.

Publications (2)

Publication Number Publication Date
FR2949283A1 true FR2949283A1 (fr) 2011-02-25
FR2949283B1 FR2949283B1 (fr) 2012-03-30

Family

ID=41722715

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0955705A Expired - Fee Related FR2949283B1 (fr) 2009-08-19 2009-08-19 Procede et installation pour marquer en temps reel un flux video compose d'une succession d'images video codees selon la norme mpeg-2.

Country Status (1)

Country Link
FR (1) FR2949283B1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2960854A1 (fr) 2014-06-27 2015-12-30 Thomson Licensing Procédé et dispositif pour déterminer un ensemble d'éléments modifiables dans un groupe d'images

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0928110A2 (fr) * 1997-12-30 1999-07-07 Sarnoff Corporation Traitement d'un signal d'image pour l'insertion d'un filigrane électronique
EP1139660A1 (fr) * 1998-08-27 2001-10-04 International Business Machines Corporation Systeme permettant d'incorporer des informations additionnelles dans des donnees video, procede d'incorporation associe
WO2004006168A1 (fr) * 2002-07-09 2004-01-15 Kaleidescape, Inc. Filigranage numerique et dactyloscopie de contenu numerique a l'aide de blocs alternatifs pour incorporer des informations
US20060227873A1 (en) * 2005-04-11 2006-10-12 Toebes John A Digital watermarking of a media stream using coded macroblock types

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0928110A2 (fr) * 1997-12-30 1999-07-07 Sarnoff Corporation Traitement d'un signal d'image pour l'insertion d'un filigrane électronique
EP1139660A1 (fr) * 1998-08-27 2001-10-04 International Business Machines Corporation Systeme permettant d'incorporer des informations additionnelles dans des donnees video, procede d'incorporation associe
WO2004006168A1 (fr) * 2002-07-09 2004-01-15 Kaleidescape, Inc. Filigranage numerique et dactyloscopie de contenu numerique a l'aide de blocs alternatifs pour incorporer des informations
US20060227873A1 (en) * 2005-04-11 2006-10-12 Toebes John A Digital watermarking of a media stream using coded macroblock types

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HARTUNG F ET AL: "Digital watermarking of MPEG-2 coded video in the bitstream domain", ACOUSTICS, SPEECH, AND SIGNAL PROCESSING, 1997. ICASSP-97., 1997 IEEE INTERNATIONAL CONFERENCE ON MUNICH, GERMANY 21-24 APRIL 1997, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, vol. 4, 21 April 1997 (1997-04-21), pages 2621 - 2624, XP010225693, ISBN: 978-0-8186-7919-3 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2960854A1 (fr) 2014-06-27 2015-12-30 Thomson Licensing Procédé et dispositif pour déterminer un ensemble d'éléments modifiables dans un groupe d'images
EP2960855A1 (fr) 2014-06-27 2015-12-30 Thomson Licensing Procédé et dispositif pour déterminer un ensemble d'éléments modifiables dans un groupe d'images
US9607349B2 (en) 2014-06-27 2017-03-28 Contentarmor Method and device for determining a set of modifiable elements in a group of pictures

Also Published As

Publication number Publication date
FR2949283B1 (fr) 2012-03-30

Similar Documents

Publication Publication Date Title
EP0997042B1 (fr) Procede de marquage d'un signal numerique video compresse
FR2849567A1 (fr) Dispositif securise pour la diffusion, l'acces, la copie, l'enregistrement, la visualisation a la demande et la gestion des droits des images photographiques de type jpeg
WO2009080926A2 (fr) Procede de codage d'un flux video echelonnable a destination d'utilisateurs de differents profils
EP1477009B1 (fr) Dispositif pour securiser la transmission, l'enregistrement et la visualisation de programmes audiovisuels
WO2017089689A1 (fr) Procédé de traitement d'une séquence d'images numériques, procédé de tatouage, dispositifs et programmes d'ordinateurs associés
FR2952497A1 (fr) Procede de codage et de decodage d'un flux d'images; dispositifs associes
EP1470714B1 (fr) Dispositif securise pour le traitement des oeuvres audiovisuelles de haute qualite
EP1590959B1 (fr) Dispositif securise pour la diffusion, l ' enregistrement et la visualisation a la demande des oeuvres audiovisuelles au format de type mpeg-2 ts
FR2949283A1 (fr) Procede et installation pour marquer en temps reel un flux video compose d'une succession d'images video codees selon la norme mpeg-2.
EP3317799B1 (fr) Procédé de fourniture d'un contenu multimédia protégé
EP1289307B1 (fr) Méthode de codage vidéo
WO2021214395A1 (fr) Procédés et dispositifs de codage et de décodage d'une séquence vidéo multi-vues
CA3130555A1 (fr) Procede permettant de dissimuler des donnees dans une image ou un flux video a l'interieur d'une chaine de compression
FR2951344A1 (fr) Procede et installation pour marquer en temps reel un flux video compose d'une succession d'images video codees en mpeg-4 avc.
EP1590961B1 (fr) Procede et dispositif de protection pour la diffusion securisee d'oeuvres audiovisuelles
EP1554879B1 (fr) Dispositif pour la transformation de contenus multimedias et audiovisuels de type mpeg-2 en contenus securises de meme type
US20170251283A1 (en) Framework for embedding data in encoded video
WO2016009159A1 (fr) Compression intra-image par decomposition de l'image source en tuiles de pixels
Chen et al. A robust watermarking scheme for stereoscopic video frames
FR2857813A1 (fr) Methode d'insertion de marques de synchronisation dans un flux video, compatible avec un chiffrage par blocs
EP3170296B1 (fr) Procédé d'accès à un contenu multimédia protégé par un terminal
FR2931609A1 (fr) Procedes de codage et de decodage pseudo-hierarchiques et systemes associes.
FR2963528A1 (fr) Telediffusion d'une video stereoscopique
WO2009130425A2 (fr) Procédé d'insertion, de suppression, support d'enregistrement et codeur
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

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 7

ST Notification of lapse

Effective date: 20170428