DEA Imagerie Vision et Robotique (IVR)

Projet présenté par :

Tien TRAN THUONG

Superviseur :

Cécile ROISIN

Description de la structure des vidéos pour les applications multimédias

1 Introduction
2 État de l'art des modèles de description de vidéo et de leurs applications 

2.1 Introduction

2.2 MPEG7 

2.2.1 Objectifs et principes de Mpeg-7

2.2.2 Applications visées par Mpeg7 
2.2.3 Conclusion

2.3 AEDI v1.0 (Audio-visual Event Description Interface version 1.0)

2.3.1 Conclusion

2.4 Schéma de description de contenu vidéo basé sur Dublin Core

2.5 Projets de développement d'applications 

2.5.1 AGIR

2.5.2 Projet DICEMAN

2.6 Autres Travaux

2.7 Synthèse
3 Contexte du travail 

3.1 L'application VidéoPrep du projet Movi

3.1.1 Introduction à Vidéoprep

3.1.2 Fichier d'entrée de Vidéoprep 
3.1.3 Les structures résultant de vidéoprep 
3.1.4 Synthèse

3.2 L'application Madeus du projet Opéra

3.2.1 Organisation logique

3.2.2 Organisation hypermédia 
3.2.3 Organisation spatiale 
3.2.4 Organisation temporelle 
3.2.5 Synthèse sur l'environnement Madeus
4 Analyse de la structure Vidéo 

4.1 Structure de haut niveau de la vidéo

4.2 Structure d'occurrence 
4.3 Relations 

4.3.1 Relations temporelles

4.3.2 Relations spatiales 
4.3.3 Relations conceptuelles

4.4 Description des entités vidéo

4.4.1 Vidéo

4.4.2 Sequence 
4.4.3 Scene 
4.4.4 Shot 
4.4.5 Transition 
4.4.6 Event 
4.4.7 Class 
4.4.8 Occurrence 
4.4.9 Zone 
4.4.10 Camera Perspective 
4.4.11 ColorHistogram 
4.4.12 Relation
5 Description XML de la vidéo 

5.1 DTD Vidéo

5.1.1 Rel_Temporal élément

5.1.2 Rel_Spatial élément 
5.1.3 Eléments de la vidéo

5.2 Génération de la structure XML d'une vidéo à partir des fichiers de vidéoprep

5.2.1 Génération d'élément Vidéo

5.2.2 Génération d'élément Sequence 
5.2.3 Génération d'élément Scène 
5.2.4 Génération d'élément Plan 
5.2.5 Génération d'élément Transition 
5.2.6 Génération d‘élément Event 
5.2.7 Génération d'élément Class 
5.2.8 Génération d'élément Occurrence 
5.2.9 Génération d'élément Zone

5.3 Exemple

6 Application 
7 Conclusion 

7.1 Résumé du travail

7.2 Bilan 
7.3 Perspectives envisagées 
Annexe A
Annexe B
Annexe C
Annexe D
Bibliographie

1 Introduction

La vidéo est un média qui devient de plus en plus important dans le domaine de l'informatique. Jusqu'à présent la vidéo est considérée comme un objet de base (non décomposable) dans les documents multimédias. Cependant, de nombreuses applications demandent de disposer d'une information de granularité plus fine, par exemple pour l'indexation et la recherche par le contenu ou encore pour la composition avec d'autres objets média. L'objectif de notre travail est de permettre à l'utilisateur d'accéder à la structure interne de la vidéo. Pour cela nous avons spécifié un modèle de structuration de la vidéo qui se veut indépendant des applications. Cependant, pour valider nos choix de modélisation, nous l'avons expérimenté dans une application particulière. L'application visée dans un premier temps est l'édition et la présentation de documents multimédias. Ainsi, l'utilisateur pourra synchroniser des événements de la vidéo avec d'autres objets de base comme du texte, des images ou des sons.  

Dans ce rapport, nous analysons la structure des vidéos pour en déterminer les entités significatives ainsi que les relations entre ces entités. Nous proposons ensuite un modèle de la structure interne de la vidéo et une description de cette structure dans le langage de marquage XML [31]. Ce travail s'appuie sur une étude des travaux du domaine, en particulier des travaux de standardisation en cours.

Pour valider notre modèle de structure vidéo, nous l'avons intégré dans le système d'édition et de présentation de document multimédia, Madeus 2.0développé dans le projet Opéra [19]. Ainsi, une vidéo composite structurée peut être éditée et mise en relation avec d'autres médias de base dans un document Madeus 2.0. Pour éviter de saisir manuellement les informations de structure des vidéos, ces informations sont récupérées à partir des résultats de l'outil d'extraction de la structure de la vidéo, Vidéoprep développé dans le projet Movi [4].

 
Organisation du rapport 

La suite de ce rapport est organisée comme suit :

• la deuxième section effectue un état de l'art sur des modèles de description de vidéo et de leurs applications. Elle présente et essaie d'évaluer des travaux actuels de descriptions d'information multimédia ;
• la troixième section decrit le contexte de notre travail. Elle présente le projet Movi avec son outil Videoprep et le projet Opéra son outil Madeus ;
• la quatrième section présente ma contribution sur la description de la structure vidéo. Pour cela, il sera nécessaire de décrire au préalable l'analyse de la structure vidéo, sur laquelle s'effectue ma proposition d'un schéma de description de la structure vidéo;
• la cinquième section décrit notre schéma sous forme de DTD (Document Type Definition) XML. Nous decrivons ensuite la génération des descriptions XML à partir des informations résultant de Videoprep, ainsi qu'un exemple de document Madeus 2.0 contenant une vidéo composite ;
• la sixième section présente notre application basée sur notre schéma XML de description de la structure vidéo ;
• enfin, dans la conclusion nous effectuons le bilan de ce projet et proposons plusieurs perspectives à envisager.

2 État de l'art des modèles de description de vidéo et de leurs applications

2.1 Introduction

Aujourd'hui, l'information audiovisuelle est utilisée dans des secteurs de la vie courante de plus en plus nombreux et joue un rôle très important dans notre société moderne. Elle est captée par des détecteurs audio et visuels et elle est enregistrée dans des médias comme les films ou les bandes magnétiques en format analogique ou digital. Alors que jusqu'à présent l'information audiovisuelle était consommée directement par l'être humain, il y a de plus en plus de cas où elle est maintenant créée, échangée, récupérée, et réutilisée au travers d'applications informatiques comme par exemple :

• les images compréhensives (surveillance, vision intelligente, caméra intelligente, etc.),
• les conversions de média (parole vers texte, image vers parole, parole vers image, etc.),
• l'extraction d'informations (recherche rapide et efficace de types divers d'information multimédia demandés par l'utilisateur),
• le filtrage dans un flot de données audiovisuelles (pour recevoir seulement des éléments multimédias qui satisfont à des préférences utilisateur).

Par exemple, un code dans un programme télévision déclenche le début d'enregistrement de ce programme par un magnétoscope, ou un détecteur d'image déclenche une alarme quand un événement visuel survient. Le transcodage automatique peut être effectué à partir de l'interprétation d'une chaîne de caractères pour en produire une forme audibles, ou une recherche peut être effectuée dans un flot des données audio ou visuelles. Pour traiter ces applications, l'information audiovisuelle doit avoir été au préalable encodée de manière à permettre aux équipements ou ordinateurs d'effectuer les traitements demandés.

L'augmentation des besoins de traitements plus sémantiques de ces sources demande de développer de nouveaux formats de représentation des informations audiovisuelles. Ces traitements sont hors de portée des formats standards tels que Mpeg1, Mpeg2, Quicktime3, AVI, Mpeg4, Quicktime4, etc. Ce nouveau format doit être interprété et accédé facilement par des équipements ou des programmes informatiques. Par exemple, un détecteur d'images doit produire des données visuelles encodées non sous la forme de valeurs de pixels, mais selon un format d'objet associé à des mesures physiques et des informations temporelles. Ces données visuelles doivent être stockées et traitées pour être utilisées par les appareils de surveillance. De même les informations audiovisuelles associées à un programme TV doivent pouvoir être interprétées par un magnétoscope pour déclencher les actions correspondantes (début/fin d'enregistrement). De la même façon, des catalogues multimédia de vente en ligne peuvent être décrits de telle sorte qu'un programme informatique puisse les comprendre et répondre à toutes les questions des clients.

Plusieurs des travaux sont en cours pour créer de nouveaux formats de représentation des informations audiovisuelles pour répondre aux besoins décrits ci-dessus. Nous décrivons ci-dessous ceux qui nous paraissent les plus importants, soit parce que ce sont des activités de standardisation (Mpeg-7, Dublin Core), soit parce qu'ils couvrent des aspects intéressants.

2.2 MPEG7

Depuis octobre 1998, MPEG (Moving Picture Experts Group) [21] a commencé un nouveau travail pour offrir des solutions au problème décrit ci-dessus. Ce nouveau travail, appelé "Multimedia Content Description Interface" (Mpeg-7), vise à créer un standard de description des données multimédias qui répondront aux exigences opérationnelles qu'elles soient de nature temps réel ou non temps réel. Mpeg7 se veut suffisamment générique pour répondre aux besoins des plusieurs applications.

2.2.1 Objectifs et principes de Mpeg-7

Mpeg-7 s'attaque à la description standardisée des informations audiovisuelles, et seulement à cet aspect. Ces descriptions doivent permettre en particulier la recherche et le filtrage de données audiovisuelles. Pour ces descriptions, MPEG propose :

• Des descripteurs (Ds) qui présentent les parties distinctives ou des caractéristiques des données qui sont significatives à quelque chose ou quelqu'un (ex : un histogramme de d'intensité lumineuse, la moyenne des composants fréquents, le texte d'un titre, etc.),
• Des schémas de description (DSs) qui comportent en particulier des relations entre descripteurs permettant de spécifier des entités de plus haut niveau, pouvant aller jusqu'à un niveau sémantique,
• Un langage de définition de description (DDL)qui doit permettre en particulier la création des nouveaux schémas de description et, peut être, des descripteurs. Il doit permettre aussi la modification et l'extension des schémas de description et des descripteurs existants,
• Des formats de codage qui permettent de réaliser des fonctions comme la compression efficace, la correction d'erreur, l'accès direct, etc.
• La prise en compte des contraintes système et performance.

Pour mieux comprendre les principes de conception ci-dessus et les relations entre eux, la Figure 1 présente les relations entre Ds, DSs et DDL. Des données audiovisuelles à partir des sources matérielles sont specifiees sous forme de caractéristiques par le système d'observation ou l'utilisateur. Ces caractéristiques sont regroupées en descripteurs, c'est-à-dire un descripteur représente un ensemble des caractéristiques ou au moins une caractéristique. Les descripteurs sont utilisés pour créer des schémas de description. Un descripteur peut appartenir a plusieurs schémas. Un schéma peut être aussi defini à partir d'autres schémas. Finalement un schéma est défini par un langage de définition de description (DDL).

 
Figure 1 Présentation des relations entre Ds et DSs
 

La Figure 2 présente les principes d'une chaîne de traitement utilisant le standard Mpeg7. Cette chaîne inclut une extraction des caractéristiques (analyse), une phase de description, application (un moteur de recherche).

 
Figure 2 Chaine de traitement video avec Mpeg-7

2.2.2 Applications visées par Mpeg7

Mpeg-7 vise à répondre aux besoins de toutes les applications. Mais le document de travail traduit clairement l'existence dans le comité Mpeg7 de spécialistes de différents domaines applicatifs qui ont mis en avant leurs propres application : Mpeg7 Application document [22].

Les applications de Mpeg-7 sont divisées en 3 classes :

1. Les applications "pull" comme la consultation de bases vidéos.
2. Les applications "push" comme la télévision personnalisée pour lesquelles il faudra permettre des filtrages. Cette classe inclut aussi la présentation d'information multimédia qui demande d'être capable de présenter de façon intelligente et automatique un ensemble de documents.
3. Les applications spécialisées comme le téléshopping, l'édition multimédia, la commande référencée capteur, etc.

La Figure 3 (issue de [22]) explique la chaîne d'application de Mpeg7. Les boîtes carrées décrivent des processus comme le codage ou le décodage. Les boîtes circulaires représentent des éléments statiques comme une description. La grande boîte au milieu de la figure inclut les éléments standard de Mpeg7.

 
Figure 3 Présentation abstraite d'une application utilisant Mpeg-7

2.2.3 Conclusion

Mpeg-7 sera une description standardisée des divers types d'information multimédia. Cette description se sera associée au contenu des médias pour permettre aux matériels de rechercher rapidement et efficacement l'information demandée par les utilisateurs. Actuellement, Mpeg-7 est dans la phase de définition, il reste encore de nombreux points en cours de discussion (analyse des besoins, des contraintes, format d'utilisation : RDF, XML DTD, C++? ?). Mpeg-7 se trouve au c?ur de la plupart des travaux actuels pour la représentation et les applications de données audiovisuelles, comme nous allons décrire ci-dessous.

2.3 AEDI v1.0 (Audio-visual Event Description Interface version 1.0)

Audiovisuel Event Description Interface (AEDI) [1] est une application indépendante développée par l'équipe de recherche en indexation de l'Institut National de l'Audiovisuel (INA). Son objectif est de fournir :  

• un format de descriptions de contenus audiovisuels,
• un format d'échange de ces descriptions entre applications,
• un encodage permettant un contrôle facile des documents.

Les utilisations d'AEDI visées sont : l'échange de métadonnées, l'annotation de vidéo, la recherche et la récupération de contenu audiovisuel.

2.3.1 Modèle et sémantique

Une description de AEDI est exprimée le long de sa timeline. Une timeline est définie par une origine; une position sur cette timeline est appelée une timeref. Une timeref est donc la distance temporelle par rapport à l'origine.  

Le modèle de description de AEDI est une structure d'arbre (voir Figure 4) dont les éléments sont : des events, des layers et des units. Les events, les layers et les units ont des propriétés intrinsèques et des propriétés définies par les utilisateurs. La liaison entre des n?uds représente des propriétés qui peuvent référer d'autres objets.  

Layers 

Un layer objet est un point de vue de document ou une partie de ce document. Il permet de grouper logiquement des events, units et layers reliés. Un layer peut avoir les propriétés comme : contexte (context), bord temporel (mintime, maxtime), permettant de contenir des events en parallèles ou en séquentiels (overlapping, sorted), etc.

Events 

Un event a un début et une durée qui sont exprimés sur la timeline. Un event décrit une sous-partie continue de document, et peut être lui-même décomposé en layers. Par défaut, les propriétés d'un event sont valides pendant la durée de cet event. Un event peut avoir les propriétés comme : contexte courant (context), instant de début (time), durée (duration), permettant de contenir des sous-events en parallèles ou en séquentiels (overlapping, sorted), nom d'auteur(who), etc.

Units 

Un unit objet est utilisé pour décrire un aspect non temporel d'un document audiovisuel. Par exemple, un unit peut représenter, un lieu spécifique, un personnage, un orateur, une technique de caméra utilisée dans un plan. Un unit peut avoir les propriétés comme : nom (firstname,lastname), contexte (contexte), etc.  

 
 
Figure 4 Présentation en arbre d'une description AEDI

2.3.2 Format de document AEDI

Document de AEDI est compose de trois sections successives pouvant être décrites dans une notation BNF comme suit :

aediDocument ::= declarationSection

definitionSection

descriptionSection  

• declarationSection : la section de déclaration fournit des informations générales de description comme : nom du document (localid="Allocine"), la version courante d'AEDI (current_version="1.0"), la vitesse de présentation des images (timescale="24"), etc.
• definitionSection : la section de définition contient des définitions de tous les types, propriétés et modèles spécifiques pour utiliser les descriptions qui la suivent. Les utilisateurs AEDI peuvent étendre ce langage pour fournir des définitions nouvelles des types, propriétés et modèles. La définition de la section consiste en la définition des objets. Une définition d'objet peut être une définition de type (typeDefObject), une définition de propriété (propertyDefObject), ou une définition de modèle (modelDefObject). La notation BNF de cette section est :

DefinitionSection ::=(definitioObject)*

DefinitionObject ::=typeDefObject

| propertyDefObject

|modelDefObject  

Par exemple, une définition de la propriété title de type string dans la section de définition est :  

<definitionSection>

. . .

<propertyDefObject localid="title" globalid="/fr/ina/corpus/title" >

<basetype type="string"/>

</propertyDefObject>

. . .

</definitionSection>

• descriptionSection : la section de description contient des informations de la description des entités qui peuvent être des units, events and layers. La notation BNF de cette section est :

descriptionSection ::=(descriptionObject)*

descriptionObject ::= entityDefinition

("model:"<localid)?

("context:"<localid)?

(property)*

";"

entityDefinition ::=unitDefinition

| eventDefinition

| layerDefinition

Etc.

Par exemple, une description d'un event de type plan (modèle "shot"), à partir du layer "scène_1" de type scène dans la section de description est :

<descriptionSection>

. . .

<event localid="shot-1" time="19:54:56:0000" duration="00:00:32:0000" model="shot" context="scene-1"

<property propid="title" <![cdata[petite fille au téléphone]]</property

. . .

</event>

. . .

</descriptionSection>

2.3.3 Conclusion

Le langage de définition des descriptions d'AEDI a été expérimenté dans le prototype d'application d'AEDI [1]. Et il est encore en développement. Par comparaison avec Mpeg-7, AEDI visé à des objectifs plus précis "définir le format de présentation et d'échange pour le contenu audiovisuel". C'est pourquoi, AEDI présente les limites suivantes :

• Il ne permet pas de synchroniser des éléments multimédias pour la présentation et l'interaction comme SMIL, MHEG, PREMO, Hytime.
• Il ne peut pas décrire des métadonnées générales comme le permet RDF (Resource Description Framework) [?], car le jeu de propriété est limité.
• Ce n'est pas un métalangage avec lequel les utilisateurs peuvent spécifier leur propre schéma de description. La seule extensibilité possible est offerte à travers la section definitionSection, mais elle ne permet pas de s'affranchir du cadre de trois objets layer, event, unit.

2.4 Schéma de description de contenu vidéo basé sur Dublin Core

Dublin Core [9] est un ensemble d'éléments de métadonnées destiné à présenter des ressources du Web. Il est donc très général et peut s'appliquer en particulier à des données audiovisuelles. Les quinze éléments de Dublin Core ont été étendus de façon à utiliser des sous-éléments permettant de créer un schéma de description vidéo [10]. À un niveau élevé ces quinze éléments de Dublin Core peuvent être utilisés pour décrire des informations de nature bibliographique à propos du document (Par exemple, Title, Author, Contributor, Date, etc.). Pour aller plus loin dans la description des contenus, l'extension des quatre éléments (Type, Description Relation, Coverage) permet de décrire des informations de plus bas niveau (sequence, scene, shot, frame).  

La Figure 5 (extraite de [12]) présente la structure logique, structure des composants et leurs attributs de Dublin Core pour une proposition de schémas de description vidéo.

 
Figure 5 : La structure de hiérarchie et les attributs de la vidéo

Nous décrivons ci-dessous les quatre éléments étendus de Dublin Core pour décrire les vidéos de façon à permettre une organisation comme celle de la Figure 5.

1. DC.Type

Cet élément définit une catégorie de ressource. Dans [12], des ressources sont classifiées en une hiérarchie comme suivant :

Image
o Moving
§ Animation
§ Film
§ Feature
§ Musical
§ Animation
§ Documentary
§ Silent
§ Short
§ Staged
§ Performance
§ etc.
§ TV
§ Drama
§ Serial
§ Documentary
§ News
§ Current Affairs
§ Performance
§ Comedy
§ Children's
§ Review
§ Interview
§ etc.
o Photograph
o Graphic

Des documents d'un film et d'une vidéo peuvent être structurés suivants : sequences, scenes, shots, frames. Chaque sequence consiste en des scenes successives, chaque scene consiste en des shots successifs, chaque shot consiste en des frames successives, chaque frame peut être divisé en des régions représentant des personnages ou objets. La hiérarchie de la structure des documents vidéo est donc :  

o Sequence
§ Scene
§ Shot
§ Frame
§ Object/Actor/Person

Par exemple deux DC.Types, la première spécifie une scène dans une séquence d'un document, et la deuxième spécifie une image dans un plan d'une scène :  

DC.Type = "Image.Moving.Film.Documentary.sequence.scene" 
DC.Type = "Image.Moving.TV.News.sequence.scene.shot.frame"
1. DC.Description

Cet élément est un ensemble de descripteurs pour décrire les caractéristiques des contenus des ressources. Ainsi, chaque DC.Type possède un tel ensemble de descripteurs. Le tableau ci-dessous présente des exemples de description de type Image.Moving.*.sequence.scene.shot.

DC.Type	DC.Description.*	Allowable Formats
Image.Moving.*.sequence.scene.shot	DC.Description.Text DC.Description.Keyframe DC.Description.Camera.Dist DC.Description.Camera.Angle DC.Description.Camera.Motion DC.Description.Lighting DC.Description.OpenTrans DC.Description.CloseTrans	Text JPEG, GIF Controlled vocab. Controlled vocab. Controlled vocab., line Controlled vocab. Controlled vocab. Controlled vocab.

2. DC.Format

Cet élément définit le format des données de la ressource. Le format peut être choisi dans une liste qui est actuellement en cours de définition. Par exemple, sont déjà définis :  

DC.Format.type = 35mm film, VHS etc. 
DC.Format.colour.depth = 256 
DC.Format.length = 31 mins. 
DC.Format.vidéocodec = MJPEG, MPEG1, MPEG2, AVI, QT, etc. 
DC.Format.framerate = 25 
DC.Format.sound = Yes/No 
3. DC.Relation

Cet élément décrit les relations hiérarchiques de la structure. Il consiste en deux sous-éléments HasPart et IsPartOf qui sont paramètres par un attribut Content. Par exemple, la valeur de Relation de la scene3.2 peut être :

Relation.HasPart Content= shot3.2.1, shot3.2.2, shot3.2.3

Relation.IsPartOf Content= sequence3

4. DC.Coverage

Cet élément est utilisé pour décrire la localisation temporelle des clips, scenes, shots, etc dans une vidéo. Le format de valeur du temps peut être une durée (frame number), un temps de codage SMPTE ou un temps absolu à partir de début. Par exemple, le moment où une ressource est déclenchée peut être décrite de la façon suivante :  

Coverage.t.min scheme=SMPTE content="09:45:23;14" 
Coverage.t.max scheme=SMPTE content="09:45:32;1" 

De plus, les sous-éléments de Coverage, Coverage.x,Coverage.y, Coverage.z, Coverage.line, Coverage.polygon et Coverage.3D peuvent être utilisés pour décrire des localisations spatiales, des mouvements et des formes pour les objets/personnages.

Conclusion

Différentes propositions de schéma de description d'informations multimédias ont été basées les éléments du Dublin Core ci-dessus pour décrire des vidéos. Dans [12] quatre méthodes de spécification de l'organisation des éléments de vidéos exprimées avec Dublin Core sont étudiées :  

• Sous forme d'une DTD XML
• Sous forme d'une RDF (Resource Description Framework) Schéma
• Sous forme d'une DCD (Document Content Description) XML
• Sous forme d'une SOX (Schema for Object-Oriented) XML

La conclusion de cette étude est qu'aucun de ces schémas ci-dessus n'est suffisant pour décrire des documents multimédias complexes. Les schémas basés sur Dublin Core ne satisfont qu'un sous-ensemble de besoins de description. Par exemple, il ne peut pas décrire des relations spatiales, temporelles, conceptuelles, etc.  

Par comparaison à Mpeg-7, les descriptions proposées de Dublin Core se veulent plus spécifiques et opérationnelles. Bien que ne satisfaisant pas encore à tous les besoins de description d'informations multimédias qui se trouvent dans Mpeg-7 Requirements [22], elles pourraient constituer une première implémentation de Mpeg-7.

2.5 Projets de développement d'applications

Dans le contexte de l'accroissement des besoins de traitement plus sémantiques de données multimédias, le domaine de l'indexation et de la recherche de contenus multimédias donne lieu à de nombreux travaux. Dans cette section on présente les deux projets AGIR et DICEMAN qui sont représentatifs de cet axe de travail.

2.5.1 AGIR

AGIR (Architecture Globale pour l'Indexation et la Recherche) est projet ambitieux et récent, établi entre plusieurs établissements français (AAR, INA, CERESYS, IRIT, INRIA, INT, LIP-6, AFNOR). Il comporte toute la chaîne de traitement des données multimédias : extractions des signatures médias, langage de description multimédias et applications.  

L'objectif du projet est de développer des technologies et des outils nécessaires pour mettre en ?uvre une "Architecture Globale pour l'Indexation et la Recherche (AGIR)" par le contenu de données multimédia, conforme aux exigences exprimées dans le contexte de la normalisation internationale. La Figure 6 présente les composants principaux de cette architecture.

 
Figure 6 : Les composants d'AGIR 

Dans le cadre d'AGIR, l'enjeu global est d'obtenir des outils de production de descriptions basés sur la norme MPEG-7 pour les contenus multimédias. C'est pourquoi l'objectif d'élaboration d'un langage de description de contenu multimédia s'insère dans le travail officiel de normalisation Mpeg-7.

Le projet démarré en janvier 1999, pour une durée de 30 mois. Il comporte deux phases, articulées en juin 2000. Il est ambitieux et s'appuie sur les standards et technologies émergentes (Mpeg-7, algorithmes d'analyse automatique des signatures média). À un niveau plus modeste, le travail présenté dans un mémoire suit la même démarche en proposant une chaîne complète de traitement d'informations multimédias, mais pour une application différente.

2.5.2 Projet DICEMAN

Diceman (Distributed Internet Content Exchange using MPEG7 descriptors and Agent Negociation) est un projet européen qui vise à développer un modèle de référence pour l'indexation, la description et l'échange de contenus audiovisuels en se basant sur la future norme internationale MPEG-7, qui a débuté en avril 1998 pour une durée de deux ans. Les établissements participants sont : CSELT (IT), KPN (NL), Teltec (IE), IBM (DE), Riverland (BE), IST (PT), UPC (SP) et l'INA en France. Ce dernier est implique dans des actions de recherche développement, et de fourniture de contenus.  

L'objectif principal de Diceman consiste à permettre l'échange de contenus audiovisuels sur Internet, et répond donc à un problème majeur auquel sont confrontés les départements d'archives, leurs clients, et de manière plus générale, l'ensemble des détenteurs de contenus. Pour cela, le projet met en place des innovations techniques concernant :  

• la description et l'indexation de contenus audiovisuels;
• l'indexation automatique et semi-automatique;
• les interfaces utilisateur avancées pour l'indexation et la recherche;
• les bases de données multimédia indexées;
• la recherche et la négociation de contenus par agents.

Comme l'AGIR, Diceman participe au travail de normalisation international Mpeg-7 par son objective de la description et l'indexation de contenus audiovisuels. Le projet comporte aussi une chaîne complète de traitement des données multimédia : l'indexation, la description et l'interface utilisateur. Néanmoins le projet Diceman a l'objectif de créer une base de données audiovisuelles pour servir aux besoins d'échange et d'accès des informations audiovisuelles sur l'Internet. A part de l'AGIR, il vise à obtenir des outils de production des descriptions des informations audiovisuelles basés sur la norme Mpeg-7.

2.6 Autres Travaux

En plus les travaux ci-dessus, il existe de nombreux autres travaux concernant ce sujet. Quelques entre eux sont relativement anciens [29][33] ; tandis que d'autres [25][13] ont débuté à partir l'appel a proposition pour la normalisation internationale Mpeg-7 en octobre 1998. Ces derniers travaux visent à contribuer à la construction de la norme Mpeg-7. Nous décrivons ci-dessous quatre propositions représentatives.  

2.6.1 Vidéo Algebra

Dans [33] un modèle, appelé Vidéo Algebra, a été proposé. Dans ce modèle les vidéos sont décomposées en des expressions vidéo. Une expression vidéo représente une partie continue et temporelle d'une séquence vidéo comme des scènes, des plans, etc. Ces expressions vidéos sont créées, décrites, mises en relation entre elles par des opérations du modèle. Ce modèle fournit un ensemble complet d'opérations qui permettent de composer, rechercher, naviguer et jouer en derrière la Vidéo digitale. Les opérations sont classifiées en quatre catégories :  

• Creation définit une construction d'une expression vidéo a partir de la séquence vidéo.
• Composition définit des relations temporelles entre des expressions vidéo.
• Output définit la localisation spatiale et la sortie audio de l'expression vidéo.
• Description associe l'attribut content à l'expression vidéo pour la décrire.

Un prototype de segmentation des vidéos et de création de nouvelles présentations fondées sur ce modèle Vidéo Algebra a été développé. Ce travail a proposé un ensemble complet d'opérations dont les opérandes peuvent être des éléments temporels comme des plans, des scènes, etc. Ces opérations peuvent être étendues pour être appliquées dans les documents multimédias comme combinaison temporelle ou spatiale des médias (texte, image, audio, vidéo) dans le document.  

2.6.2 Vidéo structurée par ordinateur

Dans [29] une chaîne complète de traitement vidéo est proposé. Le modèle de traitement vidéo se compose trois étapes :

• Production et édition de la vidéo,
• Traitement de la vidéo,
• Visualisation interactive.

La première étape est la production et l'édition de la vidéo. La production obtient la source matérielle par une caméra. Les informations issues de la caméra (point de début, point d'arrêt, l'opération de caméra comme panning, zoom, tilting, etc.) sont les informations très importantes conservées pour la suite. Ensuite dans la phase édition les sources matérielles sont collectées, examinées, sélectionnées, pour finalement produire une séquence vidéo.  

La deuxième étape consiste au traitement de la vidéo. Elle se compose des phases : analyser la structure vidéo et la faire explicitement, et indexer la vidéo. Cette partie utilide des méthodes et des modèles de détection de coupure intéressants. La méthode de l'analyse de plan qui est la plus intéressante pour nous se compose deux méthodes : l'extraction des informations correspondant aux opérations de caméra, et l'extraction des informations de couleur présentes dans une image.  

La dernière étape est la visualisation interactive de la vidéo. L'interaction correspond à ce qu'on peut faire avec la vidéo comme : naviguer, éditer, chercher, analyser, et des autres fonctions qui peuvent être ajoutées.  

On se trouve dans ce travail une idée très intéressante que des informations de la caméra sont considérées comme les informations très importantes et sont enregistrées dans la source matérielle. Cela permet à des systèmes d'extractions de la structure vidéo de pouvoir récupérer ces informations de la camera. Il présente aussi les idées de déduction des mouvements de caméra à partir de séquences vidéo. Quelques méthodes d'analyse de couleur dans une image de séquence vidéo sont aussi présentées.  

2.6.3 Schéma de description de vidéo

Dans [25] un schéma de description de contenu d'image et de vidéo est présentée. Il constitue une proposition pour Mpeg-7. Ce schéma de description est défini en XML ce qui est également l'approche que nous proposons (voire section 5). Le schéma de description d'image décrit principalement des objets dans l'image avec le descripteur de base <object. Les atouts de ce schéma sont la capacité de présentation des objets physiques (un personnage, une table, etc. ) et logiques (face, homme, enfant, etc. ) avec l'attribut Type='PHYSICAL'/'LOGICAL', et la capacité de présentation de la structure hiérarchique physique (une face du personnage, un bras du garçon, etc) et logique (l'objet logique HumanFace se compose deux objets physiques de face de deux personnages) avec le descripteur <object-hierarchy. Par exemple, une description d'objet a la forme suivante :  

<object id='objet-1' type='PHYSICAL'</object> 

Le schéma de description de vidéo décrit principalement des événements dans la Vidéo avec le descripteur de base <event. Un événement peut être un plan, un groupe de plans successifs ou un groupe de plans discontinus. Pour décrire la structure hiérarchique (des plans dans un groupe) il utilise le descripteur <event_hierarchy. Par exemple, la description de la scène (scene1) et ses trois plans (shot1, shot2, shot3) dans la vidéo Allocine à la forme suivante :  

<event id='scene1' type='SCENE'</event>
<event id='shot1' type='SHOT'</event>
<event id='shot2' type='SHOT'</event>
<event id='shot3' type='SHOT'</event>
 
<event_hierarchy type='PHYSICAL'>
<event_node id='0' event_ref='scene1'>
<event_node id='1' event_ref='shot1'/>
<event_node id='2' event_ref='shot2'/>
<event_node id='3' event_ref='shot3'/>
</event_node>
</event_hierarchy>
 

<event_node> pressente un noeud dans l'arbre hiérarchique, ce n?ud est référencé à un événement par attribut event_ref.

Le schéma proposé n'est pas complet, il ne décrit pas les informations comme : les caractéristiques, la forme, les mouvements d'objet, les propriétés de la caméra, etc. L'idée d'utiliser un descripteur <event pour décrire tous les événements dans la vidéo (plan, scène, séquence, etc.) est intéressante, mais n'est pas suffisant, parce que le plan, la scène, la séquence, etc. sont des entités dans la vidéo qui ont des caractéristiques différentes. De plus, les plans, les scènes, les séquences peuvent être de plusieurs types différents qu'il est nécessaire de modéliser. On ne peut pas donc grouper tous ces événements sous le même descripteur. On se trouve aussi que cette idée est semblable a l'approche de AEDI avec layer et event objets. D'un autre côté, le modèle de description de la structure hiérarchique est très bien.  

2.6.4 Langage de définition de description pour Mpeg-7

Dans [13] un langage de définition de description (DDL) est présenté pour être une proposition de DDL pour Mpeg-7. Le schéma est construit principalement sous la forme d'un schéma RDF (Resource Description Framework) [5]. Il est complété par des relations, des spécifications spatiales et temporelles, et des capacités puissantes de description de types de données basés sur le schéma d'orienté objet SOX. Il utilise aussi des bonnes caractéristiques d'autres schémas comme SMIL, XML DTD. Par exemple, bloque parallèle et séquentiel <par et <seq de SMIL.  

Ce travail est d'un niveau plus élevé que les autres puisqu'il propose d'un langage de définition. Les autres ne créent qu'un ensemble de descripteurs spécifiques avec un schéma de description correspondant. Cependant, bien que plus complet ce langage ne peut pas décrire encore certains des aspects difficiles de ce sujet comme : les mouvements d'objet et les opérations de caméra.

2.7 Synthèse

Les travaux présentés ci-dessus ne se situent pas tous au même niveau :  

• Mpeg-7 vise à satisfaire tous les besoins et à être utilisable pour toutes les applications possibles de traitement de l'information audiovisuelle. Pour cela il offre un métalangage de haut niveau. Mais il est en phase de définition.
• Dublin Core propose aussi de couvrir un ensemble de besoins similaire et compatible avec Mpeg-7, mais la capacité de Dublin Core est encore limitée par ses schémas incomplets.
• AEDI vise à répondre à des besoins plus étroits et précis comme : l'échange de métadonnées, l'annotation de vidéo, la recherche et la récupération de contenu audiovisuel.
• Les applications visent à créer des chaînes différentes de traitement d'informations audiovisuelles qui appliqueront le futur format Mpeg-7.
• Les autres travaux actuels visent à contribuer de créer la normalisation internationale Mpeg-7.

Les travaux présentés ici sont tous en cours d'élaboration et donc leur évaluation est difficile. Nous voyons clairement que Mpeg-7 est le travail pivot qui recouvre tous les autres. Certains des autres travaux (Dublin Core, AEDI, video algebra) ont commencé avant Mpeg-7. Leurs résultats antérieurs ont été expérimentés dans des prototypes en général de portée limitée. Mais on peut constater que maintenant tous ces travaux visent à contribuer à créer Mpeg-7.  

A part Mpeg-7 qui n'a pas encore de résultat concret car en cours de définition, les autres travaux ont des limites. Par rapport à nos besoins, les limites les plus importantes sont la synchronisation temporelle et spatiale entre les composants de la vidéo qui est nécessaire à la composition multimédia s'est-à-dire avec les autres médias (image, texte, son). On peut dire qu'aucun des formats existants actuellement ne peut satisfaire ces besoins.  

Pour notre objectif qui est de décrire la structure des vidéos dans un environnement d'édition et de présentation de documents multimédias, nous allons tirer parti de ces travaux existants notamment sur la décomposition en entités : sequence, scene, shot, etc. et les compléter pour les aspects concernant les relations temporelles et spatiales (voir sections 4 et 5).

3 Contexte du travail

Avant de présenter le travail effectué dans le cadre ce DEA, je présente ci-dessous les projets dans lesquels il s'inscrit : le projet d'analyse de vidéo (Vidéoprep) effectué dans Movi, et le projet d'environnement auteur multimédia dans Opéra.

Mon travail se situe en effet dans le cadre d'une collaboration entre le projet Movi et Opéra. La collaboration porte sur le codage des structures issues de vidéoprep. A terme, un premier prototype sera disponible en XML et qui permettra de s'affranchir des codages ad hoc dans des fichiers de ces structures. Ceci permet d'utiliser les résultats de Videoprep pour l'édition de documents multimédia telle qu'elle est vue dans Opéra, et de façon plus large, pour tout traitement capable d'utiliser les relations extraites par Vidéoprep.

3.1 L'application VidéoPrep du projet Movi

Movi a développé des outils de mise en correspondance d'images fixes, outils basés sur des primitives de types segments de droites, sur des points d'intérêts et leurs signatures, sur des régions. Ces mises en correspondances permettent de retrouver, dans des espaces de recherche assez large, les formes les plus ressemblantes.

Vidéoprep est un outil qui extrait des informations de structure correspondant à une vidéo et qui comporte :

• Des regroupements d'images en plan
• Des objets dans ces plans
• Des descripteurs (actions, textes, ?) associés à ces objets
• Des classes d'équivalence d'objets (objets sémantiquement équivalents).

Les contributions scientifiques de Movi portent essentiellement sur les outils de mise en correspondance, principalement les images fixes à ce jour, et qui permettent la construction de ces classes d'équivalence.

3.1.1 Introduction à Vidéoprep

Vidéoprep est une application développée par le projet Movi et Vista de l?INRIA en collaboration et selon les spécifications d?Alcatel CRC. Ce logiciel permet de structurer une vidéo de manière semi-automatique et interactive. Cette structure s'effectue en trois étapes semi-automatiques :  

1. Le découpage en plans ;
2. L'extraction des zones correspondant à des champs d?intérêt, en particulier des zones en mouvement ;
3. La création de liens de ressemblance entre ces zones, en définissant les objets et en leur associant des informations de nature diverse.

Le logiciel permet à l'utilisateur de compléter manuellement cette structure.

Les principaux fichiers résultats sont décrits dans la Figure 7.

 
Figure 7 : Entrées et sorties de l'application vidéoprep.

Les fichiers de sortie de Vidéoprepcontiennent des informations sur la structure d'une vidéo. Cela permet aux applications indépendantes de Vidéoprep d'utiliser ces résultats de Vidéoprep.

3.1.2 Fichier d'entrée de Vidéoprep

Le fichier d'entrée de Vidéoprep a comme suffixe .vdo .Ce fichier contient des informations de description pour la vidéo à analyser comme :

PATH= chemin du répertoire du fichier vidéo

PREFIX= Préfixe du nom de fichier vidéo 
SUFFIX= suffixe du nom de fichier vidéo 
FIRST_IMAGE= Numéro de la première image de la vidéo 
LAST_IMAGE= Numéro de la dernière image de la vidéo 
WIDTH= Largeur de la présentation de la vidéo 
HEIGHT= Hauteur de la présentation de la vidéo 
IMAGE_PER_SECOND= Nombre d'images présentées par seconde 
DATA_VERSION= Numéro de version des fichiers résultat de vidéoprep, par exemple, DATA_VERSION= 1.1.1 les premières versions des fichiers résultats sont traitées.

Exemple: Le fichier d'entrée Allocine.vdo ci-dessous est utilisé pour analyser la vidéo allcine.mpg de l'exemple décrit en section 4.3.  

PATH=/home/zeus2/ttran/Projets/documents/vidéos/allocine/

PREFIX=allocine 
SUFFIX=.mpg 
FIRST_IMAGE=1 
LAST_IMAGE=902 
WIDTH=352 
HEIGHT=288 
IMAGE_PER_SECOND=25 
DATA_VERSION=1.1.1 

3.1.3 Les structures résultant de vidéoprep

L'ensemble des fichiers résultats de vidéoprep est constitué de cinq fichiers (les indices i, j, k sont les numéros de la version résultat) :  

• b_short.i: informations des plans extraits d'une vidéo comme : numéro séquentiel du plan, plan avec ou sans transition (1 ou 0), numéro de la première image du plan, numéro de la dernière image du plan, etc.
• b_zones.i.j: informations des objets extraits d'une vidéo comme : nom de la zone, commentaire de la zone, numéro de l?image, type de la zone (1=extraite automatiquement), abscisse et ordonnée d?un point appartenant à la zone. etc.
• b_maps.i.j: informations détaillant des objets sur chaque image comme : les numéros des images où sesituent les polygones, le nombre de sommets N de chaque polygone, N lignes donnant les coordonnées (x, y) de chaque sommet, etc.
• b_class.i.j.k: informations des classes qui représentent un groupe d'objets dans la vidéo comme : nom de la classe, commentaire de la classe, exécutable attaché à la classe, type de la classe, nombre de zone N dans cette classe, N ligne indiquant le numéro des zones de cette classe, etc.
• thumbi.ppm (les images).

Dans l'annexe A, la structure précise de ces différents fichiers est décrite. Elle est accompagnée d'exemples illustratifs.

3.1.4 Synthèse

L'ensemble des informations résultant de Vidéoprep est très intéressant et utilisable. Il peut être réutilisé par des applications simples, par exemple Vidéoclic. Cette application récupère l'ensemble de fichiers résultats de Vidéoprep pour permettre à l'utilisateur de naviguer dans la structure de la vidéo au niveau des plans et des objets vidéos. De plus, elle permet d'afficher des informations d'un objet vidéo quand l'utilisateur clique sur la zone d'affiche de l'objet sur l'écran.

Cependant pour des besoins de traitement plus complexes (cf. section 2) il est nécessaire d'une part enrichir ces informations et d'autre part de les rendre accessibles selon un format plus indépendant et plus exploitable. Par exemple, l'intégration de vidéos dans des documents multimédias de telle sorte que des événements de la vidéo soient synchronisés avec autres médias, ou la recherche et l'accès à des extraits de vidéo stockés dans des grandes bases de données. Le format actuel des informations résultant de Vidéoprep ne supporte pas ces besoins. Il est donc nécessaire de trouver un nouveau format pour les informations de Vidéoprep, ce qui constitue un des objectifs de mon DEA.

3.2 L'application Madeus du projet Opéra

Le projet Opéra s'intéresse aux documents électroniques : documents techniques, hypertextes, multimédia, etc. Opéra étudie des modèles de documents qui rendent compte à la fois de leur organisation logique, de leur présentation graphique, de leur enchaînement temporel et des contenus multimédias. Il met également au point des techniques d'édition et de présentation qui s'appuient sur ces modèles. Il développe actuellement un prototype d'un environnement d'édition et de présentation pour les documents multimédias qui s'appelle Madeus.

Le projet Opéra a abordé les recherches sur le multimédia depuis 1994 selon trois directions complémentaires : la modélisation de l'information temporelle [Layaïda97], la conception d'environnements auteur réellement conviviaux [JRT98] et [JRT98b] et la conception de systèmes de présentation multimédia performants [Sabry99]. Ces travaux sont expérimentés dans le système d'édition/présentation Madeus [JLRST98] caractérisé par une approche de spécification à base de contraintes. Il est en effet fondé sur les relations temporelles d'Allen, dont une partie a été adaptée au placement spatial. Le format source des documents Madeus est spécifié sous forme d'une DTD XML (Annexe B).

Les documents Madeus sont organisés autour de quatre dimensions, que nous présentons à travers un exemple complet, qui sera utilisé tout au long de ce rapport, dont le scénario est le suivant :

Nous souhaitons construire un document multimédia Introduction-Vidéo qui présente le contenu d'une vidéo. Le document comporte une introduction composée d'un élément texte Titre-Présentation, d'un élément sonore Musique et d'une scène Contenu-vidéo. La scène Contenu-vidéo contient une vidéo (video-Allocine), un élément texte Titre-vidéo qui présente le titre de la vidéo Allocine, trois éléments textes (txt-Scene1, txt-Scene2, txt-Scene3) qui présentent les scènes de la vidéo et treize éléments texte (txt-Shot1, txt-Shot2, ?, txt-Shot13) qui présentent les plans de la vidéo Allocine.

3.2.1 Organisation logique

L'organisation logique d'un document Madeus est décrite sous forme d'une hiérarchie de composants, les feuilles étant les éléments de base (texte, image, vidéo, son) du document. L'organisation logique de l'exemple Introduction-Vidéo est présentée dans la Figure 8.

Figure 8 : Structure logique du document Introduction-vidéo

3.2.2 Organisation hypermédia

Dans les documents Madeus, il est possible de définir des liens de navigation en spécifiant de façon classique une ancre de départ, une ancre d'arrivée (intra ou extra document) et le type du lien (renvoi, référence, annotation, etc.). La désignation d'un lien inter-documents s'effectue par la notion d'URL (Uniform Resource Locator) utilisée par le World Wide Web. La différence majeure par rapport aux systèmes hypertexte classiques réside dans la nature temporelle des documents. L'activation d'un lien peut ainsi provoquer soit l'interruption des activités en cours (avec ou sans retour), soit une inclusion d'une portion de scénario qui s'ajoute au scénario courant.

Dans l'exemple Introduction-Vidéo les éléments texte (txt-SceneX, txt-ShotX) sont des liens vers des documents externes désignés par leur URL.

3.2.3 Organisation spatiale

Cette dimension permet de décrire la disposition souhaitée des éléments du document sur l'écran. La spécification du placement spatial dans Madeus s'effectue par l'intermédiaire des attributs de positionnement Left et Top (Figure 9) qui définit la position spatiale absolue d'un élément de base. Les valeurs de ces attributs correspondent aux coordonnées en pixels du coin supérieur gauche de l'élément de base. Si cet attribut n'est pas spécifié, alors l'objet est positionné par défaut avec les coordonnées (0, 0).

<Vidéo Name ="video-Allocine"

FileName ="allocine.mpeg" 
Duration ="10" 
Left ="320" 
Top ="70" 
...
Figure 9 : Exemple de l'attribut de positionnement

Le placement spatial peut aussi s'effectuer par des relations spatiales pour spécifier le placement relatif entre les objets. Elles sont délimitées par les balises <Relations> et <Spatial>.  

<Relations>

<Spatial> 
<Top_spacing Interval1="Titre-vidéo" Interval2="vidéo-Allocine" 
Distance="10"/> 
<Left_spacing Interval1="txt-Scen1" Interval2="video-Allocine" 
Distance="30"/> 
<Botton_spacing Interval1="txt-Shot1" Interval2="txt-Scen1" 
Distance="5"/> 
. . . 
</Spatial > 
</Relations>
Figure 10 : Exemple de relations spatiales

3.2.4 Organisation temporelle

La présentation d'un document multimédia est orchestrée par son scénario temporel. Un soin particulier est donc apporté dans Madeus pour offrir à l'auteur les moyens de construire des scénarios complexes en utilisant des opérateurs temporels "intuitifs ". De plus, Madeus vérifie que le scénario ne contient pas d'incohérences temporelles susceptibles de rendre impossible sa présentation.

L'approche choisie la description du scénario temporel dans Madeus est une approche déclarative basée sur les contraintes d'intervalles d'Allen. L'idée sous-jacente à cette approche est que l'auteur spécifie ce qu'il souhaite obtenir comme placement temporel (A avant B, etc.) sans avoir à spécifier toutes les informations temporelles attachées aux éléments, comme leurs instants de début et de fin ou leur durée. Le scénario temporel d'un document est donc défini par un ensemble de relations entre les éléments d'un même élément composite. Par exemple,  

<Equals Interval1="Titre-video" Interval2="Video-Allocine" />

<Meets Interval1="Titre-presentation" Interval2="Contenu-video" />
<Finishes Interval1="Contenu-video" Interval2="Musique" />
<Starts Interval1="txt-Scene1" Interval2="Video-Allocine" /> 
Etc. 

En plus de ces relations, Madeus utilise deux opérateurs supplémentaires, parmin et parmaster, pour spécifier des relations de causalité entre les intervalles. Dans ces relations, deux intervalles commencent en même temps, A parmin B spécifie que le plus court interrompt le plus long, A parmaster B spécifie que la fin de A, désigné comme le maître de la relation, provoque la fin de B si et seulement si B n'est pas encore terminé. 

3.2.5 Synthèse sur l'environnement Madeus

L'utilisation des relations d'Allen et les relations de causalité permet aux auteurs de construire des documents complexes en offrant des opérateurs temporels "intuitifs ". De plus, cette approche permet de tenir compte de la flexibilité des objets, c'est-à-dire de leur capacité à être présentés avec des durées variables. En contrepartie, l'auteur peut spécifier des documents incohérents et donc il est nécessaire de mettre en ?uvre des mécanismes, qui sont présents dans Madeus, pour vérifier et maintenir cette cohérence.

De plus, on peut imaginer dans l'exemple de document Introduction-Vidéo, si on veut les éléments texte (txt-Scene1, txt-Scene2, txt-Scene3, txt-Shot1,?, txt-Shot13) commençant aux moments où les scènes ou les plans de la vidéo Allocine qu'ils représentent sont commencés et disparaissant aux moments où les scènes ou les plans sont terminés. Ce besoin demande de décomposer l'élément vidéo pour pouvoir synchroniser les objets médias (texte, son, image) dans Madeus avec des événements de la vidéo. Pour répondre à ce premier besoin (synchronisation temporelle des événements dans une vidéo avec d'autres objets media), il est très facile d'étendre l'environnement de Madeus. En effet, la syntaxe de Madeus est basée sur XML, ce qui permet simplement d'ajouter des sous-éléments de vidéo. Le modèle des relations temporelles dans Madeus est complet et suffisant pour décrire des relations temporelles entre des sous-éléments d'une vidéo. Pour aller plus loin (Synchronisation spatiale, recherche sur le contenu de la vidéo, navigation et édition de la structure vidéo, etc.) on doit développer des modèles et des outils plus complexes qui ne sont pas disponibles actuellement dans Madeus. Cela rejoint les objectifs de recherche décrits en section 2.  

4 Analyse de la structure Vidéo

Cette analyse s'appuie d'une part sur notre connaissance des informations extraite par Vidéoprep et d'autre part sur une réflexion relative à la sémantique de la vidéo et à son intérêt pour les applications (voir section 2).

4.1 Structure de haut niveau de la  vidéo

La structure la plus élémentaire d'une vidéo est une séquence d'images. Tous les éléments de la structuration définis ci-dessous sont repérés par rapport à ce flot de l'image.

On désignera par Vidéo une entité vidéo. Dans cette entité Vidéo, on distinguera des Scenes qui correspondent à des unités dramatiques de la vidéo. Une scene ont lieu toujours dans une periode continue : la bagarre au saloon, la promenade en montagne, etc. Dans des vidéos de taille plus grande, on a besoin de plus des Sequences qui correspondent à des unités dramatiques. Une séquence est un groupement de scènes qui se relient par leurs accélérations émotives [ 6] (voir Figure 11 et Figure 12).

Dans les scènes, on distinguera les Plans. Ils correspondent à une unité de prise de vue, avec ou sans mouvement de caméra, comme par exemple : gros plan sur le personnage, ou encore, panoramique de caméra qui suit la voiture. Entre deux plans, une séparation peut être plus ou moins complexe : soit un changement de plan (cut en anglais), qui est instantané et qui représente 90% des cas, ou soit une transition plus longue, donc caractérisée par une durée (voir Figure 13 et Figure 14).

On peut définir dans une vidéo des entités significatives comme des personnages, des éléments décors, des objets comme les voitures, les tables, etc. On peut également définir des objets de granularité plus fine : des parties d'éléments comme le bras du personnage. Ces entités sont regroupées au niveau de l'entité Vidéo et sont appelées des entités Class (voir Figure 11).

Chaque apparition d'une classe dans les images consécutives est appelée une entité occurrence. Les classes ont des occurrences dans différents plans. Toutes les occurrences apparaissant dans un plan sont stockées au niveau de ce plan (voir Figure 14).

On peut avoir de plus des entités Event. Un Event est une sous-séquence d'images de la vidéo qui représente un événement dans un plan, une scène ou une séquence et est rattaché au niveau du plan, de la scène ou de la séquence, par exemple, le déclenchement d?une explosion, manifestation, orage, etc. En particulier, Event décrit une période où des relations spatiales sont valables (voir Figure 13, Figure 14 et Figure 15).

 
Figure 11 : Structure d'une vidéo en séquences et classes. 
 
Figure 12 : Structure d'une séquence vidéo en scènes et en events 
 
Figure 13 : Structure d'une scène vidéo en plans et events. 
 
Figure 14 : Structure d'un plan vidéo. 
 
Figure 15 : Structure d'un occurrence, d'un event et d'une transition en séquences d'image. 
 
Figure 16 : Organisation générale d?une vidéo.

4.2 Structure d'occurrence

Une occurrence appartient d'une classe et elle est une suite de zones. Chaque zone est caractèrisé par des entités : forme, couleur, caméra et position (voir la Figure 17).

Figure 17 : structure d'occurrence.

Une forme se compose des caractèristiques comme suivantes :

• Une suite des points du contour,
• Une boite carrée minimale entoure la zone,
• L'orienté de l'axe principal de la zone,

Une couleur entité se compose une liste de couleurs et leurs fréquences

Une caméra entité est la prise de vue de caméra. Elle se compose des caractéristiques comme suivantes :

• Distance focale de caméra,
• Orientation de la caméra par rapport à objet,
• Distance de caméra à l'objet,
• Mouvement de caméra (panning, zooming, titling, etc.).

Une position entité est un point central de la zone.

4.3 Relations

Dans une vidéo on peut identifier des relations de plusieurs natures entre les composants de vidéo, comme :

· Relations temporelles.
· Relations spatiales.
· Relations conceptuelles.

4.3.1 Relations temporelles

Ce sont les relations qui relient des entités d'une vidéo dans l'ordre temporel défini par l'exécution de la vidéo. Il est nécessaire de décrire ces relations pour permettre de synchroniser des entités de vidéo avec d'autres objets d'un document multimédia. Les relations temporelles sont simples à déterminer peuvent être automatiquement calculées. Dans notre contexte, les informations résultats de vidéoprep sont suffisantes pour déterminer automatiquement les relations temporelles. Le langage de description de documents de Madeus 2.0 permet de décrire de nombreuses relations temporelles (principalement celles définies par Allen) qui sont uffisantes pour exprimer nos descriptions de relation temporelle entre les entités d'une vidéo.  

Ainsi, nous proposons d'utiliser les relations temporelles d'Allen[All83] :  

· A finishes B
· A starts B
· A overlaps B
· A during B
· A meets B
· A before B
· A equals B

Dans une première étape, on n'utilise que les relations A meets B, A during B, A starts B, A finishes B, A equals B.

4.3.1.1 Durée de présentation d'une image de la vidéo

Chaque image d'une vidéo est présentée selon une durée dépendant de la vitesse de cette vidéo. Par exemple, pour une vitesse de présentation de 25 images par seconde, chaque image de la séquence doit être affichée à l'utilisateur pour une durée de 40 millisecondes (voir Figure 18)

 
Figure 18 : Présentation de la séquence des images de la Vidéo.

4.3.1.2 Scénario temporel d'une Vidéo

Une vidéo est composée par plusieurs Séquences qui sont les unités de la Vidéo. Ces Séquences sont enchaînées par des relations temporelles pour créer la Vidéo.

La figure 10 décrit un scénario créé par des relations meets entre les séquences ainsi que les relations starts et finishes pour la synchronisation de début et de fin de la vidéo.

Figure 19 : Scénario temporel d'une Vidéo.

4.3.1.3 Scénario temporel d'une Séquence

La Séquence est l'unité la plus grande de la Vidéo, elle est composée de plusieurs Scènes. On utilise les relations temporelles Starts, Finishes, Meets, During de Madeus 2.0 pour enchaîner ces Scènes. Des Events sont attachés dans la séquence par la relation During.

Figure 20 : Scénario temporel d'une Sequence.

4.3.1.4 Scénario temporel d'une Scène

Une Scène est une suite des plans, on peut donc utiliser aussi les relations Starts, Finishes, Meets, During pour enchaîner des plans et attacher des Events à la Scène.

 
Figure 21 : Scénario temporel d'une Scene.

4.3.1.5 Scénario temporel d'un Plan

Un Plan est créé par une suite des images. La figure 13 décrit un scénario d'un Plan. Dans ce cas, il est plus complexe, parce qu'un Plan se compose plus d'éléments comme des Transitions, Occurrences, objets de description des relations spatiales Rels_sp et des Events. Ces éléments sont attachés au Plan par la relation During :

Figure 22 : Scénario temporel d'un Plan.

4.3.2 Relations spatiales

Les relations spatiales décrivent les positions entre des objets. La position spatiale des objets dans la vidéo est déjà définie par leurs coordonnées absolues, c'est pourquoi les relations entre des objets de la vidéo n'ont pas le but de spécifier un placement à réaliser pour ces objets, mais de décrire des relations spatiales existantes entre ces objets qui sont utiles pour caractériser des suites d'images. Le jeu de relations spatiales défini dans Madeus 2.0 n'est pas suffisant pour exprimer toutes les propriétés spatiales que l'on peut vouloir décrire entre des objets d'une vidéo. Les relations spatiales d'une Vidéo peuvent être décrites comme des entités de vidéo. Par exemple : La relation "Personnage A à droite de la voiture B pendant 10 seconds " peut être décrite par l'entité Rel_spatial avec le type de relation On_Right_Of de la manière suivante :  

Rel_spatial

Name : Rel_sp1

Type : On_Right_Of 
ObjetA : PersonnageA 
ObjetB : VoitureB 
Duration: 10s 
 

Le problème est que les relations spatiales entre des objets évoluent, et on fera l'hypothèse qu'elles sont statiques pendant une durée donnée. De fait, une relation est valide pendant une durée spécifiée dans le descripteur de la relation ; ces relations peuvent être des relations de haut niveau, comme à_Intérieur (inside) qui a une signification 3D non interprétable directement pour le système, et doit donc obligatoirement être fournie par le concepteur de façon interactive. Plus simples sont les relations visuelles, qui dans une certaine mesure pourront être calculées automatiquement, comme par exemple au_dessous_dans_image (Below_Of).

Dans la première étape de ce travail, on ne cherchera pas à développer complètement des relations spatiales. Il est intéressant de noter que pour ce travail de description des relations spatiales, on peut espérer exploiter les résultats de vidéoprep qui contiennent des informations permettant de calculer automatiquement des relations spatiales entre des objets vidéos dans une image. De plus, des travaux ont été menés dans Madeus pour exprimer des relations spatio-temporelles, c'est-à-dire des relations spatiales qui dépendent de l'existence de relations temporelles entre objets [30]. Ce type de relations devrait permettre de composer spatialement des objets vidéos avec d'autres objets dans les documents multimédia. Par exemple, on crée une bulle pour un personnage d'une vidéo et cette bulle peut bouger pour suivre les mouvements du personnage.

La liste des relations spatiales prises en compte dans cette version de DTD vidéo est la suivante : On_Left_of, On_Right_of, On_Top_of, Below_of, Inside, Touched_by, On_Right_Top_of, On_Left_Top_of, On_Left_Below_of, On_Right_Below_of, Intersect. Ces relations sont des composants d'un Rel_Spatial.

4.4 Relations conceptuelles

Ce sont les relations au niveau semantique comme des relations familiales, les relations sociales. Elles ne sont pas considérées dans cette étape de notre travail car il n'existe pas de moyen de les extraire automatiquement.

4.5 Description des entités vidéo

Dans cette section on présente un prototype de description des entités de la vidéo.

4.5.1 Vidéo

Une vidéo est représentée par une Vidéo objet qu'il se compose de plusieurs Séquences pouvant contenirplusieurs Scènes.

Descripteur syntaxique

Vidéo{

String Name

String Source 
String Duration 
Int Left 
Int Top 
Int Number_Image 
Sequence List_Sequence[ ] 
Class List_Class[ ] 
Int Rate 
String Title 
String Author 
String Format 
String Language 
String Abstract

}

Sémantiques de descripteur syntaxique 

· Name : Pour identifier une Vidéo

· Source : Chemin où on peut trouver la vidéo.

· Duration : Durée nominale de la vidéo, elle est égale à : Nombre d'image / Rate milliseconde

· Position (Left, Top) : la position de la présentation vidéo sur l'écran.

· List_Sequence : Liste des séquences de la vidéo. Par défaut une seule séquence par une vidéo.

· List_Class : Liste des classes des occurrences apparaissant dans la vidéo.

· Rate : Vitesse nominale de la vidéo (nombre d'images/seconde).

· Title : Nom de la vidéo donné par l'auteur

· Author : Auteur(s) de la vidéo

· Format : Format de stockage de la vidéo.

· Language : Langue de la vidéo

· Abstract : Résumé de la vidéo.

4.5.2 Sequence

Cet objet représente une séquence de la vidéo.

Descripteur syntaxique 

Sequence{

String Name

String Duration 
Scene List_Scene[ ] 
Int First_Image 
Int Last_Image 
String Comment

}

Sémantiques de descripteur syntaxique 

· Name : Pour identifier une séquence

· Duration : Durée nominale de la séquence.

· List_Scene : Liste des Scènes contenues.

· Comment : Commentaire de la séquence.

4.5.3 Scene

Cet objet représente une scène dans la vidéo.

Descripteur syntaxique 

Scene{

String Name

String Duration 
Shot List_Shot[ ] 
Event List_Event[ ] 
Int First_Image 
Int Last_Image 
String Comment

}

Sémantiques de descripteur syntaxique 

· Name : Pour identifier une scène

· Duration : Durée nominale de la scène.

· ListPlans : Plans qui la composent

· Sequence : Séquence de rattachement

· ListEvent : Liste de events qui sont attachés à cette scène.

· Comment : Commentaire de la scène.

4.5.4 Shot

Shot représente un plan dans vidéo séquence. Il est une séquence d'images. De plus, dans un shot il peut avoir des Occurrences, des Transitions, des Events ou des objets de relations spatiales Rel_sp.

Descripteur syntaxique 

Shot{

String Name

String Duration 
Enum Shot_Type {zoom-in, zoom-out, panning} 
If (Shot_Type="zoom-in" or Shot_Type="zoom-out") { 
Int Scale 
}else if (Shot_Type="panning") { 
Vector Direction 
} 
Int First_Image 
Int Last_Image 
String Key_Frame 
Boolean Is_Tranisition 
If (IsTransition) { 

Transition Shot_Transition

}

String Keyframe 
Occurrence List_Occurrence[ ] 
Event List_Event[ ] 
String Comment

}

Sémantique de descripteur syntaxique 

· Name : Pour identifier un plan.

· ListContenu : Liste des entités (occurrence, rel_sp, event) qui apparaissent dans le plan.

· Duration : Durée nominale du plan, elle est égal à (LastImage-firstImage+1) / Rate milliseconde.

· Shot_Type : Type du shot, à ce moment un shot a trois types.

· Scale : Si un shot a type de zoom_in et zoom_out, cet attribut est l'échelle du zoom. S'il est négatif, c'est zoom_in.

· Direction : Si un shot a type de panning, cet attribute est la direction de mouvement de caméra.

· IsTransition : Plan avec ou sans transition  avant.

· Shot_Transition : Si IsTransition est vrai, le shot contient une transition avant.

· FirstImage : Numéro de la première image du plan.

· LastImage : Numéro de la dernière image du plan.

· Keyframe : Image de représentation du plan.

· Liste_Occurrence : Liste des occurrences dans shot.

· Liste_event : Liste des events dans shot.

· Comment : Commentaire du plan.

4.5.5 Transition

Il représente une transition d'un plan.

Descripteur syntaxique 

Transition{

String Name

String Duration 
Int First_Image 
Int Last_Image 
Enum Transition_Type{fade-in, fade-out, dissole, wipe}

}

Sémantique de descripteur syntaxique 

· Name : Pour identifier la transition.

· Duration: Durée nominale de la transition, elle est égal à (LastImage-firstImage+1)/Rate milliseconde.

· FirstImage : Numéro de la première image de la transition.

· LastImage : Numéro de la dernière image de la transition.

· Transition_Type : Type de la transition: fondu, enchaîné, etc.

4.5.6 Event

Il représente une séquence d'image jugée significative dans la vidéo. Il est rattaché au plan, scène ou séquence qui le contient entièrement.

Descripteur syntaxique 

Event{

String Name

String Duration 
Int First_Image 
Int Last_Image 
String Type 
If (Type="Spatial_Relation") { 
SpatialRelation List_Relation[ ] 
} 
String Comment

}

Sémantique de descripteur syntaxique 

· Name : Pour identifier l'event

· Duration : Durée nominale de l'événement, elle est égal à (LastImage-firstImage+1)/Rate milliseconde.

· FirstImage : Numéro de la première image de l'événement.

· LastImage : Numéro de la dernière image de l'événement.

· Type : Des types d?événements pourraient être créés par une grammaire de définition d'objets sémantiques : les explosions, les introductions des personnages, etc. Il peut être le type de relation spatiale, alors l'event représente un ensemble de relations spatiales entre des occurrences dans un plan.

· List_Relation : Si type de l'event est une Spatial_Relation, l'event sera contient ensemble des relations spatiales.

· Comment : Commentaire de l'event.

4.5.7 Class

Une classe représente l'ensemble des occurrences d'un objet qui est présent dans différents plans.

Descripteur syntaxique 

Class{

String Name

String Sub_Class_of 
Genre Genre_Objet 
Instance List_Instance[ ] 
String Comment

}

Genre{ 
String Name 
Enum Kind{human_being, animal, plant, thing} 
If (Kind="human_being" or Kind="animal") { 
Enum Sex{male, female} 

}

String MetaType

}

Instance{ 
String Ref_Occurrence 
} 
 
Sémantiques de descripteur syntaxique 

· Name : Pour identifier la classe.

· Sub_Class_of : nom de sa super-classe.

· Genre_Objet : Genre de l'objet.

· List_Instance : Liste des occurrences de cet objet.

· Comment : Commentaire de la classe.

· MetaType : Définition plus spécifique de l'objet : étudiant, tigre, herbe, etc.

· RefOccurrence : Référence à l'occurrence (ID).

4.5.8 Occurrence

Cet objet représente une apparition d'un objet dans un plan. Il est construit d'une séquence des zones dans une suite des images d'un plan.

Descripteur syntaxique 

Occurrence{

String Name

String Of_Classe 
Int Duration 
Int First_Image 
Int Last_Image 
String Key_Frame 
Zone List_Zone[ ] 
String Comment

}

Sémantiques de descripteur syntaxique 

· Name : pour identifier l'occurrence.

· Of_Classe : Nom de la classe dont il fait partie.

· Duration : Durée nominale, elle est égale à (LastImage-firstImage+1) /Rate milliseconde.

· FirstImage : Image où l'occurrence apparaît.

· LastImage : Image dans laquelle l'occurrence a disparu.

· Key_Frame : nom de l'image qui représente cette occurrence.

· List_Zone : De fait une occurrence va être physiquement une suite de zone dans des images.

· Comment : Commentaire de l'occurrence.

4.5.9 Zone

C'est une zone spatiale d'une image qui contient une occurrence d'un objet dans cette image. Cette zone est déterminée par un polygone.

Descripteur syntaxique 

Zone{

String ID

Int Image 
ColourHistogram Colour_Histogram_Zone [] 
CameraPerspective Camera_Zone 

Point Shape[]

Point Centroid

Enum Length_Units {Pixel, Meters, Inche,?} 
Double Box_Height 
Double Box_Width 
Double Box_Depth 
Double Vertical_Angle 
Double Horizontal_Angle

}

Struct Point { 

Int x

Int y 
Int z

}

Sémantique de descripteur syntaxique 

· ID : Pour identifier la zone.

· Image : Numéro de l'image dans laquelle la zone apparaît.

· Colour_Histogram_Zone : Liste des fréquences des couleurs de la zone.

· Camera_Zone : Situation da la caméra pour prendre l'image qui contient cette zone.

· Shape : Suite des points du polygone qui délimite cette zone.

· Centroid : Point central de la zone.

· Length_Units : Unité de mesure, elle est utilisée pour présenter la boîte d'englobement de la zone.

· Box_Height, Box_Width, Box_Depth : Définition de la boite la plus petite entoure la zone. Ils sont des mesures verticales, horizontales et de profondeur de cette boite.

· Vertical_Angle, Horizontal_Angle : Angle entre l'axe principal de la boite et l'axe vertical.

· Horizontal_Angle : Angle entre l'axe principal de la boite et l'axe horizontal.

4.5.10 Camera Perspective

Cet objet représente les caractéristiques de la caméra lors de la prise de vue d'occurrence dans une image.

Descripteur syntaxique 

CameraPerspective {

Double Camera_Focal_Length

Enum Camera_Angle_Type{High,Low} 
Double Camera_Vertical_Angle 

Double Camera_Horizontal_Angle

Enum Camera_Distance_Type{Master, Long, Medium, Closeup, Detail}

Double Camera_Distance

Enum LengthUnits {Pixel, Meters, Inche,?} 
Enum Camera_Motion{TRACK_LEFT, TRACK_RIGHT, 

BOOM_DOWN, BOOM_UP, DOLLY_FORWARD,

DOLLY_BACKWARD, PAN_LEFT, PAN_RIGHT, 
TILT_UP, TILT_DOWN, ROLL, ZOOM_IN, 
ZOOM_OUT, FIXED}

}

Sémantique de descripteur syntaxique 

· Camera_Focal_Length : Distance focale de caméra.

· Camera_Angle_Type : Type d'orientation de la caméra par rapport à objet.

· Camera_Vertical_Angle : Angle vertical de déposition de caméra.

· Camera_Horizontal_Angle : Angle horizontal de déposition de caméra.

· Camera_Distance_Type : {Master, Long, Medium, Closeup, Detail}

· Camera_Distance : distance entre caméra et objet.

· LengthUnits : unité de mesure {Pixel, Meters, Inche,?}

· Camera_Motion : Mouvement de caméra {TRACK_LEFT, TRACK_RIGHT, BOOM_DOWN, BOOM_UP, DOLLY_FORWARD,DOLLY_BACKWARD, PAN_LEFT, PAN_RIGHT, TILT_UP, ILT_DOWN, ROLL, ZOOM_IN, ZOOM_OUT, FIXED}

4.5.11 ColorHistogram

Cet objet représente une fréquence d'une couleur.

Descripteur syntaxique 

Struct ColourHistogram {

RGB_Value Color 
Float Frequence 
} 
Struct RGB_Value { 
Int r 

Int g

Int b

}

Sémantiques de descripteur syntaxique 

· Color : Valeur de la couleur décrite.

· Frequence : Fréquence du couleur.

· r, g, b : Trois parties de système de couleur RGB (Rouge, Verte, Bleu)

4.5.12 Relation

4.5.12.1 Relation Temporelle

Cet objet représente des relations temporelles d'Allen entre des occurrences dans la même plan.

Descripteur syntaxique 

Struct Relation_Temporal{

RelationAllen List_Relation[]

}

Struct RelationAllen { 

String Interval1

String Interval1 
Int Delay

}

( RelationAllen = Equals | Meets | Finishes | Starts | During ) 
 
Sémantiques de descripteur syntaxique 

· RelationAllen : Présentation des relations d'Allen : Equals | Meets | Finishes | Starts | During.

· Interval1 : Nom ou ID du premier objet temporel participant à la relation

· Interval2 : Nom ou ID du deuxième objet temporel participant à la relation

· Delay : Relation During a besoin de cet attribut pour spécifier le début du deuxième objet temporel par rapport au premier objet temporel.

4.5.12.2 Relation Spatiale

On a un ensemble de relations Near, At, Right-Left, Above-Below, In_front_of-Behind, Beside pour décrire une relation spatiale entre deux occurrences dans le même plan. Pour décrire un ensemble de relations entre des occurrences d'une même période dans un plan, les objets de relation spatiales sont groupés dans un event objet.

Descripteur syntaxique 

Struct Relation_Spatial{

String ObjetA

String ObjetB

}

( Relation_Spatial= Near | At | Right-Left | Above-Below | In_front_of-Behind | Beside ) 
 
Struct Between { 

String REFO1

String REFO2 
String LO

}

Sémantiques de descripteur syntaxique 

· ObjetA : Nom ou ID du premier objet participant à la relation

· ObjetB : Nom ou ID du deuxième objet participant à la relation

· REFO1 (REFerence Object 1) : Nom ou ID du premier objet de référence

· REFO2 (REFerence Object 2) : Nom ou ID du deuxième objet de référence

· LO (Object to be localized) : Nom ou ID de l'objet localisé.

5 Description XML de la vidéo

Nous choisissons le langage de marquage XML [31] pour décrire la structure vidéo. XML est un standard défini par un groupe de travail du W3C. Il est très proche de son prédécesseur SGML [14]. Il répond aux même objectifs, c'est-à-dire décrire selon un format déclaratif la structure arborescente d'un document. Il s'appuie aussi sur le concept de DTD (Document Type Definition) permettant de définir une classe de documents. Chaque document correspond alors à une instanciation de la DTD.

De façon plus générale, on peut considérer XML est comme un langage permettant de décrire des informations structurées. Ces caractéristiques s'accordent avec notre but mieux que ses prédécesseurs HTML et SGML. En effet, HTML est une DTD spécifique donc le jeu de types d'éléments est fixe ; tandis que SGML bien qu'offrant une puissance de description équivalente à XML, est plus complexe à implanter dans une application (parser).

De plus, XML est indépendant vis à vis des applications, cela permet aux documents XML d'être utilisés dans des applications différentes. Il est facile d'écrire des programme de traitement de documents XML grâce à l'existence de plusieurs implémentations d?analyseurs XML. Enfin document les documents XML sont codés selon un format textuel donc lisibles et facilement éditables.

Dans la suite de cette section, nous présentons la DTD vidéo. La DTD que nous proposons repose sur les entités et leurs attributs définis dans la section 3.3. Pour être plus lisible, nous présentons dans un premier temps cette DTD par parties : les relations temporelles, les attributs (selon une syntaxe simple qui n'utilise pas les entités XML, pour plus de clarté), puis enfin les types d'éléments constituant la vidéo. Le corps complet de la DTD se trouve en annexe C.

Ensuite nous décrivons comment les documents XML conformes à cette DTD de vidéo sont générés à partir des informations de structure vidéo fournies par l'application VidéoPrep. En fin de section nous présentons un exemple de description XML pour la vidéo Allocine ainsi qu'un exemple de document Madeus qui utilise la structure obtenue.

5.1 DTD Vidéo

5.1.1 Rel_Temporal élément

L'élément Rel_Temporal décrit des relations temporelles entre des éléments. Il contient des éléments de relations temporelles, chaque sous élément correspond à un type de relation temporelle.  

<!ELEMENT Rel_Temporal (Equals | Meets | Finishes | Starts | Before | During | Overlaps)+

Description de chaque type de relation temporelle

Il y a deux catégories de relations temporelles: les relations temporelles avec et sans délai. Une relation temporelle sans délai a deux attributs Interval1et Interval2 qui représentent les deux éléments participant à cette relation. Ces attributs sont groupés dans l'entité %operand. Une relation avec délai a en plus des deux attributs Interval1et Interval2 un attribut Delay qui représente le délai attaché à cette relation. Les attributs de la relation avec délai sont groupés dans l'entité %operands_delay.

<!ENTITY % operands "

Interval1 CDATA #REQUIRED 
Interval2 CDATA #REQUIRED" 
 
 
<!ENTITY % operands_delay " 
Interval1 CDATA #REQUIRED 
Interval2 CDATA #REQUIRED 
Delay CDATA #IMPLIED" 
 

Les éléments de relations temporelles sont vides.

Equals élément: description de la relation Equal.

<!ELEMENT Equals EMPTY>

<!ATTLIST Equals %operands;> 
 

Meets élément: description de la relation Meet.

<!ELEMENT Meets EMPTY >

<!ATTLIST Meets %operands;> 
 

Finishes élément: description de la relation Finish.

<!ELEMENT Finishes EMPTY>

<!ATTLIST Finishes %operands;> 
 

Starts élément: description de la relation Starts.

<!ELEMENT Starts EMPTY>

<!ATTLIST Starts %operands;> 
 

Before élément: description de la relation Before.

<!ELEMENT Before EMPTY>

<!ATTLIST Before %operands_delay;> 
 

Durings élément: description de la relation During.

<!ELEMENT During EMPTY>

<!ATTLIST During %operands_delay;> 
 

Overlaps élément: description de la relation Overlap.

<!ELEMENT Overlaps EMPTY>

<!ATTLIST Overlaps %operands_delay;> 

5.1.2 Rel_Spatial élément

L'élément Rel_Spatial décrit des relations spatiales entre des éléments. Comme nous l'avons décrit dans la section 3.1.3, dans cette étape de notre travail, les relations spatiales d'une vidéo sont des éléments Rel_spatial uniquement attachés au niveau des entités plan. En plus des attributs OccA et OccB spécifiant les opérandes impliqués dans la relation, un élément Rel_spatial peut aussi avoir des attributs spécifiant la durée de la relation : soit par l'attribut Duration, soit par les attributs FirstImage et LastImage qui spécifient la suite des images du plan dans lesquelles la relation est valide. Ces attributs sont groupés dans l'entité att_rel_saptial.

<!ENTITY % att_rel_saptial "

Name CDATA #REQUIRED 
OccA CDATA #IMPLIED 
OccB CDATA #IMPLIED 
FirstImage CDATA #IMPLIED 
LastImage CDATA #IMPLIED 
Duration CDATA #IMPLIED 
Comment CDATA #IMPLIED ">

<!ELEMENT Rel_spatial (On_Left_of | On_Right_of | On_Top_of | Below_of | Inside, Touched_by | On_Right_Top_of | On_Left_Top_of | On_Left_Below_of | On_Right_Below_of | Intersect)>

Description de chaque type de relation spatiale

On_Left_of élément : description de la relation spatiale dans laquelle l'objet A est à gauche de l'objet B.

<!ELEMENT On_Left_of EMPTY>

<!ATTLIST On_Left_of %att_rel_spatial>
 

On_Right_of élément : description de la relation spatiale dans laquelle l'objet A est à droite de l'objet B.

<!ELEMENT On_Right_of EMPTY>

<!ATTLIST On_Right_of %att_rel_spatial>
 

On_Top_of élément : description de la relation spatiale dans laquelle l'objet A est au-dessus de l'objet B.

<!ELEMENT On_Top_of EMPTY>

<!ATTLIST On_Top_of %att_rel_spatial>
 

On_Below_of élément : description de la relation spatiale dans laquelle l'objet A est au-dessous de l'objet B.

<!ELEMENT On_Below_of EMPTY>

<!ATTLIST On_Below_of %att_rel_spatial>
 

Inside élément : description de la relation spatiale dans laquelle l'objet A est inclus dans l'objet B.

<!ELEMENT Inside EMPTY>

<!ATTLIST Inside %att_rel_spatial>
 

Touched_by élément : description de la relation spatiale dans laquelle l'objet A et l'objet B se touchent.

<!ELEMENT Touched_by EMPTY>

<!ATTLIST Touched_by %att_rel_spatial>
 

On_Right_Top_of élément : description de la relation spatiale dans laquelle l'objet A est au-dessus et à droite de l'objet B.

<!ELEMENT On_Right_Top_of EMPTY>

<!ATTLIST On_Right_Top_of %att_rel_spatial>
 

On_Left_Top_of élément : description de la relation spatiale dans laquelle objet A est au-dessus et à gauche de l'objet B.

<!ELEMENT On_Left_Top_of EMPTY>

<!ATTLIST On_Leftt_Top_of %att_rel_spatial>
 

On_Left_Below_of élément : description de la relation spatiale dans laquelle objet A est au-dessous et à gauche de l'objet B.

<!ELEMENT On_Left_Below_of EMPTY>

<!ATTLIST On_Leftt_Below_of %att_rel_spatial>
 

On_Right_Below_of élément : description de la relation spatiale dans laquelle objet A est au-dessous et à droite d'objet B.

<!ELEMENT On_Right_Below EMPTY>

<!ATTLIST On_Right_Below %att_rel_spatial>
 

Intersect élément : description de la relation spatiale dans laquelle l'objet A et l'objet B sont en intersection.

<!ELEMENT Intersect EMPTY>

<!ATTLIST Intersect %att_rel_spatial> 

5.1.3 Eléments de la vidéo

5.1.3.1 Attributs communs :

· Attribut d'identification

· Name attribut :

Name CDATA #REQUIRED

Name attribut est utilisé pour identifier uniquement un élément. Cet attribut apparaît dans tous les éléments.  

· Source attribut

· BaseName attribut :

BaseName CDATA #IMPLIED

BaseName attribut indique le répertoire où la source est contenue.

· FileName attribut:

FileName CDATA #IMPLIED

FileName attribut indique le nom de la source.

Ces deux attributs sont utilisés dans Vidéo élément pour déterminer la source vidéo.

· Attribut de la durée

· Duration attribut:

Duration CDATA #IMPLIED

Duration attribut détermine la durée nominale de la présentation d'un élément. Il est dans tous les éléments sauf Class élément et Zone élément.

· Attributs de position:

Ces attributs déterminent la position d'un élément visible sur l'écran de présentation. La zone de présentation de l'élément visible est la boîte, et elle est déterminée par les cordonnées du point en haut et à gauche de cette boite.

· Left attribut

Left CDATA #IMPLIED

Left attribut détermine l'abscisse du point en haut et à gauche de la zone présentation.

· Top attribut

Top CDATA #IMPLIED

Top attribut détermine l'ordonnée du point en haut et à gauche de la zone présentation.

· Attributs de taille

Ces attributs déterminent la taille de la zone de présentation de l'élément visible.

· Width attribut

Width CDATA #IMPLIED

Width attribut est la largeur de la zone de présentation.

· Height attribut

Height CDATA #IMPLIED

Height attribut est la hauteur de la zone de présentation.

· Attribut de liaison

· HRef attribut:

HRef CDATA #IMPLIED

Href attribut permet d'accéder à des informations complémentaires attachées à l'élément.

· Attribut de commentaire

· Comment attribut:

Comment CDATA #IMPLIED

Comment attribut contient des commentaires de l'élément

· Attributs d'indexation une séquence d'image

· FirstImage attribut:

FirstImage CDATA #IMPLIED

FirstImage est l'index de la première image de la séquence d'image.

· LastImage attribut:

LastImage CDATA #IMPLIED

LastImage est l'index de la dernière image de la séquence d'image.

· Des méta Attributs

Ces attributs, attachés à l'élément vidéo, décrivent des informations comme le titre, le nom du producteur, la langue de présentation, le format de stockage et le résumé de la vidéo:

· Title attribut: Nom de la vidéo donné par l'auteur

Title CDATA #IMPLIED

· Author attribut: Auteur(s) de la vidéo

Author CDATA #IMPLIED

· Format attribut: Format de stockage de la vidéo.

Format CDATA #IMPLIED

· Language attribut: Langue de présentation de la vidéo

Language CDATA #IMPLIED

· Description attribut: Description: résumé de la vidéo.

Description CDATA #IMPLIED

5.1.3.2 Vidéo élément

Entités

Descriptions XML

Vidéo : Name   Source  Duration   Position (Left , Top)  NumberImage   NumberPlan   Title   Author   Format   Language   Rate   Description   ListSequences   ListClass

<!ELEMENT Vidéo (Sequence+,Class*, Rel_Temporal)  <!ATTLIST Vidéo Name CDATA #REQUIRED  BaseName CDATA #IMPLIED  FileName CDATA #IMPLIED Duration CDATA #IMPLIED Left CDATA #IMPLIED Top CDATA #IMPLIED Width CDATA #IMPLIED Height CDATA #IMPLIED NImage CDATA #IMPLIED  NPlan CDATA #IMPLIED BackGround CDATA #IMPLIED Title CDATA #IMPLIED Author CDATA #IMPLIED Format CDATA #IMPLIED  Language CDATA #IMPLIED Rate CDATA #IMPLIED Description CDATA #IMPLIED>

Vidéo élément est description XML de l'entité Vidéo de notre modèle de structure vidéo. Il contient un ou plusieurs Sequence éléments, plusieurs ou aucun Class éléments, et un Rel_Temporal élément.

Les attributs spécifiques d'éléments vidéo :

· NImage attribut: contenant le nombre d'images de la vidéo

· Nplan attribut: contenant le nombre de plans de la vidéo

· Rate attribut: contenant la vitesse nominale de présentation des images de la vidéo.

5.1.3.3 Sequence élément:

Entités	Descriptions XML
Sequence: Name   Duration   Comment   ListScene   ListEvent	<!ELEMENT Sequence (Scene+,Event*,Rel_Temporal) > <!ATTLIST Sequence Name CDATA #REQUIRED Duration CDATA #IMPLIED Comment CDATA #IMPLIED >

Sequence élément est la description XML de l'entité Sequence. Il contient un ou plusieurs Scene éléments, plusieurs ou aucun Event éléments, et un Rel_Temporal élément.

5.1.3.4 Scene élément

Entités	Descriptions XML
Scene: Name   Duration   Comment   ListPlans   OfSequence   ListEvent	<!ELEMENT Scene (Plan+,Event*,Rel_Temporal) > <!ATTLIST Scene Name CDATA #REQUIRED Duration CDATA #IMPLIED Comment CDATA #IMPLIED >

Scene élément est la description XML de l'entité Scene. Il contient un ou plusieurs Plan éléments, plusieurs ou aucun Event éléments, et un Rel_Temporal élément.

5.1.3.5 Plan élément

Entités	Descriptions XML
Plan Name   FirstImage   LastImage   KeyFrame   Duration   Comment   LastImageTrans   OfScene   ListContenu   IsTranisition	<!ELEMENT Plan (Transition?,Event*,Occurrence*,Rel_sp*, Rel_Temporal)> <!ATTLIST Plan Name CDATA #REQUIRED FirstImage CDATA #IMPLIED LastImage CDATA #IMPLIED KeyFrame CDATA #IMPLIED Duration CDATA #IMPLIED Comment CDATA #IMPLIED >

Plan élément est description XML de l'entité Plan. Il contient un ou aucune Transition élément, plusieurs ou aucun Event éléments, plusieurs ou aucun Occurrence éléments, Plusieurs ou aucun Rel_sp élément, et un ou aucune Relation élément.

5.1.3.6 Transition élément

Entités	Descriptions XML
Transition Name   FirstImageTrans   LastImageTrans   Duration   TransitionType	<!ELEMENT Transition EMPTY <!ATTLIST Transition Name CDATA #REQUIRED FirstImage CDATA #IMPLIED LastImage CDATA #IMPLIED Duration CDATA #IMPLIED TransitionType CDATA #IMPLIED >

Transition élément est description XML de l'entité Transition.

Il a l'attribut spécifique TransitionType décrivant la type de la transition: fondu enchaîné, etc.

5.1.3.7 Event élément

Entités	Descriptions XML
Event Name   FirstImage   LastImage   Duration   Type   Comment	<!ELEMENT Event EMPTY > <!ATTLIST Event Name CDATA #REQUIRED FirstImage CDATA #IMPLIED LastImage CDATA #IMPLIED Duration CDATA #IMPLIED Type CDATA #IMPLIED Comment CDATA #IMPLIED >

Event élément est la description XML de l'entité Event.

Il a plus un Type attribut qui contient le catégorie sémantique.  

5.1.3.8 Class élément

Entités	Descriptions XML
Class Name   ListOccurrence   Execution   Comment	<!ELEMENT Class EMPTY> <!ATTLIST Class Name CDATA #REQUIRED ListOccs CDATA #IMPLIED Execution CDATA #IMPLIED Comment CDATA #IMPLIED >

Class élément est description XML de l'entité Class.

Il a plus deux attributs :

· ListOccs attribut contient une liste d'occurrences de cette classe.

· Execution attribut contient une commande exécutable attachée à cette classe.

5.1.3.9 Occurrence élément

Entités	Descriptions XML
Occurrence Name   FirstImage   LastImage   Duration   Comment  ListZone   OfClasse	<!ELEMENT Occurrence (Zone+) > <!ATTLIST Occurrence Name CDATA #REQUIRED FirstImage CDATA #IMPLIED LastImage CDATA #IMPLIED Duration CDATA #IMPLIED Comment CDATA #IMPLIED Href CDATA #IMPLIED >

Occurrence élément est la description XML de l'entité Occurrence. Il contient plusieurs Zone élément
 

5.1.3.10 Zone élément

Entités	Descriptions XML
Zone Name   NumeroImage   ListPoint   OfOccurrence	<!ELEMENT Zone EMPTY > <!ATTLIST Zone Name CDATA #REQUIRED NumeroImage CDATA #IMPLIED ListPoint CDATA #IMPLIED Href CDATA #IMPLIED >

Zone élément est la description XML de l'entité Zone.

5.2 Génération de la structure XML d'une vidéo à partir des fichiers de vidéoprep

Comme nous l'avons déjà décrit, notre description de la structure vidéo en XML est fondée sur les résultats de la structure de l'application Vidéoprep et de ses capacités d'extension. À cause de la limite actuelle des résultats de Vidéoprep, on ne peut pas générer automatiquement tous les éléments et les attributs de la structure vidéo que nous avons décrits. Ces éléments et ces attributs seront ajoutés manuellement par l'utilisateur comme des éléments scène, séquence , event, etc, et des attributs comme position, title, description, author , etc. À l'inverse, il y a quelques informations du résultat de Vidéoprep qui ne sont pas encore utilisées par notre outil de génération car elles n'ont pas encore leur équivalent dans la DTD XML.

Dans la suite de cette section, nous décrivons la génération des éléments de la structure vidéo sous forme de tableaux de correspondance entre les champs des fichiers de vidéoprep et les éléments et attributs qui sont générés automatiquement. Nous précisons également les éléments et les attributs qui sont ajoutés manuellement.  

5.2.1 Génération d'élément Vidéo

L'élément Vidéo est l'élément racine, il contient tous les autres éléments de la structure vidéo. Il est généré à partir des informations du fichier d'entrée de Vidéoprep (*.vdo), du fichier b_shots.i et des informations ajoutées par l'utilisateur.

Information	Vidéo élément <!ELEMENT Vidéo (Sequence+,Class*, Rel_Temporal)
Fichier entrée de Vidéoprep (.vdo)
PREFIX	Name CDATA #REQUIRED
PATH	BaseName CDATA #IMPLIED
PREFIX + SUFFIX	FileName CDATA #IMPLIED
LAST_IMAGE - FIRST_IMAGE + 1	NImage CDATA #IMPLIED
(LAST_IMAGE - FIRST_IMAGE + 1 ) / IMAGE_PER_SECOND	Duration CDATA #IMPLIED
WIDTH	Width CDATA #IMPLIED
HEIGHT	Height CDATA #IMPLIED
IMAGE_PER_SECOND	Rate CDATA #IMPLIED
Fichier des plans b_shots.i
Compter le nombre de plans dans ce fichier	NPlan CDATA #IMPLIED
Ajoutés par l'utilisateur après la génération automatique	BackGround CDATA #IMPLIED Left CDATA #IMPLIED Top CDATA #IMPLIED  Title CDATA #IMPLIED Author CDATA #IMPLIED Format CDATA #IMPLIED  Language CDATA #IMPLIED Description CDATA #IMPLIED >

5.2.2 Génération d'élément Sequence

Il n'y a pas encore d'informations relatives aux séquences dans les fichiers de Vidéoprep. Il y a donc un seul élément Sequence dans la structure vidéo générée. L'attribut Name de cet élément est le nom par défaut Seq. La durée de cet élément est calculée à partir des durées des scènes qu'il contient. La génération de l'élément Sequence est réalisée comme suit:  

Information	Sequence élément <!ELEMENT Sequence Scene+,Event*,Rel_Temporal)> <!ATTLIST Sequence
Par défaut "Seq"	Name CDATA #REQUIRED
Calculée à partir des durées des scènes	Duration CDATA #IMPLIED
Ajouté par l'utilisateur après la génération automatique	Comment CDATA #IMPLIED

5.2.3 Génération d'élément Scène

Comme dans le cas de l'élément Sequence, il n'y a pas d'informations de scène dans les fichiers de Vidéoprep. L'application génère donc un seul élément Scene dans la structure vidéo avec le nom par défaut "Scene". La durée de cet élément Scene est calculée à partir des durées des plans qu'il contient. La génération de l'élément Scene est réalisée comme suit :

Information	Scene élément <!ELEMENT Scene (Plan+,Event*,Rel_Temporal)> <!ATTLIST Scene
Par défaut "Scene"	Name CDATA #REQUIRED
Calculé à partir des durées des plans	Duration CDATA #IMPLIED
Ajouté par l'utilisateur après la génération automatique	Comment CDATA #IMPLIED >

5.2.4 Génération d'élément Plan

L'élément Plan est contenu dans l'élément Scene. Les informations dans le fichier b_shots.i sont utilisées pour générer des éléments Plan. Le nom de l'élément Plan est la chaîne "Plan" complétée par l'information Numéro séquentiel du plan de cet élément. La durée de l'élément Plan est le nombre d'images divisé par la vitesse de la vidéo. La génération de l'élément Plan est décrite dans la tableau ci-dessous. Si l'information Plan avec ou sans transition est égale à 1, alors un élément Transition est créé et est contenu dans cet élément Plan.  

lnformation	Plan élément <!ELEMENT Plan (Transition?,Event*,Occurrence*,Rel_spatial, Rel_Temporal)> <!ATTLIST Plan
Fichier de Vidéoprep b_shots.i
"Plan"+ Numéro séquentiel du plan	Name CDATA #REQUIRED
Numéro de la première image du plan	FirstImage CDATA #IMPLIED
Numéro de la dernière image du plan	LastImage CDATA #IMPLIED
(Numéro de la première image du plan - Numéro de la dernière image du plan) / Rate	Duration CDATA #IMPLIED
Ajoutés par l'utilisateur après la génération automatique	Comment CDATA #IMPLIED >

5.2.5 Génération d'élément Transition

L'élément Transition est contenu dans l'élément Plan. Les informations dans le fichier b_shots.i sont utilisées pour générer des éléments Transition. Un élément Transition n'est créé que si l'information Plan avec ou sans transition est égale à 1. Alors il est créé dans le corps de l'élément Plan avec le nom par défaut "Trans". La génération de l'élément transition est décrite dans le tableau ci-dessous.  

Information	Transition élément <!ELEMENT Transition EMPTY> <!ATTLIST Transition
Fichier de Vidéoprep b_shots.i
Par défaut "Trans"	Name CDATA #REQUIRED
Numéro de la première image du plan	FirstImage CDATA #IMPLIED
Numéro de la dernière image de la transition	LastImage CDATA #IMPLIED
(Numéro de la première image du plan - Numéro de la dernière image de la transition) / Rate	Duration CDATA #IMPLIED
Ajoutés par l'utilisateur après la génération automatique	TransitionType CDATA #IMPLIED >

5.2.6 Génération d'élément Event

Il n'y a aucune information sur les événements dans les fichiers Vidéoprep. Un élément Event n'est donc pas créé automatiquement. Il est ajouté par l'utilisateur près la période de génération automatique. Pour déterminer les attributs de l'élément Event, l'utilisateur regarde la vidéo, détermine les paramètres d'une période qu'il juge significative dans cette vidéo, et les décrit dans les attributs de l'élément Event.    

5.2.7 Génération d'élément Class

L'élément Class est généré automatiquement à partir des informations des fichiers b_class.i.j.k de Vidéoprep. La génération de l'élément Class est décrite dans le tableau ci-dessous.

Information	Class élément <!ELEMENT Class EMPTY> <!ATTLIST Class
Fichier b_class.i.j.k
Nombre de la classe	Name CDATA #REQUIRED
Nombre de zones N dans cette classe + N ligne indiquant le numéro des zones de cette classe	ListOccs CDATA #IMPLIED
Exécutable attaché à la classe	Execution CDATA #IMPLIED
Commentaire de la classe	Comment CDATA #IMPLIED >

5.2.8 Génération d'élément Occurrence

L'élément Occurrence est généré dans le corps de l'élément Plan. Les fichiers b_zones.i.j et b_maps.i.j sont utilisés pour générer des éléments Occurrences. La génération de l'élément Occurrence est décrite dans le tableau ci-dessous.  

Information	Occurrence élément <!ELEMENT Occurrence (Zone+) > <!ATTLIST Occurrence
Fichier b_zones.i.j
Nom de la zone	Name CDATA #REQUIRED
(FirstImage - LastImage) / Rate	Duration CDATA #IMPLIED
Commentaire de la zone	Comment CDATA #IMPLIED
Numéro de l'image	FirstImage CDATA #IMPLIED
Dans le fichier b_maps.i.j trouver la dernière image de la zone	LastImage CDATA #IMPLIED
Ajoutés par l'utilisateur après la génération automatique	Href CDATA #IMPLIED >

5.2.9 Génération d'élément Zone

L'élément Zone est généré dans le corps de l'élément Occurrence. Les fichiers b_maps.i.j sont utilisés pour générer des éléments Zone. La génération de l'élément Zone est décrite dans le tableau ci-dessous.

Information	Zone élément <!ELEMENT Zone EMPTY > <!ATTLIST Zone
Fichier b_maps.i.j
"Zone"+ (Le numéro de l'image où se situe le polygone - FirstImage de l'élément Occurrence qui le contient)	Name CDATA #REQUIRED
Le numéro de l'image où se situe le polygone	NumeroImage CDATA #IMPLIED
Le nombre de sommets N du polygone  N lignes donnant les coordonnées (x,y) de chaque sommet	ListPoint CDATA #IMPLIED
Ajoutés par l'utilisateur après la génération automatique	Href CDATA #IMPLIED >

5.3 Exemple:

Nous montrons un document Madeus 2.0 contenant la vidéo structurée qui est généré automatiquement par rapport aux informations de la structure vidéo d'application Vidéoprep selon le processus décrit dans la figure 1. Dans ce document la vidéo allocine.mpg est décrite comme un objet composite Allocine qui contient une séquence Seq. Séquence Seq se compose de trois scènes Scene1, Scene2, Scene3. Scene1 contient trois plans Plan1, Plan2 et Plan3. Scene2 contient huit plans Plan4, Plan5,?, Plan11 Scene3 contient deux plans Plan12 et Plan13.

Le scénario de ce document se présente comme suit (voir figures 14 et 15): Au début le texte élément Introduction est présenté pendant 5 secondes. Après le texte élément Titre et la vidéo élément Allocine sont joués, la durée de présentation des deux élément est la même et est égale à 36080 milisecondes. Pendant la présentation de la vidéo élément Allocine, les textes éléments TitreObjet1, PetiteFille1, PetiteFille2, PetiteFille3, PetiteFille4, TitreObjet2 sont présentés en même temps que les présentations respectives des éléments occurrences "Titre vidéo", "Petite fille profil", "Petite fille assise", "Petite fille au telephone", "Petite fille au telephone 3", "Numero d'appel" dans la vidéo. Enfin quand la vidéo élément est terminée, le texte élément Fin est présenté. Le source XML du document se trouve dans l'annexe C.

6 Application

Dans cette section nous décrivons la chaîne complète d'application de composition et de présentation des documents multimédias qui considère l'objet vidéo comme un objet composite.  

Le processus de présentation de documents multimédias qui contiennent des objets vidéos structurés se compose donc de 3 phases (voir la Figure 23) :

· L'analyse de la vidéo pour extraire des éléments vidéos,

· La génération de ces informations résultantes de la structure vidéo en XML,

· L'édition et la présentation des documents contenant des vidéos structurées.

L'analyse et la structuration de la vidéo sont effectués avec l'outil Vidéoprep (section 3.1) pour avoir des informations sur la structure de la vidéo comme des Séquences, des Scènes, des Plans, etc.  

La génération de document spécifiant la structure de la vidéo est effectuée automatiquement à partir des informations résultats de Vidéoprep comme décrit dans section 5.2. Ce document est conforme à la DTD XML qui représente notre modèle de structure vidéo (section 5.1).

Figure 23 : Modèle du processus de traitement vidéo. 

L'étape finale, c'est-à-dire la composition des éléments vidéo avec les autres éléments du document et la présentation du document, s'effectue grâce au logiciel Madeus2.0. Cette phase de composition entre la structure de la vidéo et les autres objets est effectuée avec l'aide de la nouvelle interface ajoutée dans Madeus 2.0. Cette interface, appele structured Vidéo View, contient quatre zones principales (voire la Figure 24) :

1. est la présentation de l'élément courant choisi par l'utilisateur dans la vidéo;

2. est la zone de description de l'élément choisi. Chaque description dépend du type de l'élément choisi. Par exemple, si un élément scène est choisi, la zone de description présente les images caractérisées de chaque plant dans cette scène ;

3. est la zone de la visualisation des éléments de la vidéo dans la structure hiérarchique. Elle permet de naviguer facilement dans cette structure. Quand un élément de la structure vidéo est choisi, la zone de présentation de l'élément correspondant et la zone de description sont mises à jour.

4. affiche les informations quantitatives de l'élément choisi comme l'instant de début, le nombre d'images, le nombre de plans.

Figure 24 : l'interface Structured vidéo view dans Madeus 2.0.

7 Conclusion

7.1 Résumé du travail

Ce rapport a présenté les travaux effectués dans le cadre d'un projet de DEA. Nous avons commencé par faire un état de l'art des modèles de description de vidéo et de leurs applications. Les schémas de description de structure de la vidéo ont été présentés. Nous avons pu constater que tous ces schémas sont en cours et incomplets. Ils ne décrivent pas généralement toutes les caractéristiques souhaitées, comme les formes des objets, leurs mouvements, les relations temporelles et spatiales, les mouvements de caméra. Le travail de Mpeg-7 constitue dans ce contexte le travail principal de description de contenu audiovisuel. Il est supporté par d'autres travaux et est concidéré futur de format de description des applications en cours d'élaboration (AGIR, Decman).  

Dans la troisième partie, nous avons décrit notre contexte de travail. Nous avons présenté le projet Movi et les principes de l'application Vidéoprep, ses limites et le besoin d'un nouveau format plus sémantique pour l'ensemble des informations résultants de Vidéoprep. Puis nous avons présenté le projet Opéra, son outil Madeus 2.0 et son modèle de document multimédia caractérisé par quatre dimensions : logique, spatiale, hypermédia, temporelle. Nous avons indiqué ensuite le besoin de décomposition des objets vidéo dans Madeus. Notre travail est ainsi issu des limites de Videoprep et des besoins Madeus, et s'effectue donc dans le cadre de la collaboration entre le projet Movi et le projet Opéra.  

Dans la quatrième partie, nous avons présenté notre analyse de la structure vidéo et une proposition d'un modèle de description de la vidéo. Notre analyse est basée principalement sur les informations résultant de Vidéoprep. Nous avons également proposé de nombreuses extensions aux informations extraites par Vidéoprep comme les éléments event, scene, séquence, couleurHistogramme, cameraPerspective, etc. Ces extensions font ainsi de notre modèle un modèle plus général et plus puissant. Les relations temporelles entre les éléments vidéo dans notre modèle sont fondées sur les relations temporelles d'Allen. Ceci permet à notre modèle d'avoir la capacité d'exprimer la synchronisation temporelle entre les éléments de la vidéo.  

Dans la cinquième partie, nous avons décrit la génération XML de description de la vidéo dans notre format à partir des informations résultants de Vidéoprep. La génération est effectuée automatiquement, mais il y a encore quelques éléments qui doivent être ajoutés manuellement après par l'utilisateur comme les éléments event, scene, sequence, etc. Une partie de notre modèle qui est traduite en XML, d'une part à cause de la limite des informations extraites par Vidéoprep, et autre part de la limite de la capacité actuelle de Madeus 2.0, par exemple, il n'a pas encore des méthodes de présentation des mouvements d'un objet, c'est pour quoi la description de mouvement d'objet est inutile à ce moment.  

Finalement, dans la sixième partie nous avons présenté une chaîne complète d'application de traitement de la vidéo que nous avons réalisée pour l'édition et la présentation des documents multimédia basé sur notre modèle de présentation de la vidéo. Cette application considère Vidéoprep et Madeus 2.0 comme des outils pour analyser, éditer et présenter la vidéo.

7.2 Bilan

Le modèle de structuration présenté dans ce rapport permet de répondre aux besoins de structuration de l'application multimédia vidéo. Il a fait l'objet d'un rapport de contrat [23] et d'une soumission au workshop EG Multimedia'99 [27] (réponse attendue début juillet 99)  

L'expérimentation nous a permis de valider notre approche en intégrant ce type de description de vidéo dans l?outil Madeus. Cela nous a permis de spécifier un premier niveau de description structurée de la vidéo en prenant en compte les besoins concrets de l'application cible (ici l'environnement d'auteur Madeus), et de tester la chaîne totale du processus décrit en Figure 23 : production automatique de structures de vidéo par l'application Vidéoprep, génération d'une structure XML pour cette vidéo, composition de cette vidéo dans un document multimédia et présentation à l'utilisateur.  

7.3 Perspectives envisagées

Les perspectives envisagées s'articulent autour des deux grands axes que nous avons considérés dans ce travail : le format et les outils.

Format

Pour aller plus loin, il faudra compléter le format de description XML pour permettre d'exprimer des relations spatiales plus riches entre les objets contenus dans les vidéos. Il sera aussi nécessaire d'analyser les besoins d'autres applications (comme la recherche d'informations, la création de la génération automatique de séquences audiovisuelles à partir de différentes vidéos, etc.) pour étendre le format proposé actuellement.  

Il faudrait aussi viser à créer un langage de définition des descriptions (DDL) à partir de notre modèle de description de la vidéo. Ce langage permet de créer des schémas concrets pour chaque application concrète. Par exemple, un schéma de relations temporelles et spatiales pour le système d'édition et de présentation des documents multimédia, un schéma de position spatiale pour le système de robot industriel, un schéma d'exécution conditionnelle pour système de surveillance, etc. Ce travail répondra aux besoins sémantiques que nous avons décrit dans section *. Et il constitue un objectif à plus long terme de la description d'informations audiovisuelles qui rejoint les objectifs de Mpeg-7.  

Outils 

Pour améliorer les outils d'extraction est d'édition, il faudrait :

· Étendre les capacités d'analyse automatique de Vidéoprep (scène, séquence, couler, mouvement de caméra, etc.).

· Améliorer la déduction automatique des objets et des relations dans le format structuré XML, notamment pour les relations spatiales.

· Étendre des capacités d'utilisation de notre format dans Madeus (cherche des éléments vidéos, synchronisation spatiale, etc.).

Annexe A. Les structures résultant de vidéoprep 

L'ensemble des fichiers résultats de vidéoprep est constitué de cinq fichiers, les i, j, k sont les numéros de la version résultat :  

· b_short.i: informations des Plans extraits d'une Vidéo.

· b_zones.i.j: informations des objets extraits d'une Vidéo.

· b_maps.i.j: informations détaillant des objets sur chaque image.

· b_class.i.j.k: informations des classes qui représentent un groupe de objets dans la vidéo.

· thumbi.ppm (les images)

Fichier des plans b_shots.i .

Ce fichier comprend une ligne par plan avec 5 valeurs numériques entières :

· Numéro séquentiel du plan

· Plan avec ou sans transition ( 1ou 0)

· Numéro de la première image du plan

· Numéro de la dernière image de la transition (une transition commencée par la première image du plan) ( -1 si pas de transition)

· Numéro de la dernière image du plan

Exemple : Le fichier b_shots.1 de la vidéo Allocine

1 0 1 -1 29

2 1 30 40 104 
3 1 105 117 123 
4 1 124 136 176 
5 1 177 192 247 
6 0 248 -1 302 
7 0 303 -1 417 
8 0 418 -1 427 
9 1 428 441 487 
10 0 488 -1 569 
11 0 570 -1 767 
12 0 768 -1 872 
13 1 873 884 902

Fichier des zones b_zones.i.j .

Ce fichier comprend pour chaque zone :  

· Taille du nom de la zone <CR

· Nom de la zone <CR

· Taille du commentaire de la zone <CR

· Commentaire de la zone <CR

· Etiquette de la zone,

· Numéro de l?image,

· Type de la zone (1=extraite automatiquement),

· Abscisse d?un point appartenant à la zone <CR

· Ordonnée d?un point appartenant à la zone <CR

Exemple : Le fichier b_zones.1.1 de la vidéo Allocine

11

Titre Vidéo 
10 
No comment 
51 32 10 0 0 
19 
Petite fille profil 
10 
No comment 
42 137 10 0 0 
19 
Petite fille assise 
10 
No comment 
43 193 10 0 0 
25 
Petite fille au telephone 
10 
No comment 
50 248 10 0 0 
. . .  

Fichier des cartes b_maps.i.j .

Ce fichier comprend pour chaque carte :  

· Le numéro de l'image où sesitue le polygone,

· L?étiquette du polygone,

· Le nombre de sommets N du polygone <CR

· N lignes donnant les coordonnées (x,y) de chaque sommet <CR.

Exemple : Le fichier b_maps.1.1 de la vidéo Allocine

32 51 5

51 96 
312 98 
306 182 
49 173 
52 97 
33 51 5 
51 96 
48 172 
306 181 
312 97 
50 95 
34 51 5 
50 94 
312 97 
306 181 
48 171 
51 95 
. . .

Fichier des classes b_class.i.j.k .

Ce fichier comprend pour chaque classe :  

· Taille du nom de la classe <CR

· Nom de la classe <CR

· Taille du commentaire de la classe <CR

· Commentaire de la classe <CR

· Taille de exécutable attaché à la classe<CR

· Exécutable attaché à la classe<CR

· Numéro de la classe ,

· Type de la classe,

· Nombre de zone N dans cette classe <CR

· N ligne indiquant le numéro des zones de cette classe<CR

Exemple : Le fichier b_class.1.1.1 de la vidéo Allocine

115

Petite fille prise comme actrice principale du film Allocine afin de montrer la simplicité du serveur téléphonique.

10 
No comment 
0   
 
1 0 7 
42 
43  
 
50 
26 
45 
47 
49 
10 
Pub cinéma 
0   
 
0   
 
0 2 2 
51 
48 
9 
Telephone 
0   
 
0   
 
2 2 2 
44 
46 

Annexe B. Document Madeus AllocineDemo.madeus

<?xml version = "1.0" ? >

<Madeus Name = "MadeusDocument" Version = "1.0">

<Composite Name= "VidéoComposite" Duration = "40 40 40">

<Movie Name="allocine"

BaseName="/home/zeus2/ttran/Projets/documents/vidéos/allocine/"

FileName="allocine.mpg"

Duration="36080 36080 36080"

Left="320" Top="70"

Rate="25">

<Sequence Name="Seq"

Duration="36080 36080 36080"

<Scene Name="Scene1"

Duration="4920 4920 4920"

<Plan Name="Plan1"

Duration="1160 1160 1160"

</Plan>

<Plan Name="Plan2"

Duration="3000 3000 3000">

<Transition Name="Trans"

Duration="400 400 400" / >

<Occurrence Name="Titre vidéo"

Duration="2920 2920 2920" />

<Relations>

<Temporal>

<Starts Interval1="Trans" Interval2="." />

<During Interval1="Titre vidéo" Interval2="." Delay="80" />

</Temporal>

</Relations>

</Plan>

<Plan Name="Plan3"

Duration="760 760 760">

<Transition Name="Trans"

Duration="480 480 480" />

<Relations>

<Temporal>

<Starts Interval1="Trans" Interval2="." /

</Temporal>

</Relations>

</Plan>

<Relations>

<Temporal>

<Starts Interval1 = "Plan1" Interval2 = "." />

<Finishes Interval1 = "." Interval2 = "Plan3" / >

<Meets Intervals = "Plan1 Plan2 Plan3" / >

</Temporal >

</Relations >

</Scene >

<Scene Name="Scene2"

Duration="25760 25760 25760" >

<Plan Name="Plan9"

Duration="2400 2400 2400" >

<Transition Name="Trans"

Duration="520 520 520" / >

<Occurrence Name="Petite fille au telephone 3"

Duration="1840 1840 1840" />

<Relations >

<Temporal >

<Starts Interval1="Trans" Interval2="." / >

<During Interval1="Petite fille au telephone 3" Interval2="." Delay="560" />

</Temporal >

</Relations >

</Plan >

<Plan Name="Plan8" >

Duration="400 400 400">

<Occurrence Name="Petite fille au telephone 2"

Duration="320 320 320" />

<Relations >

<Temporal >

<During Interval1="Petite fille au telephone 2" Interval2="." Delay="80" />

</Temporal >

</Relations >

</Plan >

<Plan Name="Plan7"

Duration="4600 4600 4600" >

<Occurrence Name="Telephone"

Duration="4600 4600 4600" / >

<Relations >

<Temporal >

<Durings Interval1="Telephone" Interval2="." Delay="0"/ >

</Temporal >

</Relations >

</Plan >

<Plan Name="Plan6"

Duration="2200 2200 2200"

<Occurrence Name="Petite fille au telephone"

Duration="2200 2200 2200" / >

<Relations >

<Temporal >

<Durings Interval1="Petite fille au telephone" Interval2="." Delay="0" />

</Temporal >

</Relations >

</Plan >

<Plan Name="Plan5"

Duration="2840 2840 2840" >

<Transition Name="Trans"

Duration="600 600 600" / >

<Occurrence Name="Petite fille assise"

Duration="2520 2520 2520" / >

<Relations >

<Temporal >

<Starts Interval1="Trans" Interval2="." / >

<During Interval1="Petite fille assise" Interval2="." Delay="640" />

</Temporal >

</Relations >

</Plan >

<Plan Name="Plan4"

Duration="2120 2120 2120" >

<Transition Name="Trans"

Duration="480 480 480" / >

<Occurrence Name="Petite fille profil"

Duration="1800 1800 1800" />

<Relations >

<Temporal >

<Starts Interval1="Trans" Interval2="." / >

<During Interval1="Petite fille profil" Interval2="." Delay="520" />

</Temporal >

</Relations >

</Plan >

<Plan Name="Plan10"

Duration="3280 3280 3280" >

<Occurrence Name="Telephone 2"

Duration="3280 3280 3280" / >

<Occurrence Name="Petite fille debout sur un siege au telephone avec allocine"

Duration="3280 3280 3280" / >

<Relations >

<Temporal >

<Starts Interval1="Telephone 2" Interval2="." / >

<Statss Interval1="Petite fille debout sur un siege au telephone avec allocine"

Interval2="."/>

</Temporal >

</Relations >

</Plan >

<Plan Name="Plan11"

Duration="7920 7920 7920" >

<Occurrence Name="Petite fille sourire"

Duration="7880 7880 7880" / >

<Relations >

<Temporal >

<Starts Interval1="Petite fille sourire" Interval2="."/ >

</Temporal >

</Relations >

</Plan >

<Relations >

<Temporal >

<Starts Interval1 = "Plan4" Interval2 = "." / >

<Finishes Interval1 = "." Interval2 = "Plan11" / >

<Meets Intervals = "Plan4 Plan5 Plan6 Plan7 Plan8 Plan9 Plan10 Plan11" />

</Temporal >

</Relations >

</Scene >

<Scene Name="Scene3"

Duration="5400 5400 5400" >

<Plan Name="Plan13"

Duration="1200 1200 1200" >

<Transition Name="Trans"

Duration="440 440 440" / >

<Relations >

<Temporal >

<Starts Interval1="Trans" Interval2="." / >

</Temporal >

</Relations >

</Plan >

<Plan Name="Plan12"

Duration="4200 4200 4200">

<Occurrence Name="Numero d'appel"

Duration="4200 4200 4200" / >

<Relations >

<Temporal >

<Starts Interval1="Numero d'appel" Interval2="."/ >

</Temporal >

</Relations >

</Plan >

<Relations >

<Temporal >

<Starts Interval1 = "Plan12" Interval2 = "." / >

<Finishes Interval1 = "." Interval2 = "Plan13" / >

<Meets Interval1 = "Plan12" Interval2 = "Plan13" / >

</Temporal >

</Relations >

</Scene >

<Relations >

<Temporal >

<Starts Interval1 = "Scene1" Interval2 ="." / >

<Finishes Interval1 = "." Interval2 = "Scene3" / >

<Meets Intervals = "Scene1 Scene2 Scene3" / >

</Temporal >

</Relations >

</Sequence >

<Relations >

<Temporal >

<Equals Interval1="Seq" Interval2="." / >

</Temporal >

</Relations >

</Movie >

<Text Name = "Titre"

Value = "Test Structure de la vidéo ALLOCINE dans Madeus" Red="0" Green="0" Blue="0"

FontSize="26" FontFamily="Times"

Left = "50.0" Top = "5.0"

Duration="195 195 195"

Width="849.0" Height="28.0"/ >

<Text Name = "Introduction"

Value = "Introduction: Debut Vidéo dans 5 second"

Red="0" Green="0" Blue="0"

FontSize="25" FontFamily="Times"

Left = "100.0" Top = "200.0"

Duration = "5 5 5"

Width="549.0" Height="28.0"/ >

<Text Name = "TitreObjet1"

Value = "Titre vidéo"

Red="0" Green="0" Blue="0"

FontSize="16" FontFamily="Times"

Left = "25.0" Top = "100.0"

Duration = "1 1 1"

Width="449.0" Height="28.0"/ >

<Text Name = "TitreObjet2"

Value = "Numero d'appel"

Red="0" Green="0" Blue="0"

FontSize="16" FontFamily="Times"

Left = "25.0" Top = "100.0"

Duration = "1 1 1"

Width="449.0" Height="28.0"/ >

<Text Name = "PetiteFille1"

Value = "Petite fille profil"

Red="0" Green="0" Blue="0"

FontSize="16" FontFamily="Times"

Left = "25.0" Top = "120.0"

Duration = "1 1 1"

Width="449.0" Height="28.0"/ >

<Text Name = "PetiteFille2"

Value = "Petite fille assise"

Red="0" Green="0" Blue="0"

FontSize="16" FontFamily="Times"

Left = "25.0" Top = "140.0"

Duration = "1 1 1"

Width="449.0" Height="28.0"/ >

<Text Name = "PetiteFille3"

Value = "Petite fille au telephone"

Red="0" Green="0" Blue="0"

FontSize="16" FontFamily="Times"

Left = "25.0" Top = "160.0"

Duration = "0 0 0"

Width="449.0" Height="28.0"/ >

<Text Name = "PetiteFille4"

Value = "Petite fille au telephone 3"

Red="0" Green="0" Blue="0"

FontSize="16" FontFamily="Times"

Left = "25.0" Top = "180.0"

Duration = "1 1 1"

Width="449.0" Height="28.0"/ >

<Text Name = "FIN"

Value = "FIN" Red="0" Green="0" Blue="0"

FontSize="36" FontFamily="Times"

Left = "520.0" Top = "190.0"

Duration = "20 20 20"

Width="449.0" Height="28.0"/ >

<Relations >

<Temporal >

<Meets Interval1 = "Introduction" Interval2 ="allocine" / >

<Meets Interval1 = "Introduction" Interval2 ="Titre" / >

<Equals Interval1 ="allocine.Seq.Scene1.Plan2.Titre vidéo"

Interval2 ="TitreObjet1" / >

<Equals Interval1 ="allocine.Seq.Scene2.Plan4.Petite fille profil" Interval2 ="PetiteFille1" / >

<Equals Interval1 ="allocine.Seq.Scene2.Plan5.Petite fille assise" Interval2 ="PetiteFille2" / >

<Equals Interval1 ="allocine.Seq.Scene2.Plan6.Petite fille au telephone"

Interval2 ="PetiteFille3" / >

<Equals Interval1 ="allocine.Seq.Scene2.Plan9.Petite fille au telephone 3"

Interval2 ="PetiteFille4" / >

<Equals Interval1 ="allocine.Seq.Scene3.Plan12.Numero d'appel" Interval2 ="TitreObjet2" / >

<Meets Interval1 = "allocine" Interval2 ="FIN" / >

</Temporal >

</Relations >

</Composite >

</Madeus >

Annexe C. DTD Madeus 

<!--====================================================================-->

<!--========================================================= Functions -->

<!--====================================================================-->

<!ELEMENT segment EMPTY>

<!ATTLIST segment

src_left CDATA #IMPLIED

src_top CDATA #IMPLIED

dst_left CDATA #IMPLIED

dst_top CDATA #IMPLIED>

<!--====================================================================--

<!--================================================ Generique entities --

<!--====================================================================--

<!ENTITY % link_properties "HRef CDATA #IMPLIED">

<!ENTITY % position_properties "Left CDATA '0'

Top CDATA '0'

Depth CDATA '0' ">

<!ENTITY % position_functions "(segment)" >

<!ENTITY % color_functions "(segment)" >

<!ENTITY % font_functions "(segment)" >

<!ENTITY % size_properties "Width CDATA '50'

Height CDATA '50' "

<!ENTITY % color_properties "Red CDATA '0'

Green CDATA '0'

Blue CDATA '0'"

<!ENTITY % font_properties "FontFamily CDATA 'serif'

FontSize CDATA '12'

FontStyle CDATA 'normal' "

<!ENTITY % global_properties "Name CDATA #REQUIRED

FileName CDATA #IMPLIED

BaseName CDATA #IMPLIED

Value CDATA #IMPLIED

BackGround CDATA #IMPLIED

Duration CDATA #IMPLIED

%link_properties;"

<!ENTITY % all_properties "%global_properties; %position_properties; %font_properties;"

<!ENTITY % objects "(Text | Movie | Audio | Picture | Plugin | Unknown | Fictitious

| External | Applet | Html)"

<!--====================================================================-->

<!--========================================= Generally useful entities -->

<!--====================================================================-->

<!--====================================================================-->

<!--========================================================== Document -->

<!--====================================================================-->

<!ELEMENT Madeus (%objects; | Composite)

<!ATTLIST Madeus

Name CDATA #REQUIRED

Version CDATA #REQUIRED

<!--====================================================================-->

<!--======================================================= Text object -->

<!--====================================================================-->

<!ENTITY % text_properties "%position_properties;

%size_properties;

%color_properties;

%font_properties;"

<!ENTITY % text_functions "%position_functions;

| %font_functions;

| %color_functions;"

<!ELEMENT Text (text_intervals?, Relations?)

<!ATTLIST Text %global_properties;

%text_properties;

<!ELEMENT text_intervals (text_interval+)

<!ELEMENT text_interval (%text_functions;)*

<!ATTLIST text_interval

%global_properties;

%text_properties;

<!--====================================================================-->

<!--======================================================= Html object -->

<!--====================================================================-->

<!ENTITY % html_properties "%position_properties;

%size_properties;

%color_properties;

%font_properties;"

<!ENTITY % html_functions "%position_functions;

| %font_functions;

| %color_functions;"

<!ELEMENT Html (html_intervals?, Relations?)

<!ATTLIST Html %global_properties;

%html_properties;

<!ELEMENT html_intervals (html_interval+)

<!ELEMENT html_interval (%html_functions;)*

<!ATTLIST html_interval

%global_properties;

%html_properties;

<!--====================================================================-->

<!--==================================================== Picture object -->

<!--====================================================================-->

<!ENTITY % picture_properties "%position_properties;

%size_properties;"

<!ENTITY % picture_functions "%position_functions;"

<!ELEMENT Picture (picture_intervals?, relations?)

<!ATTLIST Picture %global_properties;

%picture_properties;

<!ELEMENT picture_intervals (picture_interval+)

<!ELEMENT picture_interval (%picture_functions;)*

<!ATTLIST picture_interval

%global_properties;

%picture_properties;

<!--====================================================================-->

<!--====================================================== Movie object -->

<!--====================================================================-->

<!ENTITY % movie_properties "%position_properties;

%size_properties;"

<!ENTITY % movie_functions "%position_functions;"

<!ELEMENT Movie (movie_intervals?, relations?)

<!ATTLIST Movie %global_properties;

%Movie_properties;

<!ELEMENT movie_intervals (movie_interval+)

<!ELEMENT movie_interval (%movie_functions;)*

<!ATTLIST movie_interval

%global_properties;

%Movie_properties;

<!--====================================================================-->

<!--====================================================== Audio object -->

<!--====================================================================-->

<!ENTITY % audio_properties "%position_properties;

%size_properties;"

<!ENTITY % audio_functions "%position_functions;"

<!ELEMENT Audio (audio_intervals?, relations?)

<!ATTLIST Audio %global_properties;

%audio_properties;

<!ELEMENT audio_intervals (audio_interval+)

<!ELEMENT audio_interval (%audio_functions;)*

<!ATTLIST audio_interval

%global_properties;

%audio_properties;

<!--====================================================================-->

<!--===================================================== Plugin object -->

<!--====================================================================-->

<!ENTITY % plugin_properties "%position_properties;

%size_properties;"

<!ENTITY % plugin_functions "%position_functions;"

<!ELEMENT Plugin (plugin_intervals?, relations?)

<!ATTLIST Plugin %global_properties;

%plugin_properties;

<!ELEMENT plugin_intervals (plugin_interval+)

<!ELEMENT plugin_interval (%plugin_functions;)*

<!ATTLIST plugin_interval

%global_properties;

%plugin_properties;

<!--====================================================================-->

<!--===================================================== Applet object -->

<!--====================================================================-->

<!ENTITY % applet_properties "%position_properties;

%size_properties;"

<!ENTITY % applet_functions "%position_functions;"

<!ELEMENT Applet (Param*)

<!ATTLIST Applet %global_properties;

%applet_properties;

<!ELEMENT Param EMPTY

<!ATTLIST Param

Name CDATA #REQUIRED

Value CDATA #REQUIRED

<!--====================================================================-->

<!--==================================================== Unknown object -->

<!--====================================================================-->

<!ENTITY % unknown_properties "%position_properties;

%size_properties;"

<!ENTITY % unknown_functions "%position_functions;"

<!ELEMENT Unknown (unknown_intervals?, relations?)

<!ATTLIST Unknown %global_properties;

%unknown_properties;

<!ELEMENT unknown_intervals (unknown_interval+)

<!ELEMENT unknown_interval (%unknown_functions;)*

<!ATTLIST unknown_interval

%global_properties;

%unknown_properties;

<!--====================================================================-->

<!--================================================= Fictitious object -->

<!--====================================================================-->

<!ENTITY % fictitious_properties "%position_properties;

%size_properties;"

<!ENTITY % fictitious_functions "%position_functions;"

<!ELEMENT Fictitious (fictitious_intervals?, relations?)

<!ATTLIST Fictitious %global_properties;

%fictitious_properties;

<!ELEMENT fictitious_intervals (fictitious_interval+)

<!ELEMENT fictitious_interval (%fictitious_functions;)*

<!ATTLIST fictitious_interval

%global_properties;

%fictitious_properties;

<!--====================================================================-->

<!--================================================== Composite object -->

<!--====================================================================-->

<!ELEMENT Composite (Default? , (%objects; | Composite)+, Relations?)

<!ATTLIST Composite

%global_properties;

%size_properties;

%position_properties;

<!ELEMENT Default EMPTY

<!ATTLIST Default

%all_properties;

<!--====================================================================-->

<!--========================================================= Relations -->

<!--====================================================================-->

<!ELEMENT Relations ((Rel_Temporal, Rel_Spatial?) | Rel_Spatial)

<!--=============================================================-->

<!--=================================================== temporal -->

<!--=============================================================-->

<!ENTITY % operands "

Interval1 CDATA #REQUIRED

Interval2 CDATA #REQUIRED"

<!ENTITY % operands_delay "

Interval1 CDATA #REQUIRED

Interval2 CDATA #REQUIRED

Delay CDATA #IMPLIED"

<!ELEMENT Temporal (Equals | Meets | Met_by | Finishes | Finished_by | Starts |

Started_by | Kills | Killed_by | Parmin | Lipsync | Lipsync_by | Before |

After | During | Contains | Overlaps | Overlaps_by | Begins | Ends)+

<!ELEMENT Equals EMPTY

<!ATTLIST Equals %operands;

<!ELEMENT Meets EMPTY

<!ATTLIST Meets %operands;

<!ELEMENT Met_by EMPTY

<!ATTLIST Met_by %operands;

<!ELEMENT Finishes EMPTY

<!ATTLIST Finishes %operands;

<!ELEMENT Finished_by EMPTY

<!ATTLIST Finished_by %operands;

<!ELEMENT Starts EMPTY

<!ATTLIST Starts %operands;

<!ELEMENT Started_by EMPTY

<!ATTLIST Started_by %operands;

<!ELEMENT Kills EMPTY

<!ATTLIST Kills %operands;

<!ELEMENT Killed_by EMPTY

<!ATTLIST Killed_by %operands;

<!ELEMENT Parmin EMPTY

<!ATTLIST Parmin %operands;

<!ELEMENT Lipsync EMPTY

<!ATTLIST Lipsync %operands;

<!ELEMENT Lipsync_by EMPTY

<!ATTLIST Lipsync_by %operands;

<!ELEMENT Before EMPTY

<!ATTLIST Before %operands_delay;

<!ELEMENT After EMPTY

<!ATTLIST After %operands_delay;

<!ELEMENT During EMPTY

<!ATTLIST During %operands_delay;

<!ELEMENT Contains EMPTY

<!ATTLIST Contains %operands_delay;

<!ELEMENT Overlaps EMPTY

<!ATTLIST Overlaps %operands_delay;

<!ELEMENT Overlaps_by EMPTY

<!ATTLIST Overlaps_by %operands_delay;

<!ELEMENT Begins EMPTY

<!ATTLIST begins %operands_delay;

<!ELEMENT Ends EMPTY

<!ATTLIST Ends %operands_delay;

<!--=============================================================-->

<!--==================================================== spatial -->

<!--=============================================================-->

<!ENTITY % operands_dist "

Interval1 CDATA #REQUIRED

Interval2 CDATA #REQUIRED

Distance CDATA #IMPLIED"

<!ELEMENT Spatial (Left_align | Center_v | Right_align | Left_spacing |

Left_ident | Right_ident | Right_spacing | Top_align |

Center_h | Bottom_align | Top_spacing | Top_ident |

bottom_ident)+

<!ELEMENT Left_align EMPTY

<!ATTLIST Left_align %operands;

<!ELEMENT Center_v EMPTY

<!ATTLIST Center_v %operands;

<!ELEMENT Right_align EMPTY

<!ATTLIST Right_align %operands;

<!ELEMENT Left_spacing EMPTY

<!ATTLIST Left_spacing %operands_dist;

<!ELEMENT Left_ident EMPTY

<!ATTLIST Left_ident %operands_dist;

<!ELEMENT Right_ident EMPTY

<!ATTLIST Right_ident %operands_dist;

<!ELEMENT Right_spacing EMPTY

<!ATTLIST Right_spacing %operands_dist;

<!ELEMENT Top_align EMPTY

<!ATTLIST Top_align %operands;

<!ELEMENT Center_h EMPTY

<!ATTLIST Center_h %operands;

<!ELEMENT Bottom_align EMPTY

<!ATTLIST Bottom_align %operands;

<!ELEMENT Top_spacing EMPTY

<!ATTLIST Top_spacing %operands_dist;

<!ELEMENT Top_ident EMPTY

<!ATTLIST Top_ident %operands_dist;

<!ELEMENT Bottom_ident EMPTY

<!ATTLIST Bottom_ident %operands_dist;

<!ELEMENT Bottom_spacing EMPTY

<!ATTLIST Bottom_spacing %operands_dist;

Annexe D. DTD Vidéo 

<!--===================================================================-->

<!--=============================================== Generique entities -->

<!--===================================================================-->

<!ENTITY % position_properties "Left CDATA #IMPLIED

Top CDATA #IMPLIED"

<!ENTITY % size_properties "Width CDATA #IMPLIED

Height CDATA #IMPLIED"

<!ENTITY % source_properties "BaseName CDATA #IMPLIED

FileName CDATA #IMPLIED"

<!ENTITY % link_properties "HRef CDATA #IMPLIED"

<!ENTITY % global_properties "Name CDATA #REQUIRED

Duration CDATA #IMPLIED

%link_properties;"

<!ENTITY % sequence_image_properties "FirstImage CDATA #IMPLIED

LastImage CDATA #IMPLIED"

<!ENTITY % comment_properties "Comment CDATA #IMPLIED"

<!--===================================================================-->

<!--================================================== Structure Vidéo -->

<!--===================================================================-->

<!--===================================================================-->

<!--==================================================== Vidéo élément -->

<!--===================================================================-->

<!ENTITY %vidéo_properties " NImage CDATA #IMPLIED

NPlan CDATA #IMPLIED

Rate CDATA #IMPLIED

Title CDATA #IMPLIED

Author CDATA #IMPLIED

Format CDATA #IMPLIED

Language CDATA #IMPLIED

Description CDATA #IMPLIED"

<!ELEMENT Vidéo (Sequence+,Class*, Rel_Temporal?)

<!ATTLIST Vidéo

%global_properties;

%source_properties;

%position_properties;

%size_properties;

%vidéo_properties;

<!--===================================================================-->

<!--================================================= Sequence élément -->

<!--===================================================================-->

<!ELEMENT Sequence (Scene+,Event*,Rel_Temporal?)

<!ATTLIST Sequence

%global_properties;

%comment_properties;

<!--===================================================================-->

<!--==================================================== Scene élément -->

<!--===================================================================-->

<!ELEMENT Scene (Plan+,Event*,Rel_Temporal?)

<!ATTLIST Scene

%global_properties;

%comment_properties;

<!--===================================================================-->

<!--===================================================== Plan élément -->

<!--===================================================================-->

<!ELEMENT Plan

(Transition?,Event*,Occurrence*,Rel_sp*,Relations?)

<!ATTLIST Plan

%global_properties;

%sequence_image_properties;

<!--===================================================================-->

<!--=============================================== Transition élément -->

<!--===================================================================-->

<!ELEMENT Transition EMPTY

<!ATTLIST Transition

%global_properties;

%sequence_image_properties;

TransitionType CDATA #IMPLIED

<!--===================================================================-->

<!--==================================================== Event élément -->

<!--===================================================================-->

<!ELEMENT Event EMPTY

<!ATTLIST Event

%global_properties;

%sequence_image_properties;

Type CDATA #IMPLIED

%Comment_properties;

<!--===================================================================-->

<!--==================================================== Class élément -->

<!--===================================================================-->

<!ELEMENT Class EMPTY

<!ATTLIST Class

%global_properties;

ListOccs CDATA #IMPLIED

Execution CDATA #IMPLIED

%Comment_properties;

<!--===================================================================-->

<!--=============================================== Occurrence élément -->

<!--===================================================================-->

<!ELEMENT Occurrence (Zone+)

<!ATTLIST Occurrence

%global_properties;

%sequence_image_properties;

%Comment_properties;

<!--===================================================================-->

<!--===================================================== Zone élément -->

<!--===================================================================-->

<!ELEMENT Zone EMPTY

<!ATTLIST Zone

%global_properties;

NumeroImage CDATA #IMPLIED

ListPoint CDATA #IMPLIED

<!--===================================================================-->

<!--=================================================== Rel-SP élément -->

<!--===================================================================-->

<!ELEMENT Rel_sp EMPTY

<!ATTLIST Rel_sp

%global_properties;

OccA CDATA #IMPLIED

OccB CDATA #IMPLIED

<!--===================================================================-->

<!--========================================================= Relation -->

<!--===================================================================-->

<!ELEMENT Relations ((Rel_Temporal, Rel_Spatial?) | Rel_Spatial)

<!--===================================================================-->

<!--===================================================== Rel_Temporal -->

<!--===================================================================-->

<!ELEMENT Rel_Temporal (Equals | Meets | Finishes | Starts | Before | During | Overlaps)+

<!ENTITY % operands "

Interval1 CDATA #REQUIRED

Interval2 CDATA #REQUIRED"

<!ENTITY % operands_delay "

Interval1 CDATA #REQUIRED

Interval2 CDATA #REQUIRED

Delay CDATA #IMPLIED"

<!ELEMENT Equals EMPTY

<!ATTLIST Equals %operands;

<!ELEMENT Meets EMPTY

<!ATTLIST Meets %operands;

<!ELEMENT Finishes EMPTY

<!ATTLIST Finishes %operands;

<!ELEMENT Starts EMPTY

<!ATTLIST Starts %operands;

<!ELEMENT Before EMPTY

<!ATTLIST Before %operands_delay;

<!ELEMENT During EMPTY

<!ATTLIST During %operands_delay;

<!ELEMENT Overlaps EMPTY

<!ATTLIST Overlaps %operands_delay;

<!--===================================================================-->

<!--====================================================== Rel_Spatial -->

<!--===================================================================-->

<!ELEMENT Rel_Spatial (On_Left_of | On_Right_of | On_Top_of | Below_of | Inside | Touched_by |

On_Right_Top_of | On_Left_Top_of | On_Left_Below_of | On_Right_Below_of | Intersect)+

<!ENTITY % att_rel_saptial "

Name CDATA #REQUIRED

OccA CDATA #IMPLIED

OccB CDATA #IMPLIED

FirstImage CDATA #IMPLIED

LastImage CDATA #IMPLIED

Duration CDATA #IMPLIED

Comment CDATA #IMPLIED "

<!ELEMENT On_Left_of

<!ATTLIST On_Left_of %att_rel_spatial

<!ELEMENT On_Right_of

<!ATTLIST On_Right_of %att_rel_spatial

<!ELEMENT On_Top_of

<!ATTLIST On_Top_of %att_rel_spatial

<!ELEMENT On_Below_of

<!ATTLIST On_Below_of %att_rel_spatial

<!ELEMENT Inside

<!ATTLIST Inside %att_rel_spatial

<!ELEMENT Touched_by

<!ATTLIST Touched_by %att_rel_spatial

<!ELEMENT On_Right_Top_of

<!ATTLIST On_Right_Top_of %att_rel_spatial

<!ELEMENT On_Left_Top_of

<!ATTLIST On_Leftt_Top_of %att_rel_spatial

<!ELEMENT On_Left_Below_of

<!ATTLIST On_Leftt_Below_of %att_rel_spatial

<!ELEMENT On_Right_Below

<!ATTLIST On_Right_Below %att_rel_spatial

<!ELEMENT On_Right_Below

<!ATTLIST On_Right_Below %att_rel_spatial

Bibliographie

[1]

G.Auffret, J.Carrive, O.Chevet,T.Dechilly, R.Ronfard, B.Bachimont, Audiovisual Event Description Interface AEDI v1.0, user guide, INA, France, 1998.  

[2]

J.F. Allen, Maintening Knowledge about Temporal intervals, Communication of the ACM, 26(11), pp.832-843, Novembre 1983.

[3]

G.Auffret, J.Carrive, O.Chevet, T.Dechilly, R.Ronfard, B.Bachimont, Audiovisual-based Hypermedia Authoring: using structured representations for efficient access to AV documents, Institus National de l'Audiovisuel (INA).

[4]

P.Bertolino, Indexation vidéo, http://www.inrialpes.fr/movi/Demos/DemoPascal/vidéoclic.html, Projet Movi Inria Rhône-Alpes, 1998  

[5]

Brickly D., Guha R., Layman A., Resource Description Framework (RDF) Schema Specification, WD-rdf-schema,W3C Working Draf, October 1998.  

[ 6]

Chandler D., The 'Grammar' of Television and Film, UMA,1994, http://www.aber.ac.uk/~dgc/gramtv.html  

[7]

J.Carrive, F.Pachet, R.Ronfard, Logiques de descriptions pour l'analyse structurelle de film - Description Logics for Structural Analysis of Film, Institus National de l'Audiovisuel (INA).  

[8]

Y.Carbonneaux, M.Jourdan, C.Roinsin, L.Tardif et L.Villard, Architecture détaillée du logiciel Pleiade, http://www.inrialpes.fr/opera/Madeus.en.html, Projet Opéra Inria Rhôn-Alpes, décembre 1998.  

[9]

The DublinCore : A Simple Content Description Model for Electronic Resources, http://purl.org/dc.  

[10]

The DublinCore Metadata Element Set : Reference, http://purl.org/dc.  

[11]

R.Hammoud, L.Chen, D.Fontaine, An Extensible Spatial-Temporal Model for Semantic Vidéo Segmentation, TRANSDOC Projet, Laboratoire HEUDIASYC umr cnrs, Mai 1198  

[12]

J. Hunter, "A Comparison of Schemas for Dublin Core-Based Vidéo Metedata Representation", CITEC, Autralia, 1999.  

[13]

J.Hunter, A Proposal for an Mpeg-7 Description Definition Language (DDL), CITEC, Autralia, 1999.

[14]

I.S.O , Information processing - Text and office systems - Standard Generalized Markup Langaguage (SGML), num. ISO 8879, 1986.  

[15]

Jourdan M., Layaïda N., Roisin C., Sabry-Ismail L., Tardif L., Madeus, an Authoring Environment for Interactive Multimedia Documents, ACM Multimedia'98, pp. 267-272, ACM, Bristol (UK), septembre 1998.  

[16]

Jourdan M., Roisin C., Tardif L., Édition et Visualisation Interactive de Documents Multimedia, Proceedings of Electronic Publishing'98, St Malo, LNCS n.1375, pp. 370-380, Springer, avril 1998.  

[17]

Jourdan M., Roisin C., Tardif L., Multiviews Interfaces for Multimedia Authoring Environments, Proceedings of the 5th Conference on Multimedia Modeling, pp. 72-79, IEEE Computer Society, Lausanne, octobre 1998.  

[18]

Jourdan M., Roisin C., Tardif L., A Scalable Toolkit for Designing Multimedia Authoring Environments, to be published in special issue on `Multimedia Authoring and Presentation: Strategies, Tools, and Experiences', for the Multimedia Tools and Applications journal, Kluwer Academic, 1999.

[19]

M.jourdan, C.Roisin et L.Tardif, Rapport de conception de l'architecture du logiciel Madeus version 2.0, Projet Opéra, Inria Rhône-Alpes, Juin 1998.    

[20]

Nabil Layaida, Madeus, Système d'édition et de présentation de documents structurés multimédias, Thèse, Université Joseph Fourier, Juin 1997.  

[21]

MPEG, http://drogo.cselt.stet.it/mpeg/, 1999  

[22]

MPEG-7 Document, http://www.darmstadt.gmd.de/mobile/MPEG7/Documents.htm, 1999  

[23]

Mohr R., Roisin C., Tran Thuong T., Villard l., Descritpion XML des structures de video, Projets Movi, Opéra - INRIA Rhône-Alpes, mars 1999.    

[24]

Y.Nakamura, T.Kanade, Semantique Analysis for Vidéo Contents Extraction - Spotting by

Association in News Vidéo, 1998.  

[25]

S.Paek, A.B.Benitez, and S.K.Chang, Self-Decribing Schemes for Interoperable Mpeg-7 Multimedia Content Descriptions, Image & Advanced TV Lab, Departement of Electrical Engineering Columbia University, USA, 1999.    

[26]

R.Ronfard, J.Carrive, F.Pachet, A film template library for vidéo analysis and indexing based on description logics, Institus National de l'Audiovisuel (INA), INA-Lip6, Sony-CSL.    

[27]

Roisin C., TranThuong T., Villard L., Intergration of Structure Video in a Multimedia Authoring System, Submitted to EG Multimedia'99-workshop of EUROGRAPHIC'99, OPERA project, INRIA Rhone-Alpes, 1999.    

[28]

Sabry-Ismaël L., Schéma d'exécution pour les documents multimédia distribués, Doctorat d'informatique, Université Joseph Fourier, janvier 1999.  

[29]

Y.Tonomura, A.Akutsu, Y.Taniguchi, G.Suzuki, Structured Vidéo Computing, NTT Human Interface Laboratoires, 1994 IEEE.  

[30]

L.Villard, Spécification de relations spétio-temporelles dans un document multimédia, DEA Informatique, Université Joseph Fourier, Grenoble, Juin 1998.  

[31]

W3C, Extensible Markup Language (XML), http://www.w3.org/TR/REC-xml, Février 1998.

[32]

W3C, XML Specification DTD (XML spec), http://www.w3.org/TR/REC-xml, September 1998  

[33]

R.Weiss, A.Duda, D.A.Gifford, Composition and Search with a Vidéo Algebra, 1995 IEEE.