Vidéo Sonic Visualiser

MASTER 2 PRO MITIC
Université RENNES 1
2006-2007
Vidéo Sonic Visualiser
Arthur DIBON, Damien LE BERRIGAUD,
Laurent POIRIER, Mickaël SIMON
Table des matières
1 Introduction
4
1.1
Présentation du projet PELOPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2 IHM
7
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Les points faibles de Sonic Visualiser . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.1
Un outil trop complexe : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.2
Gestion des onglets : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.3
Gestion des panneaux : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Les points forts de Sonic Visualiser . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.1
La vue globale du signal audio . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.2
Les icônes représentant les types de descripteurs . . . . . . . . . . . . . . . . .
10
2.3.3
La gestion du zoom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.4
La barre de chargement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.5
La notion de session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
Inspiration de divers logiciels de montage audio/vidéo . . . . . . . . . . . . . . . . . .
11
2.4.1
Intégration d’un chrono
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4.2
Implémentation du drag and drop . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4.3
Déportation des boutons de gestion de la lecture . . . . . . . . . . . . . . . . .
13
2.4.4
Une interface entièrement redimensionnable . . . . . . . . . . . . . . . . . . .
13
Les fonctionnalités non implémentées : . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3
2.4
2.5
3 Intégration de la Vidéo
15
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2
Videolan vs Mplayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2.1
16
Versions testées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
3.2.2
3.3
3.4
Etapes de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
Utilisation de Mplayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3.1
Utilisation d’un QProcess . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3.2
Lancement du Processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3.3
Gestion des communications . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3.4
Fin de processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
Lecture de sélections multiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.4.1
Mécanisme de recherche de Mplayer . . . . . . . . . . . . . . . . . . . . . . . .
18
3.4.2
Synchronisation de la vidéo sur la bande son . . . . . . . . . . . . . . . . . . .
19
4 Query Descriptor
22
4.1
L’objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2
Aspects techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.3
L’outil - Query Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.4
Les formats d’exportation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.5
Le langage de requête . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.5.1
incrEnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.5.2
incrStart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.5.3
getStart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.5.4
getEnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.5.5
before . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.5.6
after . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.5.7
isIn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.5.8
cover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.5.9
meet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.5.10 union . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.5.11 inter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
Fonctionnalités non-implémentées . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.6
5 Import des fichiers descripteurs
5.1
29
Format de fichier de Sonic Visualiser . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.1.1
Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.1.2
Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.1.3
Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.1.4
Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
2
5.2
Format de fichier projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.2.1
Descripteur symbolique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.2.2
Descripteur numérique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.3
Intégration des descripteurs dans Sonic Visualiser . . . . . . . . . . . . . . . . . . . .
33
5.4
Taux d’échantillonnage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
6 Conclusion
38
7 Informations générales
39
7.1
Serveur Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
7.2
Responsables IRISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
7.3
Equipe MITIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3
1
Introduction
1.1
Présentation du projet PELOPS
PELOPS, ITEA-IP-04010
Cadre des travaux :
Le projet PELOPS se positionne dans le domaine de la production de contenu dans les
situations de capture et de distribution d’informations évènementielles ; le projet se rapporte donc
aux études de studios de production en réseau et aux outils associés d’analyse de contenu pour la
production et la publication temps réel avec exploitation ultérieure des contenus existants. Le projet
vise plus spécifiquement à développer le marché d’exploitation des contenus audiovisuels sportifs.
Dans ce contexte, il est nécessaire de générer, collecter et exploiter des métadonnées à chaque
étape du processus. Ce processus doit par conséquent être mis en oeuvre de façon aussi efficace que
possible et en évitant autant que faire se peut aux opérateurs des manipulations laborieuses et sources
d’erreurs. C’est ce qui plaide en faveur d’une extraction automatique de ces métadonnées et d’une
organisation structurée pour une réutilisation aisée et minimisant les erreurs de montage. PELOPS
propose une investigation des axes d’études suivants :
– Extraction et utilisation de différents types de métadonnées (métadonnées issues du
contexte et métadonnées issues de l’analyse du contenu) avec une orientation de standardisation pour faciliter et accélérer la production et la publication en temps réel pendant
le déroulement de l’évènement couvert mais aussi en temps décalé pour la production
ultérieure de résumés, documentaires, etc.
– Faciliter les échanges de contenus dans un environnement de production mobile, et entre
tous les acteurs de la production grâce à une approche pragmatique dans le sens de la
standardisation.
– Prise en compte de l’arrivée et du déploiement de technologies informatiques dans les
4
environnements de production de contenu audiovisuel (en particulier, les interconnexions
et réseaux basés sur les protocoles IP - Internet Protocol)
.
– Démontrer en parallèle avec un canal de diffusion TV traditionnel, les moyens
supplémentaires offerts grâce aux infrastructures s’appuyant sur les protocoles IP pour la
publication et la distribution des médias.
Fig. 1.1 – Pelops Market
1.2
Cahier des charges
Dans le cadre du projet PELOPS, il a été demandé la mise en place d’outils permettant à
l’équipe d’exploiter et de vérifier à l’aide de la vidéo, la pertinence des descripteurs audios générés,
ainsi que la création de nouveaux descripteurs à partir de l’existant.
Définition d’un descripteur :
Un descripteur est une manière formel de décrire un signal donné, il y a deux types de
descripteurs :
– Les descripteurs symboliques, qui permettent, dans une durée, de signifier un évènement.
– Les descripteurs numériques, qui permettent de quantifier une information durant un
évènement.
5
Aprés décision de prendre Sonic Visualiser comme basse des travaux, nous avons dresser une
liste des fonctionnalités à améliorer et à ajouter dans l’application existante.
–
–
–
–
–
–
–
–
–
Importation de descripteurs symboliques et numériques.
Visualisation et manipulation des descripteurs.
Sauvegarde des descripteurs dans une session de travail.
Modification de l’IHM pour faciliter l’utilisation du produit.
Intégration d’un outil de requêtage pour exploiter les descripteurs.
Extraire et générer un résultat à partir d’une requête exprimée.
Ré-importation d’un résultat dans une session.
Intégration de la vidéo dans l’IHM.
Conversion automatique d’un descripteur pour l’adapté au taux d’échantillonnage du flux
sonore étudié.
6
2
IHM
2.1
Introduction
L’interface est la partie avec laquelle l’utilisateur va interagir pour réaliser les opérations
offertes par le logiciel. Les maquettes que nous avons réalisées d’après le cahier des charges font
apparaı̂tre qu’il y aura beaucoup d’informations à afficher à l’écran. L’organisation de l’interface
aura donc un rôle primordial pour maximiser l’utilisabilité du logiciel.
Nous sommes donc partis d’un logiciel existant permettant de visualiser et d’analyser des
signaux audios : Sonic Visualiser.
Fig. 2.1 – Interface d’origine de Sonic Visualiser
7
2.2
Les points faibles de Sonic Visualiser
Lors de la prise en main de Sonic Visualiser, conjointement avec M. Gonon, M. Ben et M.
Marie-Dessoude, nous avons pu mettre en avant divers points de l’interface à améliorer.
2.2.1
Un outil trop complexe :
– L’outil offre à l’utilisateur tout un tas de fonctionnalités qui ne sont pas utiles pour notre
utilisation. Il est possible de :
– gérer la rapidité de la lecture du fichier sonore,
– d’afficher plusieurs types de spectrogrammes (simple, gamme mélodique, pics de
fréquence),
– gérer plusieurs sons simultanément,
– d’afficher des notes musicales.
De plus, l’utilisation de spectrogramme provoque un bog d’affichage, le panneau s’affiche
en inverse vidéo et il est impossible de revenir en mode normal même après suppression
de la couche spectrogramme.
→ Dans un soucis de rendre l’application la plus simple possible et d’éviter la surcharge
de fonctionnalités, l’accès à ces fonctions par les menus a été supprimé.
2.2.2
Gestion des onglets :
Fig. 2.2 – Gestion des onglets de Sonic Visualiser
– Chaque onglet correspond à une couche sur un panneau donné. On peut en ajouter autant
qu’on le désire mais la manière dont ils sont gérés rend leur utilisation très difficile. En
effet, chaque onglet est nommé par un numéro attribué incrémentalement. Il est donc
difficile de savoir à quoi il se rapporte. Pour connaı̂tre le nom réel du descripteur auquel
l’onglet correspond, il faut le survoler et attendre l’affichage d’une info-bulle.
→ Afin de simplifier la navigation dans les onglets, le nom de chaque descripteur apparaı̂t
dorénavant directement sur l’onglet. Nous avons intégré un bouton qui permet de mas8
quer/démasquer l’intégralité des onglets de chaque panneau simultanément. Le but étant
de permettre le redimensionnement des panneaux à volonté afin d’en voir le plus grand
nombre possible à l’écran.
2.2.3
Gestion des panneaux :
Les panneaux permettent d’afficher autant de couches que souhaité. Une couche peut-être
un signal audio ou un descripteur (numérique ou symbolique) représentant des informations issues
de l’analyse du fichier sonore.
– Tout d’abord, la manière d’indiquer le panneau courant n’est pas satisfaisante. En effet,
une barre noire, peu visible, est positionnée sur la gauche de celui-ci. Ensuite, il est possible
d’ajouter autant de panneaux qu’on le souhaite, or au-delà de 4, l’application devient trop
petite pour tous les contenir et certains panneaux demeurent invisibles puisqu’il n’y a pas
de barre de défilement d’implémenter.
→ L’indicateur de panneau courant a été supprimé et le panneau courant est maintenant
mis en évidence grâce à un cadre. Nous avons mis en place une barre de défilement qui
permet de visualiser un nombre quelconque de panneaux.
Fig. 2.3 – Mauvaise gestion des panneaux
9
2.3
Les points forts de Sonic Visualiser
Si nous avons décidé de prendre Sonic Visualiser comme base, c’est bien parce qu’il proposait
des fonctionnalités intéressantes pour notre projet. Voici les points forts que nous avons décidé de
conserver pour Video Sonic Visualiser.
2.3.1
La vue globale du signal audio
– La vue globale du signal audio permet de se situer aisément dans le temps. Elle indique la
position du curseur et grâce à une lucarne, la partie du signal affichée dans les panneaux
(notion de zoom). Le signal miniaturisé qu’elle contient permet en un coup d’oeil de répérer
les zones plus ou moins ’actives’.
2.3.2
Les icônes représentant les types de descripteurs
– Chaque onglet contient une icône représentative du type du descripteur associé. Ainsi
d’un coup d’oeil, l’utilisateur peut prendre connaissance de ce qu’il manipule (descripteur
numérique ou symbolique).
2.3.3
La gestion du zoom
– La gestion du zoom et la navigation dans les panneaux grâce à la souris ou aux flèches
directionnelles est intuitive et très fluide.
2.3.4
La barre de chargement
– Lors du chargement d’un son dans Sonic Visualiser, une fenêtre contenant une barre de
progression s’ouvre et indique à l’utilisateur que le son est en cours de décodage. Cette
fenêtre est non bloquante, l’utilisateur peut ainsi charger sa vidéo en parallèle.
2.3.5
La notion de session
– Sonic Visualiser intègre la notion de session. Ainsi, l’état de l’application peut être sauvegardé et restauré à l’identique très simplement. Celà offre à l’utilisateur un confort
indéniable.
10
2.4
Inspiration de divers logiciels de montage audio/vidéo
Tout d’abord, Sonic Visualiser est un outil exclusivement destiné à l’analyse sonore. Notre
but étant d’intégrer la vidéo à l’application, nous nous sommes intéressés à différents logiciels de
montage vidéo, notamment SONY Vegas et ADOBE Première.
ADOBE Première a été pour nous un exemple de ce qu’il ne fallait pas faire. L’interface est
surchargée par des barres d’outils et l’utilisateur doit consacrer beaucoup de temps à la gestion des
fenêtres.
Nous avons testé divers logiciels de montage audio comme Audacity, qui propose à l’utilisateur une interface complexe et peu intuitive et Sound Forge qui quant à lui, dispose d’une interface
simple, épurée qui nous a paru intéressante.
De tous ces logiciels, celui offrant l’interface la plus aboutie est SONY Vegas. Voici les
concepts intéressants que nous avons adaptés à Sonic Visualiser.
Fig. 2.4 – Sony Vegas
11
Fig. 2.5 – Adobe Premiere
2.4.1
Intégration d’un chrono
– Les fichiers audios/vidéos analysés pourront être des fichiers de plusieurs minutes voir
plusieurs heures (évènements sportifs). Il nous a donc paru évident qu’il fallait proposer à
l’utilisateur un chrono digne de ce nom, lui permettant de se repérer rapidement dans le
temps. Les indications temporelles fournies par Sonic Visualiser à l’origine sont pauvres
et se mélangent avec le contenu des couches et deviennent illisibles.
→ Nous avons mis en place un chrono (au format h :mm :ss) qui indique à l’utilisateur la
position courante de la tête de lecture. Le chrono est volontairement gros et placé entre le
flux audio et la vidéo pour que l’utilisateur ne perde pas de temps à le chercher à chaque
fois.
2.4.2
Implémentation du drag and drop
– La mise en place de la session de travail (chargement du son et de la vidéo) par le menu
’Fichier’ n’est pas très pratique. A chaque fois l’utilisateur doit re-naviguer depuis la racine
vers les répertoires contenant ses documents.
Nous avons donc souhaité intégrer à l’interface un explorateur de fichiers pour que l’utilisateur puisse naviguer simplement au sein de son arborescence de fichiers. La mise en
place du drag and drop facilite le chargement de la vidéo et du fichier audio à analyser. Le
répertoire de travail de l’utilisateur est toujours ’disponible’ directement. Le lecteur vidéo
12
Fig. 2.6 – Intégration du chrono
et le panneau chargé de recevoir le fichier audio sont paramétrés individuellement pour
n’accepter que les types de fichiers supportés par l’un au l’autre. On évite ainsi toutes
erreurs possibles lors de la lecture.
2.4.3
Déportation des boutons de gestion de la lecture
– Les boutons gérant la lecture ont été déportés afin de les séparer clairement des barres
d’outils. Ils ont été placé près du flux pour réduire les déplacements de la souris et pour
que ça soit intuitif pour l’utilisateur.
Fig. 2.7 – Boutons de lecture repositionnés
2.4.4
Une interface entièrement redimensionnable
– La prise en charge de la vidéo a été implémentée et le lecteur a été placé à droite du
navigateur de fichiers. L’utilisation de la vidéo étant facultative lors de l’analyse d’un
fichier sonore, le lecteur de la vidéo peut-être complètement masqué (tout comme chaque
13
composant de l’interface). A l’inverse, la vidéo peut-être agrandie à volonté afin de faciliter
le contrôle de la ’vérité terrain’.
2.5
Les fonctionnalités non implémentées :
– Drag and drop de descripteurs entre panneaux.
– Drag and drop de descripteurs depuis l’explorateur de descripteurs vers les panneaux.
14
3
Intégration de la Vidéo
3.1
Introduction
Une des étapes primordiales du développement de notre application consiste à intégrer un
lecteur vidéo dans l’application Sonic Visualiser. Nous avons donc intégré un visionneur de vidéo
basé sur Mplayer directement dans l’application. Je vais donc vous détailler dans cette partie quelles
sont les raisons de ce choix et comment nous avons pu nous adapter à l’application déjà existante.
Pour obtenir l’ensemble des fonctionnalités nécessaires à notre application, nous devons
permettre de lire une vidéo et d’en analyser la bande son. Etant donné que nous avons choisi d’utiliser
Sonic Visualiser, il nous faut prendre en compte ses fonctionnalités pour rendre ce travail moins
fastidieux et surtout faisable dans le temps qui nous était imparti à la réalisation de l’application.
Nous nous sommes donc mis d’accord pour utiliser la fonction déjà existante de playback des
fichiers sons en utilisant deux fichiers : le fichier son sera lu par les fonctionnalités déjà implémentées
de Sonic Visualiser, et nous allons nous charger de lire un fichier vidéo sans sa bande son et de le
synchroniser avec le fichier audio. S’il nous avait fallu une synchronisatoin absolument parfaite entre
l’image et le son nous n’aurions pas adopté cette solution et nous aurions eu beaucoup plus de travail,
mais ça n’est tout de même pas des plus simples.
3.2
Videolan vs Mplayer
La première démarche suivie a été de rechercher quels sont les lecteurs vidéos Open Source
avec lesquels nous pouvons travailler sans avoir de contraintes de codecs. Au départ j’ai retenu deux
possibilités : Videolan qui intègre directement les codecs dont il a besoin, et Mplayer qui utilise
libavcodec et qui peut également utiliser des codecs binaires non libres lorsque l’équivalent libre n’est
pas disponible.
15
3.2.1
Versions testées
Le premier Widget Qt permettant de lire les vidéos s’est donc basé sur libvlc dans sa version
la plus récente (0.90) uniquement disponible sur serveur subversion. Cette nouvelle mouture de libvlc
est beaucoup plus poussée que les versions précédentes et permet beaucoup plus de contrôle. Je
m’attarderai ici essentiellement sur les fonctionalités qui nous intéressent et surtout sur la manière
d’utiliser Videolan dans le but de synchroniser la vidéo qu’il lit avec le bande sonore elle-même lue
par Sonic Visualiser.
La deuxième Widget de lecture de vidéo est basé sur Mplayer. Il s’agit de la version 1.0 rc111(disponible sur debian testing). Le numéro de version importe peu mais il se peut que toutes les
fonctionnalitées utilisées ne fonctionnent pas aussi bien sur les versions antérieures.
Chacun des ces deux lecteurs a connu plusieurs versions pour pouvoir tester les capacités de
sycnhronisation et la facilité de mise en oeuvre avec l’environnement déjà fourni par Sonic Visualiser.
3.2.2
Etapes de tests
Dans une première version du lecteur on se contentait de lancer la lecture de la bande son et
de la vidéo de manières simultanées. Les pauses se faisaient egalément de manière synchronisées pour
toujours faire avancer ensemble la bande son et la vidéo ensemble. On ne pouvait pas alors parler de
synchronisatoin étant donné qu’on ne pouvait que lire le média avec éventuellement des pauses au
milieu.
Très vite il a fallu en faire plus, effectivement il ne nous faut pas seulement nous contenter de
lire une vidéo de bout en bout mais on doit pouvoir naviguer dans celle-ci... sans perdre la synchronisation. Les fonctionnalités de recherche fournies par Videolan et Mplayer sont par conséquent très
importantes, d’autant que, plus ces fonctions seront rapides, plus le lecteur sera agréable à utiliser.
L’API externe de Videolan que nous avons utilisée permet de se positionner sur le flux soit par le
biais d’un pourcentage (ce qui n’est pas très pratique) soit en indiquant un temps en millisecondes.
Ce niveau de précision pourrait être intéressant, mais le déplacement dans la bande son fourni par
Sonic Visualiser n’est effectif qu’à la seconde près. Mplayer quand à lui ne permet que de se déplacer
en indiquant un temps absolu ou relatif en secondes.
Cette étape de test nous a permis de nous fixer sur Mplayer qui est beaucoup plus rapide
dans sa phase de recherche même s’il paraı̂t moins précis au premier abord.
16
3.3
Utilisation de Mplayer
3.3.1
Utilisation d’un QProcess
L’utilisation de Mplayer dans un Widget Qt est assez simple et se révèle très pratique même
s’il faut faire attention à la manière de procéder. Contrairement à Videolan qui s’intègre par le biais
d’une bibliothèque externe, Mplayer s’intègre en utilisant un processus externe à notre application.
On impbrique alors celui-ci dans un object QProcess fourni par la bibliothèque Qt que nous utilisons.
Cet objet nous permet de communiquer facilement avec le processus : il nous donne le moyen d’écrire
sur son flux d’entrée pour lui envoyer des ordres ; il nous donne également la possibilité de lire sa
sortie standard et sa sortie d’erreur pour récupérer les infos nécessaires à un bon fonctionnement.
Par conséquent il ne suffit, pour l’utiliser, que d’avoir une version de Mplayer sur la machine, pas
besoin d’installer de bibliothèques supplémentaire avec ses headers pour le développement.
3.3.2
Lancement du Processus
Pour lancer le processus il suffit de connaı̂tre l’emplacement de l’executable et du lui passer
les bons paramètres. Dans notre cas nous utilisons Mplayer en mode esclave et nous voulons qu’il
se rattache à un Widget Qt, pour cela nous devons lui passer en argument l’identifiant du Widget
utilisé pour le rendu.
3.3.3
Gestion des communications
La communication entre les processus a été rendu très simple grâce à Qt. En effet pour
pouvoir lire tout ce qui arrive sur la sortie standard d’un processus il suffit de connecter le signal
du processus readyReadStandardOutput à une procédure de traitement. Cette procédure lit toutes
les lignes disponibles et si elle trouve une ligne qui correspond à une information attendue elle traite
l’information. Par exemple si on veut savoir la position actuelle de la vidéo on procèdera comme
suit : A la création du lecteur on aura connecté les événements suivants comme ceci :
connect(mplayerProcess,
this,
SIGNAL(readyReadStandardOutput()),
SLOT(catchOutput()));
On demande à Mplayer où il en est :
mplayerProcess->write("get_time_pos\n");
Mplayer va alors écrire sur sa sortie standard et le mécanisme de connection de Qt va recevoir
un signal et lancer la procédure apropriée. On trouvera alors une ligne dans le flux de sortie de ce
17
type :
ANS_TIME_POSITION=2.4
Il faut bien faire attention à se débarasser des retours à la ligne et retours chariot (”n” et
”r”). La position récupérée est en secondes.
3.3.4
Fin de processus
Un autre facilité par rapport à l’utilisation de libvlc est la facilité de gérer les arrêts du
processus Mplayer. Si on arrive en fin de vidéo ou même lors d’une erreur inattendue il est très facile
de détecter la fin du processus grâce à QProcess qui nous indique lorsque Mplayer se termine et le
code de sortie indiqué par le processus. On peut alors traiter le cas et relancer la vidéo si nécessaire.
3.4
Lecture de sélections multiple
Le lecteur de vidéo doit être capable de lire plusieurs séquences. Etant donné que le but de
notre application est de vérifier la pertinences de descripteurs symboliques et numérique. Je ne vais
pas décrire ici le détail de cette fonctionnalité mais lire plusieurs séquences d’une vidéo mis bout
à bout en fait partie. Pour cela nous utilisons la fonction de lecture de sélection offerte par Sonic
Visualiser. Une sélection pouvant être multiple, cela permet de lire plusieurs séquences de la bande
sonore. Il suffit alors de pouvoir synchroniser la vidéo avec le son en cours de lecture.
3.4.1
Mécanisme de recherche de Mplayer
Lorsque nous avons testé Videolan et Mplayer pour la rechercher à l’intérieur d’une vidéo
nous avions remarqué qu’il y avait assez souvent des décalages entre la vidéo et le son. Ces décalages
paraissaient d’autant plus étranges qu’ils pouvaient être infimes sur certaines vidéos comme ils
peuvent être très grands sur d’autres. Finalement après quelques recherches sur Internet on a fini par
trouver la raison.
Un codec vidéo de type MPEG-x utilise un système de compression temporel. Certaines
frames ne sont pas codées intégralement dans la vidéo, au lieu de stocker l’intégralité de chaque
frame, on préfère calculer certaines images à partir d’images précédentes et/ou suivantes. Un codec
utilise en faite une succession d’images de type (( I P B B B P I )) par exemple. I est une image
stockée intégralement, P est caculée à partir de l’image I précédente et B peut se baser sur la
précédente et la suivante.
18
Mplayer base sa recherche uniquement sur les images I. Cela permet une excellente rapidité
étant donné que l’image I est plus rapidement lue qu’une image P ou B, mais cela peut être au
détriment de la précision. En effet si on intercale beaucoup d’images de type P ou B entre les images
I on aura plus de difficultés à se positionner précisément dans la vidéo. Il faut donc mettre en place un
mécanisme permettant de re-synchroniser la vidéo avec le son lorsque celle-ci ne peut se positionner
à l’endroit exact de la bande son.
3.4.2
Synchronisation de la vidéo sur la bande son
Pour que le mécanisme de synchronisation soit simple et fonctionne sur tous types de lecture
de la bande son (lecture simple avec recherche pendant la lecture ou lecture de sélection multiple) nous
avons choisi de synchroniser la vidéo sur le son. Encore une fois s’il nous avait fallu une synchronisation
parfaite ce système aurait été loin d’être parfait. Dans notre cas il est simple et très efficace.
Fig. 3.1 – Synchronisation de la vidéo.
A intervalle régulier (toutes les 500ms), la lecteur vidéo va demander à Sonic Visualiser la
position de la piste audio, il va la comparer avec sa position actuelle et réagir selon le cas :
– Si l’intervalle entre la position dans le flux sonore et la position dans la vidéo est inférieur
19
à 1 seconde, il ne fait rien.
– S’il y a un décallage et que la vidéo a du retard il va re-lancer une recherche de la vidéo
au temps indiqué par la bande son.
– Si la vidéo a de l’avance elle se met en pause pour se relancer uniquement lorsque le son
aura rattrapé son retard.
De cette manière on se synchronise très bien et de manière automatique lorsqu’on fait une
recherche à une position particulière ou lorsqu’on essaie de lire une sélection multiple. Il se peut
que la synchronisation prenne du temps avec des codecs particuliers, dans ce cas nous indiquons à
l’utilisateur une estimation du temps de synchronisation.
20
Fig. 3.2 – Diagramme de séquence typique de synchronisation.
21
4
Query Descriptor
4.1
L’objectif
L’objectif de cet outil, est de permettre à l’équipe PELOPS de raffiner les descripteurs
symboliques, en vue d’extraire des résumés vidéos des manifestations sportives traitées. A partir des
descripteurs symboliques et numériques générés par leurs outils de reconnaissance de situations. On
met à disposition, un moteur de requêtes, permettant de comparer efficacement les corrélations entres
les descripteurs.
La première version proposée était basée sur l’exploitation du fichier xml Sonic Visualiser,
avec un moteur XQuery. Très vite, nous nous sommes heurtés à l’incapacité de pouvoir décrire
convenablement les requêtes demandées en XQuery.
Après étude, nous nous sommes orientés vers un outil de type interpréteur de commandes,
plus apte à répondre aux requêtes susceptibles d’être demandées. La solution proposée est basée sur
un analyseur lexical / syntaxique du type Lex et Yacc.
Cette méthode nous permet d’être totalement autonomes sur les spécificités des fonctions de
comparaison, ainsi que sur notre capacité d’enrichissement des fonctions de comparaison.
4.2
Aspects techniques
Concernant l’interpréteur du Query Descriptor, nous avons été confrontés à des problèmes
d’intégration avec la version C de Flex et Bison (Lex /Yacc sous linux) avec l’environnement QT 4.2
en C++. Après maintes tentatives de résolution du problème, nous nous sommes décidés à passer à
une version sous java. Plus simple, à mettre en oeuvre et assez performante au demeurant. Pour la
mise au point de l’intégrateur, nous tenons à remercier le professeur ROBIN Sophie, pour son aide
précieuse et efficace.
Cette décision d’utiliser Java plutôt que C pour la réalisation du moteur de
requêtes, n’a pas été sans soucis majeurs. Il nous a fallu aussi trouvé, rapidement, une bi-
22
bliothèque en java, susceptible de communiquer avec les composants Widgets de Qt TrollTech. Et ceux pour un respect de cohérence graphique avec Sonic Visualiser. Cette contrainte
nous a permis entre autre, de découvrir la bibliothèque QtJambi, développée par TrollTech.
http ://www.trolltech.com/developer/downloads/qt/qtjambi-techpreview.
Cette bibliothèque offre un accès natif aux widgets graphiques des bibliothèques QT 4.2.,
avec l’utilisation massive de JNI, (Java Native Interface). Multiplateforme et respectant totalement l’interface des objets Qt, cette bibliothèque offre également tous les mécanismes d’interaction
système/utilisateur développés chez TrollTech. En somme, une alternative réellement bleufante, capable de rivaliser avec SWT de chez IBM.
23
4.3
L’outil - Query Descriptor
Son interface se compose de quatre modules de travail et est principalement axée sur une
zone de texte (Query), qui permet à l’utilisateur de spécifier sa requête sur les descripteurs présents
dans sa session de travail.
Fig. 4.1 – Query Descriptor
Les fonctionnalités du produit :
– le Menu permet, le chargement d’un fichier session Sonic Visualiser. Il offre la possibilité
d’enregistrer les résultats obtenus dans un format reconnu comme un nouveau descripteur
dans la session de Sonic Visualiser. Ainsi que la possibilité d’exporter le résultat pour
l’extraction du futur résumé vidéo
– Query, L’éditeur de requêtes offre une coloration syntaxique, permettant à l’utilisateur
de vérifier l’exactitude de ses commandes, et éviter par la même occasion, d’exécuter des
requêtes erronées.
– Descriptors, composant permettant l’affichage des différents descripteurs symboliques
présents, dans la session, ainsi que ceux que l’utilisateurs aurait créé avec le module Numeric Descriptors. Un descripteur est affiché avec sa liste de segments rattachés.
– Result, permet l’affichage des résultats obtenus après exécution d’une requête, sous la
même forme que les descripteurs utilisés pour formuler la requête.
24
– Numeric Descriptors, ce cadre permet la création de nouveaux descripteurs symboliques
à partir des descripteurs numériques présents dans la session. La création des nouveaux
descripteurs symboliques se fait par seuillage des descripteurs numériques, plus ou moins
un delta temporel.
Fig. 4.2 – Technique de seuillage
4.4
Les formats d’exportation
Le format d’enregistrement du résultat est conforme au format d’importation des descripteurs symboliques mis en place dans Sonic Visualiser (cf. Import des fichiers descripteurs).
4.5
Le langage de requête
Le langage est basé sur onze commandes, et devrait être, à terme, enrichi.
Liste des commandes : incrEnd, incrStart, getStart, getEnd, before, after, isIn, cover, meet,
union, inter.
Toutes les opérations sont faites sur les segments des descripteurs symboliques.
Exemple de requête demandée :
((NOMDESC incrEnd 1) cover (getStart DESC2)) union DESC3 ;
25
Pour les fonctions de traitement des segments, nous nous sommes inspirés de l’article suivant :
Explaining preferred mental models in Allen inferences with a metrical model imagery,
dont est extrait le tableau suivant :
Fig. 4.3 – Liste des fonctions de traitement de segments
4.5.1
incrEnd
Permet d’incrémenter la fin des segments d’un descripteur.
Exemple : NOMDESC incrEnd 1
4.5.2
incrStart
Permet d’incrémenter le début des segments d’un descripteur.
Exemple : NOMDESC incrStart 1
4.5.3
getStart
Permet d’extraire la première seconde des segments d’un descripteur.
Exemple : getStart NOMDESC
26
4.5.4
getEnd
Permet d’extraire la dernière seconde des segments d’un descripteur.
Exemple : getEnd NOMDESC
4.5.5
before
Permet d’extraire les segments de NOMDESC1 se trouvant avant ceux de NOMDESC2.
Exemple : NOMDESC1 before NOMDESC2
4.5.6
after
Permet de récupérer tous les segments de NOMDESC1 qui se trouvent après ceux de NOM-
DESC2.
Exemple : NOMDESC1 after NOMDESC2
4.5.7
isIn
Permet d’extraire les segments de NOMDESC1 contenus dans ceux de NOMDESC2.
Exemple : NOMDESC1 isIn NOMDESC2
4.5.8
cover
Permet d’extraire les segments de NOMDESC1 qui recouvre ceux de NOMDESC2.
Exemple : NOMDESC1 cover NOMDESC2
4.5.9
meet
Permet d’extraire les segments de NOMDESC1 qui sont mitoyens avec ceux de NOMDESC2.
Exemple : NOMDESC1 meet NOMDESC2
4.5.10
union
Permet de récupérer l’union de tous les segments mitoyens.
Exemple : NOMDESC1 union NOMDESC2
27
4.5.11
inter
Permet d’extraire l’intersection de tous les segments.
Exemple : NOMDESC1 inter NOMDESC2
4.6
Fonctionnalités non-implémentées
Il serait intéressant, à terme, d’ajouter d’autres fonctionnalités dans cet outil. Par exemple,
la possibilité d’enregistrer les travaux en cours, avec la session de travail, les requêtes qui ont été
testées, ainsi que leurs différents résultats. Offrir, la possibilité de gérer les résultats sous une forme
plus globale, permettant de préserver la démarche utilisée pour rafiner les requêtes.
Ajouter un nouveau type de descripteur, un descripteur numérique multi-dimensionnel, appelé vectoriel. L’idée, serait d’offrir plusieurs valeurs pour un point donnée de la courbe des relevés.
28
5
Import des fichiers descripteurs
5.1
Format de fichier de Sonic Visualiser
L’application Sonic Visualiser permet de visualiser et d’analyser un flux audio. Le travail
peut être enregistré dans une session sur un disque sous la forme d’un fichier sv. Ce fichier sv est
un fichier XML compressé avec BZip. Ce fichier de sauvegarde contient le détail de la session de
l’utilisateur à savoir le ou les noms des fichiers sons utilisés, les types d’analyseurs utilisés pour le
traitement du signal ainsi que leurs résultats. Les principales balises contenu dans le fichier sont les
balises model, dataset, point et layer.
Exemple de fichier sv :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sonic-Visualiser>
<sv>
<data>
<model id="0" name="hihat.wav" sampleRate="44100" start="0" end="13888"
type="wavefile" file="/home/arthur/workspace/videosonic/samples/hihat.wav"
mainModel="true"/>
<model id="2" name="EmptyModel" sampleRate="44100" start="37888" end="37888"
type="sparse" dimensions="4" resolution="1" notifyOnAdd="true" dataset="1"
valueQuantization="1" minimum="178" maximum="178" units=""/>
<dataset id="1" dimensions="4">
<point frame="37888" value="178" duration="163840" label="New Point" />
</dataset>
<layer id="3" type="waveform" name="Waveform" model="0" gain="1" colour="#000000"
showMeans="1" greyscale="1" channelMode="0" channel="-1" scale="0" aggressive="0"
autoNormalize="0"/>
<layer id="4" type="timeruler" name="Ruler" model="0" colour="#000000"/>
<layer id="5" type="symbolic" name="Symbolic" model="2" colour="#008000"
29
verticalScale="1"/>
</data>
<display>
<window width="1193" height="736"/>
<view centre="0" zoom="1024" followPan="1" followZoom="1" tracking="page" light="1"
type="pane" centreLineVisible="1" height="208" >
<layer id="4" type="timeruler" name="Ruler" model="0" colour="#000000"/>
<layer id="3" type="waveform" name="Waveform" model="0" gain="1" colour="#000000"
showMeans="1" greyscale="1" channelMode="0" channel="-1" scale="0" aggressive="0"
autoNormalize="0"/>
<layer id="5" type="symbolic" name="Symbolic" model="2" colour="#008000"
verticalScale="1"/>
</view>
</display>
<selections >
</selections>
</sv>
5.1.1
Model
La balise model contient les informations sur les sons (wavefile) utilisés ou les informations
sur les des descripteurs appliqués à ces sons. Elle peut aussi contenir les différents autres types de
modèles utilisés dans l’application. Les modèles présents dans l’application sont les modèles Text,
Notes, etc.
<model id="0" name="son.wav" sampleRate="44100" start="0" end="13888"
type="wavefile" file="../samples/hihat.wav" mainModel="true"/>
5.1.2
Dataset
La balise dataset contient les points d’interaction des descripteurs. Les balises de type dataset
sont rattachés à un seul modèle mais un modèle peut définir plusieurs balises dataset.
<dataset id="1" dimensions="4">
30
5.1.3
Point
La balise point contient les informations de chaque point. Les points ont une image de départ,
une durée, une valeur ou une hauteur de positionnement sur le signal, ainsi qu’un label contenant le
nom du point.
<point frame="37888" value="178" duration="163840" label="New Point" />
5.1.4
Layer
La balise layer contient les couches graphiques qui seront affichées ou non dans l’interface
graphique. Chaque couche est reliée à son modèle. Elle permet en autre de définir la couleur d’affichage
du modèle, le texte affiché et son type de lecture.
<layer id="4" type="timeruler" name="Ruler" model="0"
5.2
colour="#000000"/>
Format de fichier projet
Les fichiers clients sont de forme textuelle. Nous les avons formaté au format xml et proposé une extension de nom desc. Pour importer ses fichiers dans Sonic Visualiser, nous avons choisi
d’utiliser les mêmes nom de balise de Sonic Visualiser pour faciliter l’insertion dans le code. Le client
désire deux types de descripteur à rajouter et à pouvoir manipuler. Les descripteurs numérique et
symbolique.
Fig. 5.1 – Objectif
L’objectif est de pouvoir importer des fichiers du client dans l’application existante, de les
sauvegarder au format prédéfini et de pouvoir les lire et ré-afficher tel qu’ils ont été importé.
31
5.2.1
Descripteur symbolique
Le type symbolique représente une action pendant un temps donné. Par exemple, les cris de
la foule lors d’un match de football. Ce type de descripteur n’existait pas dans l’application et nous
avons du le créer. Nous nous sommes inspirés du modèle NotesModel qui s’en rapprochait le plus.
Nous avons créer un nouveau modèle symbolique et une nouvelle couche graphique pour ce modèle.
Voici un exemple de descripteur symbolique.
Fig. 5.2 – Exemple de descripteur symbolique, les cris de foule.
Voici le code XML représentant un descripteur symbolique :
<model name="nomDescripteurSymbolique" type="symbolic" sampleRate="44010" dataset="
<dataset id="2">
<point frame="1550" duration="2000" />
<point frame="7000" duration="500" />
</dataset>
5.2.2
Descripteur numérique
Le type numérique représente un ensemble de points définis qui forment visuellement une
courbe. Le modèle SparseTimeValue de Sonic Visualiser proposait un modèle se rapprochant du type
numérique. Nous l’avons adapté et réutilisé pour l’affichage graphique.
Voici un exemple de descripteur numérique :
Voici le code générique XML représentant un descripteur numérique.
<model name="nomDescripteurnumerique" type="numeric" sampleRate="44100" dataset="numeroDat
32
Fig. 5.3 – Exemple de descripteur numérique
<dataset id="numero">
<point frame="0" value="27.2283" />
<point frame="64" value="27.9402" />
<point frame="128" value="27.7351" />
....
</dataset>
5.3
Intégration des descripteurs dans Sonic Visualiser
Nous avons crée des fichiers gérant le balayage (parsing en anglais) des descripteurs pour
récupérer les valeurs et les insérer dans le code et dans le fichier de sauvegarde de la session en cours.
Ce fichiers sont DescriptorFileReader.h et DescriptorFileReader.cpp.
33
Voici un schéma représentant l’insertion des fichiers dans les classes existantes.
Fig. 5.4 – Intégration du descripteur numérique
La classe DescriptorFileReader balaye le fichier XML, détermine le type de descripteur et
crée un nouveau modèle de type SparseTimeValue puis une nouvelle couche TimeValueLayer qui
est insérée dans le panneau graphique courant (Classe Pane) du document (Classe Document) de
la session. La couche est ensuite insérée visuellement dans l’interface graphique de l’application.
L’implémentation du balayage XML est facilité par la classe fournit par QT, QXmlDefaultHandler.
La fonctionnalité qui permet de modifier et de récupérer le nom du descripteur a due être rajoutée
aussi bien dans la classe DescriptorFileReader que dans SVFileReader qui le lecteur de fichier session
de Sonic Visualiser.
Les classes définissant le modèle symbolique ainsi que la couche graphique n’existant pas
nous les avons rajouté. Nous avons aussi modifié le programme d’origine pour qu’il accepte et intègre
ces fichiers à l’avenir.
34
Fig. 5.5 – Intégration du descripteur symbolique
La classe FactoryLayer a été modifié pour intégrer la nouvelle couche SymbolicLayer. Cette
classe permet la fabrication de toutes les couches graphiques. La classe MainWindow a été modifié
pour insérer un bouton permettant de charger un descripteur symbolique. La classe SVFileReader
a été changé pour pouvoir inclure des fichiers de session contenant le nouveau modèle symbolique
permettant ainsi un chargement du nouveau type par la suite. Nous nous sommes inspirés des classes
NotesModel et NotesLayer pour les nouvelles classes. Il est possible graphiquement de créer un
nouveau descripteur symbolique en le dessinant la zone du signal audio. Il est possible de modifié la
place du descripteur, de le supprimer, de changer son nom et sa couleur. Un fichier descripteur peut
comporter soit un descripteur symbolique, soit numérique ou les deux en même temps.
5.4
Taux d’échantillonnage
Lors de l’importation d’un descripteur textuel, l’application Sonic Visualiser propose à
l’utilisateur de convertir les données au taux d’échantillonnage qu’il souhaite ainsi que le taux
d’incrémentation entre deux images. Cet outil ne propose pas la possibilité de choisir le type
de descripteur que l’on souhaite obtenir avec ces données et ne prend pas en compte le taux
d’échantillonnage de la session en cours.
35
Fig. 5.6 – Outil de conversion de Sonic Visualiser
Nous avons donc facilité cette étape en convertissant automatiquement le taux
d’échantillonnage des descripteurs symbolique et numérique au taux d’échantillonnage de la session en cours. Le taux d’incrémentation entre les images est également calculé et nous modifions la
valeur des images en fonction de ce taux Voici un exemple illustrant cette fonctionnalité. Si nous
importons un descripteur symbolique dont le taux d’échantillonnage est de 22050 dans une session
dont le taux d’échantillonnage est de 44100 tel que celui-ci :
<model name="nomDescripteurSymbolique" type="symbolic" sampleRate="22050" dataset="2"/>
<dataset id="2">
<point frame="750" duration="2000" />
<point frame="3500" duration="500" />
</dataset>
Nous obtenons :
<model name="nomDescripteurSymbolique" type="symbolic" sampleRate="44100" dataset="2"/>
36
<dataset id="2">
<point frame="1500" duration="4000" />
<point frame="7000" duration="1000" />
</dataset>
37
6
Conclusion
Ce projet, nous a permis de prendre contact avec de nouveaux outils de développement tels
que :
– Les widgets Qt de Trolltech, bibliothèque professionnelle efficace en terme de productivité
de code, de facilité de prise en main, de rapidité de développement, ainsi que par la richesse
des fonctionnalités proposées, et d’outils graphiques disponibles.
– JFlex et BYacc/J, outils d’analyse lexical et syntaxique, adaptés au monde Java.
La phase d’études des produits existants, nous a permis de mieux spécifier, et cerner les
besoins de l’équipe PELOPS, en ce qui concerne les fonctionnalités de base du projet. Nous sommes
arrivés conjointement à la conclusion qu’un produit comme Sonic Visualiser offrait déjà une bonne
base de départ. Au terme des modifications et évolutions apportées, cela nous permettrait de fournir
un produit exploitable plus rapidement par l’équipe PELOPS.
Pour conclure, nous pouvons dire qu’une grande partie des objectifs ont été atteints :
– Modification et amélioration de l’ergonomie du produit initial qu’est Sonic Visualiser.
– Ajout de la vidéo, avec synchronisation du son, point important, permettant à l’équipe
PELOPS, d’opérer des vérifications terrain plus efficaces.
– Mise en place d’un moteur de requêtes permettant d’affiner la pertinence des descripteurs
générés. Il a pour but de produire un résultat exploitable, à terme, pour la création du
résumé vidéo de l’évènement sportif étudié.
38
7
Informations générales
7.1
Serveur Subversion
http ://forge.ifsic.univ-rennes1.fr/projects/videosonic
7.2
7.3
Responsables IRISA
[email protected]
Mathieu BEN
[email protected]
Gilles GONON
Equipe MITIC
[email protected]
[email protected]
[email protected]
[email protected]
Arthur DIBON
06 21 88 23 10
Damien LE BERRIGAUD
06 60 21 38 80
Laurent POIRIER
06 86 78 15 59
Mickaël SIMON
06 23 12 19 56
39