Au-delà du navigateur : nouveaux clients et nouveaux protocoles
4. Applications de base proposées par videoSpace
}
// S’il y a une nouvelle image
if (src1->getNextImage(&img1) || src2->getNextImage(&img2)) {
// Superpose les deux dernières images reçues pour // créer une nouvelle image composite
blendImages(&img1, &img2, &img) ; newImage = true ;
}
// S’il y a une nouvelle image coimposite, demande // au visualisateur de l’afficher
if (newImage) newImage = (! dst->handle(&img)) ; }
Les annexes B (miniserver.cxx) et C (videoClient.cxx) donnent deux exemples concrets d'applications conçues autour d'un squelette similaire à celui-ci et capables de filtrer, d'afficher et de transmettre des images sur le réseau48.
4. Applications de base proposées par videoSpace
VideoSpace offre aux utilisateurs un certain nombre d’applications destinées à manipuler des flux vidéo, parmi lesquelles :
• videoServer, que nous avons longuement décrit dans le Chapitre IV ;
• videoClient, que nous avons décrit dans le Chapitre V, qui a quelque peu évolué pour devenir un véritable "couteau suisse" vidéo, capable d’afficher, traiter, enregistrer ou sauvegarder un flux d’images provenant d’une source videoSpace (voir l’Annexe C).
• multiVideoClient, que nous avons également décrit dans le Chapitre V, qui permet d’afficher plusieurs sources d’images simultanément ;
• grab, qui permet de sauvegarder dans un fichier au format JPEG une image provenant d’une source quelconque ;
• mosaic, qui permet de composer les images de plusieurs sources pour former une mosaïque d’images, ce nouveau flux pouvant être affiché, enregistré dans un fichier ou transmis sur le réseau ;
48 Miniserver est un serveur HTTP capable d’envoyer par server-push les images d’une source à ses clients.
• videoResize, qui permet de redimensionner les images d’un flux vidéo puis de les afficher, sauvegarder ou transmettre sur le réseau ;
• sticky, un script Shell UNIX qui permet de "coller" un flux vidéo affiché par un videoClient sur une application en cours d’exécution en utilisant pour cela la technique présentée dans le Chapitre V.
Quelques autres applications illustrent les différents filtres accessibles par l’interface de programmation de videoSpace et ont été utilisées pour obtenir les captures d’écran présentées dans ce chapitre.
5. Discussion
L'API et les applications qui composent aujourd'hui videoSpace sont le résultat de nombreuses itérations d'un processus alternant des phases de conception et des phases d'utilisation. Avec le recul, nous pouvons faire un certain nombre de commentaires sur les facteurs qui ont contribué à l'évolution et au succès de la boîte à outils.
5.1. La diversité des sources au service du développement
incrémental
Les différents types de source d'images de videoSpace offrent une large palette de niveaux de performance en terme de fréquence et de taille des images. De ce point de vue, les sources les plus performantes sont les séquences préenregistrées et le matériel d'acquisition vidéo, capable sur certaines machines de numériser des flux au format PAL en temps réel (25 images 768x576 par seconde). Sans atteindre ce niveau, les sources réseau de videoSpace sont relativement performantes. Ainsi, lors des nombreuses transmissions vidéo que nous avons effectué entre Eindhoven (Pays Bas), Aarhus (Danemark), Bonn (Allemagne), Orsay et Dijon (France), nous avons régulièrement obtenu des performances de l'ordre de 15 à 20 images QCIF (176x144) ou 10 images CIF (320x240) par seconde avec des temps de latence inférieurs à la demi-seconde.
Ces différents niveaux de performance favorisent le prototypage et le développement incrémental des nouvelles applications. Le premier prototype d'une application peut par exemple utiliser des séquences préenregistrées et être développé sur une machine peu puissante ne disposant pas de matériel vidéo, comme un ordinateur portable par exemple. Une fois la faisabilité technique du concept validée par cette première étape, le prototype peut être testé dans des conditions plus réalistes en utilisant un flux vidéo capturé en temps réel. L'application peut ensuite être testée sur le réseau en
utilisant un videoServer distant comme source d'images. Elle peut dans ce cas bénéficier des mécanismes de contrôle et de notification de videoServer pour s'intégrer simplement aux autres applications vidéo utilisées et à la politique de contrôle d'accès choisie par l'utilisateur. Enfin, si les performances des protocoles de transmission de videoSpace s'avèrent insuffisantes, de nouveaux types de sources peuvent être ajoutés, qui seront également profitables aux autres applications.
5.2. L'importance de la hiérarchie de classes
L'un des choix de conception déterminants a été la séparation entre la classe Image, utilisée comme simple descripteur de données, et les sources, filtres, visualisateurs, transmetteurs ou enregistreurs qui manipulent ces données. L'implémentation de ces manipulateurs dans des classes distinctes de la classe Image et non comme des méthodes de celle-ci participe de façon importante à la souplesse d'utilisation et d'extension de la boîte à outils. Chaque application peut ainsi aisément définir ses propres manipulateurs qui seront créés et éventuellement modifiés au cours de l'exécution. S'ils sont par la suite réutilisés dans une autre application, ces manipulateurs peuvent alors être intégrés à la librairie commune. L'existence de classes abstraites pour les sources, les visualisateurs et les enregistreurs/diffuseurs d'images ainsi que leur description par des URLs simplifient grandement l'écriture et l'utilisation des applications. En spécifiant les URLs adéquates, le même exécutable, et donc le même code49, peut par exemple servir à enregistrer les images d'une caméra dans un fichier, diffuser la séquence enregistrée après filtrage ou afficher le flux diffusé :
Enregistre les images de la camera locale videoClient -i videoin:/anydev/anynode \ -o file:demo
Diffuse la séquence après filtrage videoClient -i file:demo \ -f difference \
-o vsmp://localhost:5557 Affiche les images diffusées
videoClient -i vsmp://localhost:5557
5.3. L'évolution par bootstrapping
Pourquoi l'exécutable à tout faire que nous venons de voir s'appelle-t-il encore videoClient ? Les raisons sont historiques et la
différence entre la fonction suggérée par ce nom et les multiples utilisations actuelles du programme illustre bien l'évolution progressive de la boîte à outils.
VideoSpace a été conçue au départ comme une librairie permettant d'accéder aux images d'une caméra capturées par videoServer ou enregistrées par videoRecorder. Une fois cette première étape atteinte, videoServer et videoRecorder ont pu être réécrit pour transmettre et enregistrer des sources distantes en plus de la caméra locale.
L'ajout de nouvelles sources par l'ajout de protocoles comme VSMP ou RFB ainsi que la création des classes abstraites de filtres, visualisateurs et enregistreurs/diffuseurs a fini par atténuer les différences entre les applications destinées à produire des images, à les traiter, les enregistrer ou les afficher. VideoServer et videoClient ont alors pu être réécrits une nouvelle fois, leur code diminuant proportionnellement à l'élévation du niveau d'abstraction auquel ils se plaçaient.
VideoServer est aujourd'hui plus un proxy HTTP qu'un serveur. Nous l'avons vu, videoClient peut remplir tous les rôles. Toute application videoSpace utilisant une ImageSource et un
ImageSink possède automatiquement cette qualité.
6. Résumé du chapitre
Nous avons décrit dans ce chapitre videoSpace, notre boîte à outils logicielle pour l’intégration de la vidéo dans les systèmes informatiques interactifs. Après avoir présenté les motivations qui nous ont conduit à poursuivre les développements logiciels commencés avec videoServer et les différents videoClients, nous avons détaillé l’interface de programmation de notre boîte à outils et donné quelques exemples d’outils de base offerts aux utilisateurs. Nous avons terminé ce chapitre par une discussion sur le développement incrémental de videoSpace et les choix importants qui ont permis son évolution.
Dans le chapitre suivant, nous décrivons trois ensembles de prototypes réalisés avec videoSpace dans des contextes différents qui illustrent les possibilités actuelles offertes par cette boîte à outils et qui préfigurent les nouveaux usages de la vidéo qu’elle devrait permettre à l’avenir.