Walking The Edit

Compte rendu réunion technique du 7 avril

Voici le compte rendu de la réunion qui a rassemblé:
– Laura Raileanu (LR)
– Nicolas Goy (NG)
– Florian Poulin (FP)
– Lionel Tardy (LT)
– Ulrich Fischer (UF)

Nicolas Goy (NG) va faire un schéma des workflows globaux d’ici milieu avril. Cela permet d’avoir une vision d’ensemble plus imagée et concrète des processus et des logiques de “passages de témoin” entre applications, moteurs, serveurs etc…

CMS:
Le CMS développé par Lionel prend de plus en plus d’importance, les fonctions suivantes vont lui être rajoutés (en parenthèse: par qui, quand):
– table pour les variables du moteur d’analyse et des règles de montage (NG, mi avril). FP donne les informations à NG pour les champs à mettre; LT va indexer ces tables de manière dynamique dans le CMS (système flexible) une fois qu’ils sont créés. But: pouvoir définir les variables pour l’analyse ainsi que l’ordre de filtrage des règles ainsi que les MIN et MAX. Le moteur de montage de FP va directement aller chercher les chiffres dont il a besoin dans ces tables (par exemple, de commencer par la continuité thématique qui est définie avec un minimum à 3 minutes et un maximum à 10 minutes, puis continuité de sujet, etc)
– table pour les settings de l’Iphone (NG, mi avril). Permet de centraliser les réglages qui affecteront le mixage ainsi que la présentation du montage en cours sur l’Iphone (par exemple de définir les échelles de temps de la présentation, de la lecture, la courbe logarithmique utilisée pour présenter la taille / longueur des médias etc)
– table pour la création des users / walkers: pouvoir créer les profils directement dans le CMS (et de les gérer par là également). LT communique avec NG pour les besoins et la manière de faire (NG, mi avril)
– table pour la génération des films (une sorte de batch, avec playlist); LT et NG (pour quand ?)

IPHONE:
NG explique ce qu’il a fait jusqu’à maintenant:
– mise en place d’un serveur de stream (lecture, mixage et envoi de plusieurs fichiers audio à partir des fichiers flv de la base de données). Important: garder les mêmes réglages (actuellement: mono 44.100 kHz, mp3); également, pour éviter des problèmes de compréhension et de mélange qui sature, il faut mixer les sons lors de la création / exportation des médias dans FinalCut. Nous allons définir des normes de ces prémix lors des prochaines exportations.
– NG a églement mis en place un média server qui sert de centrale d’échange entre les divers appareils / logiciels / scripts qui tournent en parallèle. A chaque parcours, une instance (session) est créé dans le média server; le serveur de stream devient alors une sorte de serveur ( une instance) dans le serveur de média – même chose avec le moteur de montage…
– NG va programmer l’application sur base des diverses indications et maquettes graphiques, en simplifiant au maximum: écran de login (user + pass); écran de présentation du processus en cours (avec variantes de sets de métadonnées ?); possibilité de recevoir une image du parcours / film généré (via mail + image sur un site). Il va intégrer dès mi mai le graphisme développé par Dimitri Delcourt.
– Questions ouvertes: gestion de l’échelle temporelle (adapter vitesse de défilement à la taille des médias: plus le média est gros / long, plus le défilement est lent; plus le média est petit / court, plus le défilement est rapide); gestion de l’échelle de présentation des médias calquée sur une courbe logarithmique.
– il va créer pour la présentation de juin une application téléchargeable depuis l’APP store; cela simplifiera l’installation de cette application sur des iphones des visiteurs. UF est en train de chercher un set d’une dizaine d’Iphones pour mi juin.
– Tout le paramétrage de l’Iphone se passe depuis le CMS (cf ci dessus)
– NG va faire un prototype à partir des fonction de base de l’Iphone, on va pouvoir tester dès début mai si notre logique tient (stream de données et d’audio, de présentation des métadonnées de manière fluide, la gestion des échelles etc)

MOTEUR DE MONTAGE:
– FP a étudié 2 méthodes d’analyse, et est reparti depuis le début dans une direction qui puisse gérer la complexité (tu peux nous écrire quelques lignes avec quelques détails là dessus ?)
– Il a besoin de travailler dessus jusqu’à mi mai, date à partir de laquelle nous pourrons faire des tests. Par contre, tout sera déjà prêt sur le CMS et dans le passage de main entre les processus et les opérations (cf le schéma de NG qui va arriver)

Ci dessous, quelques précisions apportées par Florian Poulin quant au travail qu’il est en train d’effectuer:
« Il y a deux approches possibles pour résoudre le problème de création d’un film à partir d’un parcours (respectant un ensemble de contraintes parfois contradictoires), qui est en fait un problème d’optimisation multi-objectifs :

1)      Algorithme exact : Cette approche permet de trouver directement la solution exacte au problème (la meilleure solution possible au problème d’optimisation). Elle peut être résolue en représentant un parcours de marcheur sous forme d’un graphe où chaque noeud représente un instant t du parcours, et chaque arc représente le choix de la lecture d’un média m depuis l’instant ti (noeud de départ de l’arc) jusqu’à l’instant tj (noeud d’arrivée de l’arc).
En analysant le parcours de l’utilisateur ainsi que les médias accessibles dans l’espace où il se trouve (et où il se trouvera dans les secondes/minutes qui suivent), on peut construire le graphe de tous les choix de médias possibles, satisfaisant les contraintes de couverture des médias sur la carte. Idéalement, sur chaque arc on devrait stocker un coût associé au choix du média, calculé à partir des diverses contraintes du projet (et cumulé au coût de l’arc précédent). Or, de part la nature des contraintes (dépendant de l’ensemble du chemin parcouru et non pas uniquement de l’instant présent), il n’est pas possible de calculer ce coût efficacement.
Une fois le graphe construit, on peut facilement énumérer tous les filmes possibles en parcourant le graphe (depuis la fin, les chemins menant à un film de la longueur souhaitée pointant vers le dernier noeud du graphe).
Si le calcul du coût avait pu être réalisé, l’arc pointant vers le dernier noeud et possédant le coût minimum désignerait l’arrivée de la meilleure solution possible au problème. Comme ce calcul n’est pas possible, il est nécessaire de parcourir toute les solutions possibles pointant vers le dernier arc, et de les évaluer une à une pour trouver laquelle satisfait le mieux les diverses contraintes. Cette opération n’est pas possible en raison du nombre trop élevé de solutions possibles (notamment induites par la définition des médias éditables). Leur simple énumération (sans leur évaluation) prend plusieurs heures pour un film de 5 minutes. (La solution est abandonnée)

2)       Algorithme itératif (recherche par voisinage) : Cette approche est radicalement différente. Au lieu de viser directement la meilleure solution, on va se promener dans l’espace des solutions du problème (incluant les bonnes solutions, les mauvaises solutions, les solutions aberrantes, mais également quelque part la solution optimale).
Ce parcours dans l’espace des solutions ne se fait pas manière totalement aléatoire, mais en se déplaçant de solutions voisines en solutions voisines (solution proches les unes des autres, avec une légère variation), en tâchant à chaque étape de se déplacer vers une meilleure solution, ceci afin de converger au final vers la solution optimale au problème (ou tout au moins, à une bonne solution). Seul problème : si on se contente de se déplacer d’une solution vers un de ses voisins améliorants, on se retrouve rapidement coincé dans ce qu’on appelle un optimum local (une solution meilleure que tous ses voisins, mais qui n’est pas l’optimum global). Il existe heureusement toutes sortes d’algorithmes pour éviter de rester piégé dans un optimum local (recuit simulé, algorithmes génétiques, recherches avec tabous, etc. à = méta-heuristiques).
Cette solution est la solution retenue (et en cours d’implémentation). Les principales difficultés de sa réalisation sont notamment la définition du voisinage (qu’est-ce qu’un film voisin d’un autre ?) et l’évaluation de la qualité d’une solution (intégration de l’ensemble des contraintes artistiques imposées pour un film donné). »
Florian Poulin, 08.04.09

Questions à résoudre:
– comment on gère les décalages temporels entre les divers processus ? Sachant qu’il y a plusieurs décalages (surtout s’il y a plusieurs parcours qui se déroulent en même temps), il faut qu’il y a un système d’anticipation / prédiction qui puisse garantir une certaine fluidité et réactivité. A priori, il y aurait un décalage d’une à deux heures entre le parcours et le film fini, présentable.
– pouvoir décrire le travail effectué (pour les non techniciens, pour pouvoir transmettre à d’autres techniciens): la question de la documentation technique (sans aller jusqu’au mode d’emploi). Daniel Sciboz va contacter NG, LT et VJ pour leur poser quelques questions surtout ayant trait à la présentation de la carte, mais à voir avec lui à quel point on peut ouvrir cette question à la présentation “non technicienne” des divers développements techniques effectués dans le cadre de ce projet.

UF, 09.04.2009

Laissez un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

;-)