Ingénierie des documents audiovisuels : le projet FERIA. Une approche centrée sur la description des contenus

Nom de la revue. Volume X – n° X/2002, pages 1 à X

Ingénierie des documents audiovisuels : le projet FERIA Une approche centrée sur la description des contenus Vincent Brunie — Jean Carrive — Laurent Vinet Institut National de l’Audiovisuel Thème de Recherche Description des Contenus Audiovisuels 4, avenue de l’Europe – 94360 Bry-sur-Marne cedex {vbrunie, jcarrive, lvinet}@ina.fr RÉSUMÉ. Cet article présente un modèle d’ingénierie des documents audiovisuels centré sur la description de contenus, ainsi que le framework FERIA, une plateforme logicielle générique qui en est une instrumentation. Il montre en quoi la norme MPEG-7 ne permet pas de répondre aux besoins de ce modèle et il décrit le langage FDL (Feria Description Language) qui répond aux besoins exprimés et sur lequel repose le framework. Ce framework propose un outillage complet de manipulation des descriptions, d’accès aux contenus ainsi qu’une architecture ouverte d’analyse automatique. Enfin, deux applications développées avec le framework sont exposées.

ABSTRACT. This article presents a model of audiovisual document engineering based on content description, as far as the FERIA framework, a generic software platform which implements this model. It shows why MPEG-7 is unable to fulfil the requirements of this model and it describes FDL (Feria Description Language) in top of what the framework is built. This framework offers a complete toolkit to manipulate descriptions, to access contents, as far as an open architecture for automatic analysis. Finally, two applications developed with the framework are shown.

MOTS-CLÉS : documents audiovisuels, multimédia, description de contenu, langages de description, framework, indexation vidéo automatique, publication multimédia. KEYWORDS: audiovisual document, multimedia, content description, description languages, framework, automatic video indexing, multimedia publishing.

2 Nom de la revue. Volume X – n° X/2002

1. Introduction

Il est aujourd’hui communément admis que les technologies numériques résolvent correctement les problèmes de disponibilité des documents en proposant les formats, les réseaux et les moyens de stockages qui permettent d’encoder, d’échanger et de conserver les contenus, qu’ils soient textuels, musicaux, audiovisuels ou multimédias. Même si tous les problèmes ne sont pas encore résolus dans ces domaines, les enjeux actuels semblent maintenant plutôt se trouver dans la mise en place de procédés permettant une organisation efficace de ces contenus dans le cadre dans lequel ils sont utilisés.

Les problèmes d’organisation des contenus couvrent des champs très vastes puisqu’il s’agit de savoir comment représenter et manipuler les contenus pour un usage particulier. Or, il est aujourd’hui banal de penser qu’il est souhaitable de disposer d’une technologie permettant de prendre en compte de façon unifiée l’ensemble des usages donnés pour une catégorie de contenus donnée. Par exemple, XML, ainsi que son ancêtre SGML ont permis de mettre en place une ingénierie des documents textuels qui permet avec un ensemble d’outils reposant sur une même base technique de répondre à des situations extrêmement variées.

Dans le domaine spécifique des documents audiovisuels, les problèmes directement liés à l’encodage des contenus occupent encore une place prépondérante du fait des enjeux industriels immédiats qui y sont associés. Néanmoins, le besoin se fait également sentir de mettre en place une ingénierie des documents audiovisuels capable de répondre avec des techniques génériques aux besoins d’un vaste champ applicatif.

Dans cet article, nous proposons un modèle pour l’ingénierie des documents audiovisuels centré sur les descriptions de contenus ainsi qu’une instrumentation expérimentale de ce modèle. Après avoir explicité et justifié cette approche qui s’oppose à une approche centrée sur les contenus eux-mêmes, plus courante dans les pratiques actuelles de l’audiovisuel, nous décrivons le modèle retenu, puis l’instrumentation technique qui en est faite dans le cadre du projet FERIA (Framework pour l’Expérimentation et la Réalisation Industrielle d’Applications multimédia). Ensuite, nous montrons comment mettre en œuvre les outils ainsi obtenus dans des applications réelles s’appuyant sur une nouvelle ingénierie des documents audiovisuels.

2. L’organisation des contenus audiovisuels

Pour chacun des acteurs ayant besoin de manipuler des contenus multimédias se pose la question de savoir quelle est l’organisation qui répond le mieux à ses besoins. Il n’y a pas si longtemps, ces activités étaient limitées aux filières classiques de l’audiovisuel : producteurs, diffuseurs ou encore archives. Chaque filière avait développé des pratiques adaptées à ses besoins et créé un ensemble de

FERIA 3

métiers correspondants. Même si elle n’était probablement pas exempte de défauts, cette organisation tendait vers une optimisation des processus en jeu.

La numérisation des contenus a bouleversé cette organisation. En effet, la large disponibilité des outils numériques fait que les rôles de chacun sont aujourd’hui beaucoup moins distincts. En particulier, les rôles des professionnels et des particuliers sont moins différenciés depuis qu’il est possible pour tous de tourner, de produire et de diffuser ses propres contenus multimédias. Au sein même des professionnels, il est également de plus en plus évident que l’allègement technique des moyens de production ouvre de nouvelles possibilités. Il nous semble alors particulièrement utile de disposer d’une technologie permettant de développer facilement de nouvelles applications de façon à accompagner, voire même à susciter le processus d’évolution des usages.

2.1. Des besoins particuliers

L’approche que nous proposons répond potentiellement à de nombreux besoins dont nous donnons ici quelques exemples.

2.1.1. Les collections du grand public

Si l’on a pu penser aux premières heures du numérique qu’il allait être possible de gérer de façon directe et aisée les contenus, on s’aperçoit que même un volume restreint de documents, textes, images, ou vidéos, rend nécessaire leur organisation. Ainsi, on voit apparaître une offre logicielle destinée à la gestion de collections de documents multimédia à l’échelle individuelle : photos (Picasa, Photoshop Album), musique (iTunes) et vidéo (iDive). Bien que destinés aux particuliers, et donc à des bases documentaires de taille relativement réduites, ces logiciels incorporent pour la plupart des technologies avancées en termes d’analyse de contenu, de représentation des descriptions et d’ergonomie. De plus, les fonctionnalités d’organisation proposées par les outils les plus populaires incorporent souvent des techniques très proches de l’état de l’art. Pourtant ces applications sont encore loin d’avoir atteint leur complète maturité et ne permettent de gérer des collections importantes à l’échelle d’un particulier qu’au prix d’un effort et d’une rigueur difficiles à exiger d’un non spécialiste.

2.1.2. Catalogue et navigation par le contenu

Un autre besoin difficile à remplir pour les détenteurs de grands catalogues audiovisuels, musicaux et multimédia est la création de services destinés au grand public, ne serait-ce qu’en lui proposant un catalogue de son offre commerciale. En effet, les grands acteurs affichent tous aujourd’hui leur ambition de mettre en place une offre de contenus vendus à la demande avec une granularité plus faible que celle rendue possible par la distribution de supports enregistrés (CD et DVD). Il serait ainsi possible de proposer par exemple des chansons à l’unité, des scènes


cultes de films ou de séries télévisées, des reportages de journaux, des compléments payants à des diffusions broadcast ou encore l’extrait dans lequel on est soi-même passé à la télévision. Néanmoins, pour l’instant aucun acteur de l’audiovisuel n’a pris le risque de se lancer et aucune offre sur des volumes importants n’est réellement disponible malgré les effets d’annonce d’acteurs technologiques spécialisés ou de grands détenteurs de contenus.

Il serait pourtant intéressant de proposer des produits nouveaux aux consommateurs, s’appuyant par exemple sur la navigation de proche en proche dans les contenus eux-mêmes. Néanmoins, le travail documentaire nécessaire pour arriver à proposer de tels produits est considérable. Il consiste à repérer dans les contenus chacun des éléments sur lesquels la navigation pourrait s’appuyer et, s’il est réalisé à la main, n’a aucune chance d’être rentabilisé.

2.1.3. Publication multisupport

La publication multisupport est un concept apparu il y a quelques années et qui commence à devenir un besoin réel et urgent qui n’est pas encore absolument rempli. Les producteurs et diffuseurs de contenus se trouvent aujourd’hui confrontés à une multiplication des terminaux de réception, téléviseurs traditionnels, terminaux numériques avec ou sans capacité d’enregistrement, avec ou sans voie de retour, lecteurs de DVD, ordinateurs connectés, DVD-Rom, téléphones mobiles, stations de jeu, etc. En plus de ces différentes catégories, on retrouve dans chacune différentes marques cherchant à se différencier de ses concurrentes par des possibilités spécifiques qui nuisent aux efforts de standardisation des consortiums d’industriels et réduisent l’interopérabilité des contenus produits. Enfin, l’amélioration de la qualité des médias audiovisuels « bruts », qu’il s’agisse de haute définition de l’image ou de son multicanal, introduit un critère de différenciation entre les terminaux selon leur capacité à interpréter ces nouveaux formats et à les reproduire de façon optimale. La convergence annoncée des terminaux de réception n’a donc pas eu lieu et rien ne semble indiquer que cela puisse être le cas dans un terme prévisible. Les producteurs de contenus doivent donc produire pour des cibles de plus en plus variées.

Comment produire des programmes pour toutes ces cibles ? S’il s’agissait simplement d’une piste vidéo et d’une bande son, la diffusion vers ces différentes cibles se résumerait à un problème de conversion de format. Par contre, il est bien évidemment tentant de profiter des nouvelles possibilités offertes par ces plateformes numériques. L’interactivité qu’elles procurent permet d’offrir des services intéressants. Le téléachat et les jeux sont les premiers à avoir trouvé un modèle économique s’appuyant sur ces technologies, mais il est également envisageable de fournir des contenus comparables avec ceux que l’on trouve aujourd’hui sur des DVD : navigation, incrustations interactives, commentaires audio, multi angle, making of, etc. La question qui se pose alors est celle de la production de contenus interactifs pour ces différentes cibles. Pour l’instant, chaque plateforme interactive possède son propre environnement auteur permettant

FERIA 5

d’exploiter au mieux ses capacités. Produire à destination de plusieurs plateformes est donc une opération coûteuse parce qu’elle nécessite de faire plusieurs fois le même travail d’authoring et de test dans des environnements différents, ainsi que d’adapter manuellement les scénarios d’interactivité aux capacités de chaque plateforme. La création de contenus interactifs pour ces nouvelles plateformes est donc aujourd’hui limitée à des expérimentations dont chacune est destinée à une plateforme particulière, donc à un public très limité, et ne rentrent pas dans un cadre économiquement viable.

2.2. Caractérisation d’une classe d’applications

Les exemples donnés ci-dessus peuvent se décomposer en une combinaison de fonctionnalités élémentaires bien définies. Nous en proposons une liste à partir desquelles nous pensons qu’il est possible d’implémenter, outre les exemples particuliers donnés ci-dessus, une famille d’application vaste et diversifiée :

– Identification : il est avant tout primordial de pouvoir identifier de façon univoque chaque unité de contenu, qu’il s’agisse d’un document, d’une piste donnée d’un document, d’un fragment de document ou encore d’une collection de documents ;

– Adressage spatial et temporel : ensuite, il est nécessaire de munir les contenus d’un système de coordonnées spatio-temporel afin de pouvoir y repérer des fragments, qu’il s’agisse de segments temporels dans une vidéo ou un son, d’une région dans une image fixe ou encore d’une région éventuellement mouvante dans une vidéo ;

– Description : sur la base des systèmes d’identification et d’adressage des contenus, on souhaite pouvoir associer des descriptions des éléments repérés exprimées dans un langage de description qui est exposé dans la section 3 ;

– Manipulation : en s’appuyant sur les descriptions associées aux contenus, il doit être possible de manipuler les éléments décrits. Ces manipulations sont similaires aux traitements les plus simples réalisés d’une part par les systèmes de montage audiovisuel – découpage temporel et remontage – et par les systèmes d’infographie d’autre part – copier/coller graphique – mais elles s’en distinguent principalement par le fait qu’elles sont faites sous le contrôle de descriptions. En fonction des besoins des applications, ces opérations de manipulation sont accessibles directement à l’utilisateur, à des outils de visualisation, à des outils d’analyse automatique de la vidéo ou du son ou encore à des outils de publication.

Ces fonctionnalités nous semblent être des conditions nécessaires pour définir un système documentaire pour l’audiovisuel. Le framework FERIA propose leur mise en œuvre en un système d’ingénierie des documents audiovisuels qui permettra la construction de nouvelles applications reposant sur la combinaison de ces quatre types de fonctionnalités.


2.3. La manipulation virtuelle des contenus

Avec l’ensemble de fonctionnalités élémentaires décrit ci-dessus, nous pouvons maintenant disposer d’un système de manipulation virtuelle des contenus. En effet, nous proposons de faire reposer le développement de la classe d’applications définie ci-dessus sur un principe de manipulation virtuelle des contenus.

Par manipulation virtuelle des contenus, nous entendons la volonté de retarder le plus possible l’opération de manipulation effective du contenu – au sens défini ci-dessus – en effectuant sur les seules descriptions des opérations qui représentent ces manipulations. De ce point de vue, les descriptions sont alors des poignées sur les contenus les mobilisant en de nouvelles organisations dont les caractéristiques sont exprimées en utilisant les possibilités de composition offertes par le langage de description. Nous espérons ainsi non seulement améliorer les performances des applications parce qu’elles manipulent alors des données de plus petite taille, c’est-à-dire des descriptions au lieu de contenus, mais nous espérons surtout faciliter leur implémentation afin d’accompagner l’évolution des usages.

La manipulation virtuelle des contenus est une généralisation à la production multimédia du paradigme du montage virtuel maintenant devenu classique en production cinématographique et audiovisuelle. Si nous prenons l’exemple du montage image en cinéma, chaque bobine de film contient un certain nombre de prises de vue qui correspondent à différentes versions (prises) des plans composant le film. En montage classique, le premier travail consiste à regarder l’ensemble du matériel tourné, les rushes, et à garder la meilleure prise de chaque plan, c’est le dérushage. Ensuite, le montage effectif est réalisé par coupage et collage physique de la pellicule dans l’ordre prévu par le scénario. Une fois le montage finalisé, on obtient donc un film constitué de différents segments de pellicules assemblés par du scotch. On réalise alors une copie qui servira de master pour les étapes de post production1.

En montage virtuel, la phase de dérushage est remplacée par deux opérations distinctes. La première étape consiste à identifier les prises de vues et leur emplacement sur la pellicule et à le noter dans un fichier interprétable informatiquement, puis à réaliser une version de prévisualisation des contenus par numérisation en faible résolution. Nous rentrons alors dans le monde des contenus virtuels, où les manipulations sur les supports de contenus sont remplacées par des opérations sur des références à ces contenus. L’opération de montage est alors faite par construction d’une liste de montage (souvent nommée Edit Decision List, EDL) en y recopiant les coordonnées des segments choisis dans l’ordre dans lequel ils doivent apparaître dans le futur film. Pour effectuer ses choix, le monteur s’appuie

1. Le montage vidéo analogique est également un exemple très intéressant, puisque le découpage physique de la bande vidéo est impossible et qu’il est alors nécessaire à chaque opération de montage de réaliser des copies qui, de génération en génération, altèrent de façon très importante la qualité du signal.

FERIA 7

sur les versions de prévisualisation des contenus. Ce montage est qualifié de virtuel car il ne met plus en jeu aucun support de contenus, il correspond simplement à un ensemble de manipulation de références à ces contenus. Dans notre terminologie, ces références sont des descriptions des rushes spécifiquement adaptées aux opérations de montage. Une fois le montage terminé, il faut tout de même obtenir un film sous forme d’une seule pellicule, ce que l’on fait dans une étape nommée conformation, qui consiste à construire de façon automatique une pellicule conforme à ce que dit l’EDL à partir des prises de vues originales. La phase de conformation nous replonge dans le monde des supports physiques de contenus.

Dans l’industrie cinématographique, le principal intérêt du montage virtuel par rapport au montage classique est de minimiser les opérations sur les pellicules. La phase de montage peut facilement donner lieu à de nombreux essais sans multiplier les phases de coupage / collage qui sont la partie coûteuse et non créative du travail. Le monteur dispose d’une liberté largement supérieure à un coût moindre. Il peut réaliser tous les essais souhaités, et lorsqu’il juge le résultat satisfaisant, la conformation peut être réalisée automatiquement et de façon définitive.

Nous souhaitons donc généraliser le paradigme du montage virtuel à la classe des applications caractérisée ci-dessus. Ceci conduit à des applications, représentées à la figure 1, qui :

– Sont centrées sur la notion de description, celle-ci reposant sur un langage de description qui conditionne entièrement les possibilités du système ;

– Sont alimentées en contenus par virtualisation, c’est-à-dire que les contenus sont nécessairement représentés dans le système par une description ;

– Effectuent des traitements sur les descriptions en en produisant de nouvelles ; ces traitement s’appuient sur des descriptions existantes, mais peuvent si accéder aux contenus de façon par exemple à pouvoir le visualiser ou l’analyser ; ces traitements peuvent être réalisés par un opérateur ou bien par un outil automatique ;

– Sont capables de publier le résultat de leurs traitements vers des formats totalement indépendants du système FERIA, le processus de publication étant guidé par les descriptions produites.


Traitements manuels

Traitements automatiques

Publicationde contenus

Web

TV

TV enrichie

DVD Rom

etc.

Contenus AV

Descriptions

Contenus AV

Virtuali

sation

Stockage

Figure 1. Applications de production par manipulation de descriptions

Un tel système est donc par définition centré sur un langage de description qui fait l’objet de la section suivante.

3. Langage de description de l’audiovisuel

La « virtualisation » des contenus impose de pouvoir décrire ces contenus de manière abstraite. Il faut les modéliser pour pouvoir les manipuler. De plus, la diversité des usages visés et la nécessité de répondre à de nouveaux besoins prescrivent une extensibilité de cette modélisation. Le formalisme Feria Description Language (FDL), langage de description de l’audiovisuel que nous présentons ici, répond aux deux grands principes suivants :

1) Il permet d’exprimer de manière non ambiguë ce qui est spécifique aux documents audiovisuels, comme l’identification des médias ou la localisation temporelle ou spatiale dans les contenus ;

2) Il est extensible, c’est-à-dire qu’il permet de définir de nouveaux modèles. On pourra alors parler de métamodèle ou de métalangage.

Les travaux les plus importants dans le domaine de la description de contenus audiovisuels se sont faits autour de la définition de la norme MPEG-7. Nous présentons tout d’abord cette norme, nous donnons ensuite les conditions devant être respectées par notre langage, conditions proches de celles annoncées initialement par MPEG-7, puis nous montrerons pourquoi MPEG-7 ne les respecte pas. Nous décrirons alors le formalisme FDL proprement dit.

FERIA 9

3.1. MPEG-7

La norme ISO MPEG-7 (MPEG-7, 2001) a été élaborée depuis 1996 et publiée en 2001 par le Moving Picture Experts Group (groupe de travail MPEG : ISO/IEC JTC 1/SC 29/WG 11) en charge du développement de normes internationales de format de représentation de l’image, de la vidéo et du son. À la différence des normes MPEG précédentes (MPEG-1, MPEG-2 et MPEG-4) qui permettaient de coder directement le contenu en définissant un format de compression, MPEG-7 est un format de « Description de Contenus Multimédias ». La norme définit en premier lieu des descripteurs (Descriptor) qui permettent de caractériser les contenus ; il s’agit en général des descripteurs d’assez bas niveau comme la couleur, la texture ou le timbre. MPEG-7 distingue les descripteurs qui ne concernent que l’image (Visual), les descripteurs qui ne concernent que le son (Audio) et les descripteurs qui s’appliquent aux deux modalités (Multimedia).

Ces descripteurs peuvent être organisés entre eux selon plusieurs dimensions, en particulier temporelle, spatiale et conceptuelle. On parle alors de schémas de description (Description Scheme), qui forment des descripteurs de plus haut niveau. Les descripteurs et les schémas de description sont exprimés dans un langage de définition de description (Description Definition Language). Le langage FDL se situe approximativement au même niveau que le DDL MPEG-7. MPEG-7 a finalement fait le choix de prendre pour DDL le langage de schéma XML XML Schema (XML Schema, 2001), ce qui constitue à notre sens l’une des principales faiblesses de cette norme. Cet aspect sera étudié plus en détail dans la section 3.3.

3.2. Le cahier des charges

Les deux principes généraux évoqués en début de section 3 peuvent être complétés par un certain nombre de conditions que doit remplir le langage de description. Ces conditions sont proches de celles que s’étaient fixées les auteurs de la norme MPEG-7 de description de documents multimédias (Pereira, 2001) au démarrage de leurs travaux, conditions que nous considérons pour beaucoup d’entre elles comme tout à fait pertinentes. Nous verrons par la suite les raisons pour lesquelles nous considérons que MPEG-7 ne répond pas à ce cahier des charges.

– Hiérarchie de descripteurs : les descripteurs peuvent être organisés en taxinomie selon une relation d’héritage ;

– Extensibilité : le langage doit fournir un mécanisme permettant de définir de nouvelles classes de descripteurs ;

– Composition : les descripteurs peuvent être composés entre eux, de manière temporelle, spatiale, structurelle ou conceptuelle ;

– Lien au média : les descripteurs peuvent référencer les contenus qu’ils décrivent ;


– Indépendance par rapport au média : ce lien au média doit se faire indépendamment du codage et de l’emplacement physique des médias ;

– Identification : le langage doit fournir un mécanisme d’identification unique des médias, des schémas de description et des descriptions ;

– Types de base : le langage doit fournir les types de base communément utilisés ainsi que les types permettant la localisation temporelle et spatiale ;

– Syntaxe XML : le langage doit être muni d’une syntaxe XML pour les schémas de description et les descriptions, permettant ainsi l’échange et le stockage.

3.3. Critique de MPEG-7

La norme MPEG-7 quant à elle ne répond pas à tous ces principes (Troncy et al., 2004). Nous en résumons ici les raisons principales. La première critique que nous faisons à MPEG-7 est le choix de son langage de définition de descriptions (DDL). En effet, MPEG-7 a choisi pour DDL le langage XML Schema. Le choix de ce langage pose un certain nombre de problèmes. En premier lieu, XML Schema est un langage de définition de schémas XML généraliste qui ne prend pas en compte les spécificités de l’audiovisuel, et en particulier le fait de pouvoir relier temporellement ou spatialement les descripteurs avec les contenus qu’ils décrivent.

De plus, malgré les mécanismes d’extension et de restriction de schéma proposés par XML Schema, il ne s’agit pas à proprement parler d’un langage à objets et ces mécanismes ne sont pas de véritables mécanismes d’héritage (Brown et al, 2000). Il est par conséquent très difficile d’exprimer de véritables hiérarchies de descripteurs, voire impossible pour certaines configurations pourtant courantes, comme les hiérarchies parallèles.

Enfin, contrairement à ce qui avait été annoncé (Pereira, 2001), MPEG-7 n’est pas extensible : la norme ne définit pas de manière claire la façon dont on pourrait définir ses propres schémas de description. MPEG-7 peut donc être considéré comme un ensemble vaste mais clos de descripteurs. L’expérience montre en outre que ces descripteurs ne couvrent pas l’ensemble des usages visés. Enfin, MPEG-7 n’est pas modulaire, et si l’on souhaite n’utiliser qu’un ensemble restreint de descripteurs, on est tout de même amené à prendre en compte la norme dans sa totalité. Plus concrètement, pour valider un descripteur, un analyseur syntaxique (parser) devra considérer l’ensemble des schémas de description.

3.4. Les principes de FDL

La méthodologie de définition de FDL a été guidée par plusieurs préoccupations. Tout d’abord, il s’agissait de faire reposer le langage sur une modélisation abstraite de type objet, et non sur une modélisation syntaxique de type XML. Ensuite, le langage devait en priorité définir un petit nombre de classes de haut niveau ainsi que

FERIA 11

la manière de les spécialiser, plutôt que de chercher à définir immédiatement des classes spécifiques. Enfin, un soin particulier devait être apporté à la manière de localiser spatialement et temporellement descripteurs et médias décrits.

Classiquement, il existe deux manières principales d’étendre des classes d’objets : par héritage et par composition. Les deux manières sont utiles. Ainsi, dans l’exemple simpliste suivant (voir figure 2), un plateau de journal télévisé (Plateau-JT) est défini par héritage comme une spécialisation de Plateau, alors qu’une Emission est définie par composition comme la succession temporelle d’un plateau et d’un reportage.

temps

Plateau Reportage

suivi-de

Plateau-JT- présentateur

Reportage-JT- reporter

suivi-de

Emission :

Journal TV :

Figure 2. Héritage et composition de descripteurs

Il existe plusieurs formalismes opérationnels permettant d’exprimer les relations d’héritage. Les plus connus sont les langages à objets de type Java ou C#. Ils présentent l’avantage d’être implémentés dans des environnements de développement complets permettant par exemple l’accès à des bases de données ou la manipulation physique (décodage, accès, lecture) des médias. Les logiques terminologiques, ou logiques de description (Napoli, 1998) forment une autre famille de formalismes, qui permettent d’exprimer de façon formellement bien fondée la relation d’héritage, appelée alors relation de subsomption, et qui fournissent des mécanismes d’inférence permettant par exemple d’organiser automatiquement la hiérarchie des classes selon cette relation de subsomption.

Les relations de composition, en revanche, sont plus difficiles à exprimer, tout d’abord parce que plus variées (composition temporelle, spatiale, agrégation), et ensuite parce que plus difficiles à définir formellement. Il est en particulier souvent difficile de définir une relation de subsomption calculable entre des classes d’objets composites. D’importants travaux ont été réalisés, par exemple, sur les hiérarchies d’objets construits avec des relations méréonimiques du type « partie-de ». Dans l’exemple de la figure 2, on peut ainsi définir une relation de subsomption entre « Journal-TV » et « Emission » : tout journal-TV est nécessairement une émission (Carrive et al., 2000).


3.4.1. Modèle documentaire

FDL repose tout d’abord sur un modèle documentaire qui définit des notions telles que document, média ou collection, c’est-à-dire, schématiquement, ce qui peut être décrit.

– Contenu : un contenu est une manifestation physique d’un document (au sens courant) audiovisuel ;

– Piste : un contenu peut posséder plusieurs pistes audio et vidéo (piste vidéo, piste musicale, différentes pistes de dialogues en différentes langues) ;

– Média : un média est une abstraction d’un contenu qui permet de s’affranchir de la localisation physique de ce contenu. Il est ainsi possible de manipuler le même média référençant un fichier vidéo situé sur le disque dur d’un ordinateur portable ou « le même » contenu situé sur un serveur centralisé ;

– Document : classiquement du point de vue documentaire, un document possède un statut particulier ; un document est identifié et il peut être référencé, catalogué et indexé ;

– Extrait : un extrait est une partie continue d’un document. Un extrait n’a pas de véritable statut documentaire et sert essentiellement à constituer des collections (voir ci-dessous) ;

– Collection : les collections peuvent être des ensembles d’extraits ou des ensembles de documents formant un tout cohérent d’un point de vue documentaire. Il peut s’agir par exemple de l’intégrale des numéros d’une émission comme Le Grand Échiquier pour les collections de documents, ou d’une collection d’extraits établie sur un thème particulier, par exemple sur Georges Brassens.

3.4.2. Modèle conceptuel et modèle compositionnel

L’objectif de FDL est de permettre de décrire des objets audiovisuels, ces objets pouvant être des documents et les pistes les constituant, des collections de documents ou des collections d’extraits, les éléments de ces collections pouvant également être décrits. La notion centrale de FDL est la notion de descripteur (Descriptor). FDL permet de prendre en compte à la fois les aspects conceptuels (ou ontologiques) et les aspects compositionnels (ou méréologiques) des descriptions. Ainsi, un descripteur peut être défini à la fois d’un point de vue conceptuel par un ensemble de propriétés (Property) et d’un point de vue compositionnel par sa structure (Structure). Le parti pris est ici de bénéficier des apports des langages à objets pour les aspects ontologiques et de laisser le champ le plus ouvert possible pour les aspects compositionnels en offrant un certain nombre de structures élémentaires et surtout en autorisant la définition de nouveaux types de structures. Ces principes sont illustrés sur la figure 3. Ce schéma illustre également le fait que les schémas de description (Description Scheme) sont représentés par des classes (au sens objet) de descripteurs dans le sens des langages à objets. De la même manière, les définitions de propriétés et les définitions de structures utilisées dans les schémas de descriptions sont représentées dans le langage par des classes.

FERIA 13

Descriptor(D)

Property- value Structure

Descriptor class(DS)

Property class- type Structure class

instance instance instance

Figure 3. Descripteurs, propriétés et structures

La figure 4 donne un exemple de schéma de description pour le journal télévisé simpliste illustré par la figure 3. Un journal télévisé est composé (« a pour structure ») un plateau qui a pour propriété un présentateur, et un reportage qui a pour propriété un reporter.

Comme on le voit sur les figures 3 et 4, les propriétés sont typées. Les types autorisés sont :

– les types courants (nombre, entiers, nombres à virgule flottante, chaîne de caractères, listes),

– les références vers d’autres descripteurs, – les types TimeRef et SpaceRef permettant la localisation temporelle et la

localisation spatiale. Ces types permettent d’exprimer les coordonnées temporelles et spatiales indépendamment de la fréquence d’échantillonnage et de la résolution de l’image.

Journal-TV(Descriptor class)

Structure-Journal(Structure class)- no gap, no overlap

Plateau(Descriptor class)

Présentateur(Property class)- Type = string

Reportage(Descriptor class)

Reporter(Property class)- Type = string


Figure 4. Exemple de schéma de description

3.5. Implémentation objet

L’implémentation de FDL dans l’environnement .NET (Gordon et al., 2001) cherche à respecter au plus près les principes exposés ci-dessus. En particulier, un mécanisme de métaclasses a été mis en œuvre qui permet de représenter les schémas de description et les descriptions comme des classes et des instances. L’environnement .NET n’offrant pas de véritable modèle de métaclasses, nous avons implémenté un tel modèle en représentant explicitement les classes de descripteurs (i.e. les schémas de description) comme des instances d’une métaclasse DescriptorClass. Ces principes sont illustrés par la figure 5. Cette figure représente de manière légèrement simplifiée la définition et l’instanciation d’un descripteur Shot. Le schéma de description est représenté par l’instance « Shot class » de la classe « DescriptorClass ». Cette instance « Shot class » peut être créée par exemple à partir d’une définition XML du schéma de description, comme on le verra plus loin. Elle hérite, au sens de FDL, de l’instance « Descriptor class », qui définit le descripteur le plus général. Ce lien d’héritage FDL signifie de manière classique que toutes les propriétés de la classe mère sont reportées dans la classe fille.

A partir de cette instance « Shot class », la classe .NET « Shot » est générée dynamiquement en utilisant les mécanismes de réflexivité de .NET. De manière homogène à l’arbre d’héritage des métaclasses, la classe « Shot » hérite de la classe « Descriptor ». Les propriétés des descripteurs sont matérialisées par autant de variables d’instance de la classe générée.

FERIA 15

DescriptorClass

Shot class

Descriptor

Shot (générée)

Descriptor class

shot-17

Classe .NET

Instance .NET

Instanciation .NET

Instanciation FDL

Héritage .NET

Héritage FDL

Figure 5. Mécanisme d’instanciation des schémas de description

Une fois la classe « Shot » générée, il suffit pour créer une description d’instancier cette classe. Cela peut se faire de deux manières différentes, selon que les schémas de description sont fixes ou non. S’ils le sont, les classes peuvent être générées dans une première phase de développement, sauvegardées dans une librairie dynamique .NET, et utilisées par le développeur dans une deuxième phase de développement. Si les schémas de description ne sont pas fixes, c’est-à-dire s’ils peuvent être créés ou modifiés par l’application, les classes .NET seront générées et instanciées dans un même programme. Ce sont alors les mécanismes de réflexivité de .NET qui permettront cette instanciation. Il est important de noter ici que le fait de pouvoir utiliser les classes générées à partir d’une bibliothèque de classe n’est qu’une facilité pour le développeur et que dans les deux cas ce sont les mêmes instructions qui s’exécutent.

3.6. Syntaxe XML

FDL est doté d’une syntaxe XML pour les schémas de description et pour les descriptions. Rappelons, comme nous l’avons indiqué plus haut, que FDL ne repose pas sur une modélisation XML, qui n’est utilisée que pour l’échange et le stockage. Du point de vue syntaxique, un schéma de description peut-être vu comme un langage engendré par le métalangage FDL. Afin de faciliter le contrôle syntaxique, le standard du W3C XML Schema est utilisé, d’une part pour les schémas de description, pour lesquels un schéma XML a été défini, et d’autre part pour les


descriptions, où, pour chaque schéma de description, un schéma XML est automatiquement généré. Ce principe est illustré sur la figure 6.

Shot17.xmlShot.xmlDS.xsd

FDL DS Shot shot-17contrôle contrôle

Shot.xsdvalidationsyntaxique

validationsyntaxique

générationautomatique

Figure 6. Contrôle syntaxique de FDL

Le choix a été fait d’une spécificité maximale de la syntaxe des descriptions. Ainsi, par exemple, les noms de balise sont spécifiques à chaque schéma de description. Cela contraint à disposer du schéma de description pour l’analyse (parsing) des descriptions, en particulier pour savoir à quel type (propriété, descripteur ou structure) correspondent les balises. Cependant, cela permet d’avoir un contrôle syntaxique fort des descriptions, grâce en particulier au schéma XML généré à partir des schémas de description

4. Instrumentation : le framework FERIA

Le framework FERIA a pour objectif direct de faciliter le développement de la classe d’applications décrite en section 2.2 en proposant un framework générique implémentant des fonctionnalités élémentaires permettant la représentation et la manipulation des contenus par l’intermédiaire de leurs descriptions. Un framework est en général considéré comme une application « semi-complète », définie par un ensemble de hiérarchies de classes collaborant entre elles selon un schéma prédéfini de façon à offrir une architecture réutilisable pour une famille d’applications proches (Fayad et al., 1997).

L’approche adoptée pour parvenir à remplir ces objectifs repose sur les trois piliers suivants :

1) Une architecture de type « framework », présentée dans la section 4.2, qui propose une implémentation des mécanismes génériques de manipulation des descriptions et un ensemble d’API, et qui peut être spécialisé en différentes applications. Les mécanismes génériques mis en œuvre dans le projet sont les suivants :

- identification unifiée des documents audiovisuels pour assurer l’indépendance par rapport aux formats et à la localisation des médias,

FERIA 17

- système de stockage et de manipulation de tout type de description FDL,

- serveur d’analyse automatique permettant une gestion unifiée des outils (ajout, paramétrage, chaînage, lancement),

- moteur de publication permettant de produire des contenus pour différentes destinations (DVD Rom, site web, télévision interactive, etc.) à partir des mêmes données (contenus initiaux et descriptions) ;

2) Une approche centrée sur les descriptions qui unifie la représentation et les modes de traitement de l’ensemble des données gravitant autour des contenus ;

3) L’utilisation de normes ou de standards technologiques reconnus dans les milieux industriels, repris dans la section 4.1.

Application de production(back office)

Publication(médias et données)

RessourcesExternes(front office)

Producteur

Usager

Développeur d’application

Se spécialise en

produit

utilise

Framework(environnement

de développement d’applications)

Figure 7. Instanciation du framework en une application

Le cycle d’utilisation, représenté sur la figure 7, est le suivant : le framework permet à un développeur d’applications de créer des applications servant à la production de nouveaux médias à partir de descriptions de médias existants. Ces applications, dites applications de back office, sont utilisées par un producteur, alors que le média final est destiné à un usager et sera mobilisé par une des ressources externes au framework, que l’ont peut qualifier considérer dans le cas d’un logiciel (application web ou de TV interactive) comme une application de front office. Par exemple, dans le cas d’une application back office de production d’une offre de corpus thématique accessible en ligne à partir d’une base d’archives, le producteur est le documentaliste chargé d’établir cette offre et l’usager est le réalisateur cherchant des images d’archives pour illustrer un documentaire. Il utilise pour cela une application web front office qui lui présente les contenus et les données générées par le producteur.


4.1. Choix technologiques

Le framework a une vocation mixte au sens où il est à la fois susceptible de servir d’environnement expérimental dans un environnement de laboratoire et d’environnement de développement d’applications susceptibles d’être utilisées en production. Cette possibilité est très importante par rapport aux raisons qui motivent ces travaux telles qu’elles ont été énoncées au début de cet article, puisqu’elle facilite le transfert des technologies expérimentales vers leur utilisation en production, permettant ainsi de raccourcir de façon significative le cycle de retour des usages sur les développements technologiques.

Ceci repose bien entendu sur les choix architecturaux du framework explicités dans la section suivante, en particulier sur la notion d’API, mais aussi sur le choix parmi les propositions technologiques disponibles de celles susceptibles d’offrir les meilleurs compromis entre les critères les plus importants. Pour cela, les choix technologiques effectués par le projet ont principalement été guidés par les besoins du développement d’application à partir du framework. Les quelques principes suivants ont été retenus :

– l’utilisation maximale de standards industriels, notamment pour l’environnement de développement orienté objet, les technologies d’applications distribuées, le décodage et les serveurs de contenus, le stockage XML,

– l’utilisation d’un environnement de développement « habituel » pour les développeurs d’applications, mais aussi pour les développeurs d’outils d’analyse automatique,

– la facilitation du déploiement des applications et des serveurs. Les principales options techniques sont les suivantes :

– technologie objet Microsoft .NET (Gordon et al., 2001) pour le développement orienté objet ; le langage privilégié est C#, mais la plateforme .NET supporte un grand nombre d’autres langages,

– communication par web services pour l’environnement distribué, – développement des outils d’analyse automatique multiplateforme : un outil

d’analyse peut être soit développé dans l’environnement .NET du framework, soit sur une autre plateforme, par exemple en C sur une machine Linux,

– développement des interfaces utilisateurs par composants graphiques (user controls) utilisables dans l’environnement de développement Visual Studio .NET,

– décodage et restitution de média basés sur Microsoft DirectX, – streaming de média Microsoft Windows Media Services, – base de données XML X-Hive.

FERIA 19

4.2. Architecture

L’architecture logicielle du framework FERIA repose essentiellement sur un certain nombre de services définis par leurs interfaces (ou API, pour Application Programming Interface). On distingue parmi ces services d’une part des serveurs, au sens courant du terme, c’est-à-dire essentiellement un service de données, et des moteurs, qui effectuent des traitements. Les deux serveurs principaux sont le serveur de descriptions, qui permet d’accéder en particulier aux descriptions et aux schémas de descriptions, et le serveur de contenus qui délivre les contenus audiovisuels. Les deux moteurs du système sont le moteur d’analyse, qui permet d’organiser et d’exécuter des outils d’analyse automatique (voir section 4.3), et le moteur de publication qui permet, à partir des descriptions et des contenus, de produire de nouveaux dans un format cible spécifique (site web, DVD, TV-I par exemple). Sur la figure 8 figurent ces services2 ainsi que, illustré par le rectangle central, le périmètre du framework. Comme on l’a dit et comme le suggère la figure, les services sont définis par leur API. Ainsi, il est possible d’avoir des implémentations différentes des mêmes services. C’est le cas, par exemple, pour le serveur de contenus. Une version dite « distante » en a été développée, qui repose sur une architecture de type serveur et qui est capable de fournir simultanément plusieurs flux audiovisuels. Une version dite « locale », plus légère et reposant sur un simple système de fichiers, permet ainsi d’accéder à des contenus stockés sur un ordinateur portable. Les APIs étant rigoureusement identiques, une même application peut utiliser indifféremment l’une ou l’autre implémentation. De plus, comme l’indique encore la figure, le framework propose un ensemble de classes et de mécanismes d’interaction entre ces classes facilitant le développement des applications. Ces classes outils permettent par exemple l’alimentation du serveur de contenus, la visualisation des documents, la visualisation et l’édition des descriptions et des schémas de description ou l’exécution des outils d’analyse.

2. Ne figurent pas sur le schéma certains éléments, tels par exemple que les bases de données permettant de stocker les informations propres au système (utilisateurs, mots de passe) ou la configuration des outils d’analyse, ou tels que le moteur de recherche, qui peut être vu comme faisant partie du serveur de descriptions.


Application

Outild’analyse

Moteurd’analyse

Serveurde contenus

Moteur depublication

Serveurde descriptions

API API API API

APIFramework

Outild’analyse

API

API

Figure 8. Périmètre du framework FERIA

4.3. Analyse automatique

Un des objectifs du framework FERIA est de permettre d’utiliser des descriptions produites par des outils automatiques. Les outils d’analyses automatiques sont divers et variés et par principe non prédictibles dans leur comportement, voir (Foote, 1999) et (Brunelli et al., 1999) pour une description plus complète des outils utiles dans le cas des documents audiovisuels. Dans le but de permettre l’utilisation d’outils produits par le plus large spectre de développeurs, le framework FERIA organise donc l’ajout d’outils d’analyse automatique de la manière la moins contrainte possible. Le but est d’offrir à l’utilisateur (le développeur d’application) la possibilité d’intégrer des algorithmes très variés développés sur des plateformes hétérogènes (outil de transcription automatiques de la parole s’exécutant sur plateforme Linux, outil d’apprentissage de modèle de détection de texte développé sur plateforme Windows, etc.). Les outils intégrés dans une plateforme FERIA sont des services web utilisables par les applications développés à l’aide du framework. Ils sont contrôlés par le moteur d’analyse du framework qui les exécute en suivant un schéma d’analyse qui définit de façon déclarative leur ordonnancement et les flux de données entre outils d’analyse et avec le reste du framework.

Dans le framework FERIA, un outil d’analyse automatique est donc un service web qui :

– reçoit en entrée des contenus à analyser et éventuellement des descriptions générées par d’autres outils ou bien par un opérateur,

– produit en sortie des descriptions, et éventuellement des contenus, – possède un système d’introspection sur ses paramètres.

FERIA 21

L’intégration d’un outil d’analyse est facilitée par la présence d’API spécifiquement dédiées à l’analyse automatique. Celles-ci permettent principalement aux outils d’analyse de décoder les médias indépendamment de leur encodage et d’accéder aux données contenues dans les descriptions qui leur sont fournies en entrée à l’aide de fonctions renvoyant des types simples.

En plus des facilités d’intégration d’outils d’analyse existants, nous souhaitons que le framework puisse également être une plateforme pour le développement d’outils d’analyse, ce qui n’est pas forcément très facile lorsque les outils sont des serveurs par nature plus difficile à déboguer que des applications locales. Néanmoins, la plateforme .NET fournit des outils de mise au point s’utilisant de façon identique dans les applications locales et dans les applications distribuées. Les plateformes Linux n’offrant pas de telles facilités, le framework prévoit la possibilité qu’un outil d’analyse FERIA puisse fonctionner aussi dans un mode d’application locale permettant un débogage classique. Dans ce cas, l’outil d’analyse bénéficie des facilités d’accès aux contenus et aux descriptions qui lui sont fournis en entrée (il reste client des serveurs de contenus et de description), mais l’ensemble de son contrôle et de ses résultats se fait localement.

Il nous semble que le mécanisme d’analyse automatique proposé par le framework FERIA est de nature à faciliter les recherches sur la coopération entre outils d’analyse, en particulier les recherches sur l’analyse plurimodale. Il en est de même pour les recherches sur l’analyse semi-automatique où l’on cherche à faire coopérer des opérateurs humains fournissant des connaissances sur les contenus à des outils d’analyse mobilisant ces connaissances dans leurs calculs. Tous ces travaux se heurtent en particulier à des problèmes d’échange de données pour lesquels FDL fournit un principe d’unification. La combinaison des mécanismes d’API avec la déclarativité des schémas d’analyse évite à chaque outil coopérant à un ensemble d’incorporer des connaissances sur les autres outils, ce qui est un facteur de complexification freinant véritablement ce type de travaux.

L’architecture d’analyse automatique est mise à profit dans le cadre même du projet pour intégrer un ensemble très complet d’outils d’analyse automatique désormais « classiques », notamment analyse de mouvement, caractérisation des mouvements de caméra, segmentation en plan, identification d’images représentatives de plans, détection, suivi et reconnaissance de visage, détection et reconnaissance de texte, détection de logos, détection et reconnaissance des locuteurs, segmentation parole/musique/bruits, détection de sons clés, transcription de la parole et indexation textuelle.

En plus de ces outils d’analyse génériques et monomodaux, le framework comportera des outils d’analyse spécifiquement adaptés aux applications décrites dans la section 5 ainsi que des outils d’analyse plurimodaux qui feront l’objet de publications ultérieures.


4.4. Interfaces graphiques d’édition de descriptions

Le framework propose des mécanismes facilitant le développement d’interfaces graphiques d’édition de descriptions. Il s’agit d’une part de classes abstraites de type vue, par exemple pour l’édition de descripteurs temporels où l’axe du temps est classiquement représenté par l’axe horizontal de l’écran et qui prennent en charge le zoom et le défilement. Dans un paradigme classique Modèle-Vue-Contrôleur (MVC), il s’agirait de la partie vue et contrôleur des interfaces graphiques, le modèle étant un ensemble de descriptions FDL. D’une certaine manière, tout composant graphique peut être vu comme permettant de visualiser ou d’éditer des descriptions.

De manière habituelle dans un paradigme MVC, le framework propose un mécanisme de synchronisation des vues en termes d’édition de données, ce qui fait que, par exemple, la modification de la valeur d’une propriété dans une vue est répercutée dans les autres vues. Les vues peuvent de plus être synchronisées ou asservies temporellement, ce qui permet par exemple le défilement automatique d’un curseur dans une vue temporelle (de type timeline) en fonction du temps courant fourni par un player. Ces mécanismes de synchronisation sont implémentés par des mécanismes d’abonnement et de délégation, courants en programmation par objets.

Une des difficultés liées à l’approche framework est qu’il est difficile de faire le bon compromis entre généricité et spécificité, l’idéal étant souvent une grande généricité des composants logiciels et une grande spécificité des applications développées. L’approche retenue ici est que, autant que possible, les composants graphiques doivent être paramétrés dynamiquement par les schémas de description. Ainsi, un même composant graphique n’aura pas le même comportement selon le cadre applicatif. L’interface graphique pourra par exemple s’adapter aux types de données à saisir par l’utilisateur (nombres, dates, etc), ou pourra, pour un composant de segmentation temporelle manuelle, interdire la création de segments se chevauchant si le schéma de description l’interdit.

4.5. Développement des applications

Pour développer une application FERIA, le développeur d’application peut être amené à effectuer les tâches suivantes :

– Utilisation de modules existants dans le framework : le framework met à disposition des modules destinés à être utilisés tels quels ;

– Spécialisation/extension de modules existants : certains modules du framework peuvent être spécialisés en des modules plus spécifiques par utilisation des mécanismes de dérivation de classes ;

FERIA 23

– Intégration de composants d’interface utilisateur : les composants d’interfaces utilisateurs fournis par le framework sont destinés à être utilisés dans les interfaces des applications ; en ce qui concerne les composants d’édition de descriptions, ceux-ci sont configurés par le schéma des descriptions qu’ils doivent éditer ;

– Développement de composants d’interface réutilisables : si de nouveaux besoins d’interfaces utilisateurs apparaissent, le développeur d’application peut les développer comme des composants réutilisables qui enrichissent le framework ;

– Développements spécifiques : enfin, des développements complètement spécifiques à une application peuvent être nécessaires.

5. Applications

Afin d’éprouver la capacité du framework FERIA à permettre le développement d’applications de la classe définie en section 2.3 à des conditions satisfaisantes, le projet prévoit le développement de deux applications inspirées des exemples de la section 2.2.

Comme indiqué à la section 4.1 et schématisé sur la figure 7 (schéma d’instanciation du framework), une application développée à l’aide du framework est une application de production de contenus. C’est une application de back office utilisée par un producteur de contenus. Les contenus produits sont mobilisés par un système technique indépendant du framework FERIA que nous désignons par le terme d’application front office puisqu’elle s’adresse à l’usager.

5.1. Application FIDELIO/ALTO

L’application back office FIDELIO – Fabrique Informatique Dédiée à l’Élaboration de Lectures Interactives d’Œuvres scéniques – a pour objectif de produire des contenus d’enrichissement d’une captation d’opéra. Elle fournira les données nécessaires à une application front office nommée ALTO – Application de Lecture Thématique d’Œuvre scénique – qui vise initialement une plateforme de télévision interactive avec enregistreur, dite de deuxième génération, mais sera également déclinée sur DVD vidéo, sur télévision interactive de première génération et sur télévision analogique classique en fonction des capacités propres à ces plateformes.

5.1.1. ALTO

Dans sa version complète, l’application ALTO proposera à l’usager des fonctionnalités interactives complémentaire à la diffusion d’un opéra, notamment :

– accès à un résumé contextuel en fonction de l’avancement dans la visualisation,


– navigation par le livret et sous-titrage, – accès direct et navigation par les grands airs, – navigation par les interprètes, – accès à des informations supplémentaire, – possibilité de regarder un opéra avec ou sans les récitatifs, – accès direct aux grandes scènes, – accès direct aux changements de décors, – informations sur les différents costumes, – informations sur les équipes de production. Cette version complète sera disponible sur une plateforme de télévision

interactive de deuxième génération, sur laquelle l’opéra pourra être enregistré au fur et à mesure de sa diffusion, l’application ALTO et les données produites par l’application back office FIDELIO ayant été préalablement téléchargées. Une fois la diffusion terminée, il sera possible de visionner le programme en ayant l’ensemble des fonctionnalités de navigation disponibles par simple appel d’un menu apparaissant en surimpression.

ALTO sera une application générique capable de proposer ce type de services à l’usager à partir de données spécifiquement produites par un module de publication de l’application FIDELIO.

5.1.2. Déclinaisons de l’application ALTO

Dans ses versions diffusées sur des supports moins performants, les fonctionnalités sont supprimées ou modifiées, par exemple :

– sur DVD vidéo, les fonctionnalités sont comparables, mais le mode de navigation sera plus conforme à ce que propose habituellement ce type de support via un menu principal proposant une alternative entre la diffusion de l’œuvre et l’exploration des compléments,

– sur télévision interactive de première génération, c’est-à-dire sans capacité d’enregistrement, les possibilités de navigation ne seront pas disponibles,

– sur télévision analogique, il sera par exemple possible de proposer simplement le programme en incrustant dans l’image les sous-titres issus du livret.

5.1.3. FIDELIO

L’application FIDELIO permettra d’abord de produire l’ensemble des descriptions nécessaires à ALTO et ses différentes déclinaisons et ensuite de publier les données nécessaires à chacune des plateformes dans le format qui leur est propre.

En ce qui concerne les outils nécessaires pour la production des données, on identifie les besoins suivants :

FERIA 25

– outil de synchronisation texte/vidéo, – outil de segmentation semi-automatique audio, – outil de segmentation semi-automatique vidéo, – outil de renseignement de données générales sur l'opéra, – outil d'enrichissement et de visualisation des thèmes / sous-thèmes / séquences, – éditeur d’apparence de l’interface utilisateur de l’application ALTO, – outil de prévisualisation de l’application cible. À part les deux derniers, l’ensemble de ces besoins peut être rempli par

réutilisation et spécialisation d’outils livrés avec le framework FERIA. Sur ces aspects, le travail du développeur d’applications consistera donc à :

– choisir les outils d’analyse nécessaires et écrire le graphe d’analyse les mobilisant, en effectuant par exemple ici une segmentation en plans et une segmentation de la bande son,

– spécialiser les éditeurs disponibles dans le framework en écrivant les schémas des descriptions qu’ils doivent être capables de produire ; parmi ces éditeurs, certains sont destinés à corriger les résultats des outils d’analyse automatique, d’autres à générer des descriptions de façon entièrement manuelle,

– écrire entièrement les outils utilisateurs pour les deux derniers besoins, qui sont complètement spécifiques à l’application, en s’appuyant sur les API destinées à l’édition et à la visualisation de descriptions.

Une fois ces données produites, il faut les publier vers les plateformes cibles. Dans sa première version FERIA fournira peu de support pour générer des données spécifiques à des plateformes ou à des catégories de plateformes. Le travail du développeur d’application consistera donc à écrire un module de publication spécifique à chacune des cibles (et à cette application) en s’appuyant sur les API destinées au moteur de publication, qui lui permettent d’accéder aux descriptions et aux médias. En ce qui concerne les médias, l’API du serveur de contenu lui permet d’effectuer les opérations d’édition et de conversion qui peuvent être nécessaires pour certaines cibles.

Par exemple, pour la télévision interactive, le module de publication devra d’une part convertir l’opéra au format MPEG-2, et d’autre part générer un fichier de données en XML interprétable par l’application front office. Pour l’application DVD, la machine interprétant les données (le lecteur de DVD) est beaucoup plus fruste et le module de publication devra alors générer en MPEG-2 l’ensemble des contenus susceptibles d’être joués individuellement ainsi qu’un script pour un environnement auteur (par exemple Sonic Scenarist) qui l’inclura dans un design graphique prédéfini et génèrera le DVD.


5.2. Application PACE

L’application Pace (Publication Automatique d’une Collection d’Émissions) est une application de back office permettant d’alimenter en données une application de front office destinée à un utilisateur final. L’application front office est une application web qui permet au grand public de naviguer dans une collection homogène d’émissions d’une archive de télévision, probablement une cinquantaine d’émissions du Grand Échiquier.

IHM de catalogage

Descriptions générées

automatiquement(n par doc)

Catalogage(une par doc)

Description de la collection (une par

collection)Doc 1

Doc n

Collection

IHM de descriptionde la collection

Moteur d’analyse

Schémad’analyse

IHMtableau de bord

Outil 1

Outil n

Moteur depublication

Profilde publication

Site web

IHM de correction(éventuellement)

Outils spécifiques à l’application Données fixes de l’applicationOutils génériques spécialisés ou nonDonnées traitées par l’application

Serveur web

IHM de paramétrage(éventuellement)

Back office Front office

Serveur de médias

Navigateur web

Figure 9. Schéma général de l’application PACE

L’objectif de l’application est de mobiliser au maximum les outils d’analyse automatique du framework pour publier un site web proposant une consultation de la collection d’émissions par navigation. Contrairement à une consultation par recherche, l’objectif de la consultation n’est pas de répondre à une requête formulée a priori, mais plutôt de permettre à l’utilisateur d’explorer le contenu du corpus. Pour cela, le site web proposera des fonctionnalités novatrices de navigation dans la collection s’appuyant principalement sur les résultats d’analyse automatique.

L’application, schématisée à la figure 9, sera construite par spécialisation d’éléments du framework, par la mise au point d’un schéma d’analyse et de schémas de description. Dans la version en cours de développement, la publication se fera à l’aide d’un module de publication entièrement spécifique à l’application.

Par ailleurs, il sera nécessaire de développer en dehors de FERIA l’application front office, c’est-à-dire la partie applicative du site web.

FERIA 27

5.3. Perspectives d’applications

Le framework servira de base pour l’ensemble des recherches applicatives et technologiques menées à l’INA dans les domaines de la description et de l’exploitation des contenus audiovisuels. En conséquence, de nombreuses autres applications autres que celles prévues dans le strict cadre du projet sont à l’étude, dont nous citons quelques unes des plus ambitieuses :

– structuration des flux télévisuels par analyse multimodale pour le dépôt légal de la télévision : l’objectif est de développer une application permettant d’extraire automatiquement la structure d’un flux télévisuel continu à partir des grilles prévisionnelles fournies par les diffuseurs,

– assistance à la documentation de fonds radiophoniques par transcription automatique de la parole : l’objectif est de fournir une interface utilisateur de navigation dans les documents sonores s’appuyant sur une combinaison de segmentation audio, de transcription de la parole et de traitement de la langue sur la transcription, afin de permettre aux documentalistes radio d’accéder plus rapidement aux informations pertinentes pour la documentation de fonds anciens de radio,

– indexation automatique de contenus télévisuels par extraction de texte : l’objectif est de fournir un outil d’indexation automatique de certaines émissions de télévision mobilisant à la fois de la transcription automatique de la parole et de la détection/reconnaissance de texte dans l’image.

6. Conclusion

Nous avons présenté dans cet article un modèle d’ingénierie des documents audiovisuels et multimédias centré sur la description de contenus, ainsi que le framework FERIA, une plateforme logicielle générique qui en est une instrumentation. Nous avons montré en quoi la norme MPEG-7 ne permettait pas de répondre aux besoins de ce modèle et nous avons décrit le langage FDL (Feria Description Language) que nous avons mis en œuvre et qui répond aux besoins exprimés. Ce langage permet la représentation des descriptions sous la forme d’instances de schémas de description dans un langage à objets et possède une syntaxe XML qui permet l’échange et le stockage des descriptions. FDL est au cœur du framework FERIA, lequel propose un outillage complet de manipulation des descriptions, d’accès aux contenus ainsi qu’une architecture ouverte d’analyse automatique.

Nous avons présenté deux applications en cours de développement, la première permettant la navigation en ligne dans une grande collection d’émissions télévisées, la seconde permettant la production multisupport pour des médias interactifs d’une œuvre scénique filmée. D’autres applications sont à l’étude.

Outre ces perspectives applicatives, la plateforme FERIA servira de base technologique à de futures recherches. Les axes privilégiés sont l’analyse


automatique, les langages de description et la publication automatique. En ce qui concerne l’analyse automatique, le framework FERIA est conçu autour de FDL de façon à permettre la collaboration entre outils d’analyse d’une part, et entre utilisateurs et outils d’analyse d’autre part. Nous pensons donc qu’il constitue une excellente plateforme pour toutes les activités de recherche sur l’analyse multicritère, sur l’analyse multimodale et sur l’analyse semi-automatique. Sur ce dernier point, nous voyons des pistes particulièrement intéressantes sur la collaboration entre des connaissances et des outils d’analyse automatique. En ce qui concerne les langages de description, les efforts se porteront principalement sur les aspects structurels. Il s’agira en particulier d’établir des formalismes à la fois bien fondés et calculables permettant d’exprimer la composition spatiale et temporelle. Enfin, FERIA n’offre dans sa version actuelle peu de support pour la publication automatique. L’objectif est de porter les efforts de recherche sur cette partie en cherchant à identifier les processus génériques de l’activité de publication de façon à les incorporer au framework. Dans une version future, le framework FERIA proposera des modules génériques permettant de publier des contenus adaptés à des cibles (ou à des familles de cibles) spécifiques, ces modules seront adaptables à chaque application de façon déclarative. L’idéal serait d’aboutir à un modèle dans lequel les traitements réalisés par les utilisateurs et les outils d’analyse définissent les contenus et les structures à publier. Les cibles sur lesquelles ils sont publiés seront alors celles pour lesquelles on définira de façon déclarative un modèle de publication qui utilise un design graphique élaboré à l’aide des outils dédiés à chaque plateforme cible.

Le projet FERIA a reçu le soutien financier du réseau de Recherche et d’Innovation en Audiovisuel et Multimédia (RIAM). Le consortium FERIA regroupe la société CS, l’INA, les équipes TexMex et VISTA de l’IRISA, les équipes SAMOVA et SIG de l’IRIT, la société Vecsys, la société NDS Technologies et Arte France auxquels appartiennent certains des travaux cités dans cet article.

7. Bibliographie

Brown, Jr., Allen L., « Derivation, tolerance and validity: a formal model of type definition in XML Schemas », Proceedings of XML Europe 2000, ed. Pamela Gennusa, Paris, 2000.

Brunelli R., Mich O., and Modena M., « A Survey on the Automatic Indexing of Video Data », Journal of Visual Communication and Image Representation, vol. 10, 1999, p. 78-112,.

Carrive, J., Pachet, F., Ronfard, R., « Clavis: a temporal reasoning system for classification of audiovisual sequences », Proceedings of the Content-Based Multimedia Access (RIAO'2000), Paris, France, April 12-14, 2000, p. 1400-1415,.

FERIA 29

Fayad, E. M., Schmidt, D. C., « Object-Oriented Application Frameworks », Communications of the ACM, Special Issue on Object-Oriented Application Frameworks, vol. 40, n° 10, 1997.

Foote J., «An overview of audio information retrieval », Multimedia systems, vol.7, 1999, p. 2-10.

Gordon, A., Syme, D., « Typing a multi-language intermediate code », ACM SIGPLAN Notices, vol. 36, N° 3, 2001, p. 248-260.

MPEG-7. Information Technology – Multimedia Content Description Interface. Standard No. ISO/IEC n°15938, December 2001.

Napoli, A., « Une introduction aux logiques de descriptions », in Langages et Modèles à Objets, Etat des recherches et perspectives, Ducournau, R., Euzenat, J., Masini, G., Napoli, A. (éd.), Le Chesnay, INRIA, 1998, p. 321-350,.

Pereira F., MPEG-7 Requirements Document V.15, F. ISO/IEC JTC1/SC29/WG11N4510. Sydney, July 2001.

Troncy R. and Carrive J., A Reduced Yet Extensible Audio-Visual Description Language: How to Escape From the MPEG-7 Bottleneck (to appear). In ACM Symposium on Document Engineering, Milwaukee, Wisconsin, USA, October, 28-30 2004.

Snoek, C.GM., Worring, M., « A Review on Multimodal Video Indexing », In Proceedings of the IEEE International Conference on Multimedia & Expo (ICME), Lausanne, Switzerland, 2002.

XML Schema. W3C Recommendation, 2 May 2001. http://www.w3.org/XML/Schema.

Ingénierie des documents audiovisuels : le projet FERIA. Une approche centrée sur la description des contenus

Documents