Ça fait quelques mois que je n’avais pas posté d’articles, et pour cause…
Après quelques divagations de R&D (entre autre le SSDM, et quelques projets dont je n’ai pas parlé ici), je me suis aperçu qu’inventer des technos en indépendant n’était pas un modèle viable économiquement; malgré l’intérêt de Crytek et d’Ubisoft pour le SSDM, il semble que ce ne soit pas dans la philosophie de ces boites que d’acheter une techno seule. Comme il n’était pas dans mon optique de redevenir salarié, les négociations se sont arrêtés là.
Si une techno seule n’est pas vendable, proposer directement un produit finit semblait être la voie à suivre. Histoire de ne pas partir dans un projet interminable pour lancer ma boite (grâce au statut d’auto-entreprise), j’ai attaqué par un plugin.
Les nouvelles caméras HD proposent depuis 1 an le format AVCHD, destiné à remplacer le HDV; hors ce format est basé sur le h.264, codec difficile à éditer à l’heure actuelle. Autant la plupart des machines peuvent lire ces vidéos sans trop de problème, autant les logiciels de montage ont encore beaucoup de mal à gérer ce codec pour du montage temps réel, au point que la plupart sont obligés de transcoder les vidéos dans un format intermédiaire.
Choix techniques
Etant familier des GPU, c’est donc naturellement vers ça que je me suis tourné pour chercher une solution temps-réel. Actuellement, 2 technos permettent d’accéder aux capacité de décodage des GPU: DXVA et CUDA. Le premier fait le bonheur des lecteurs multimédia (type MPC-HC), le second des logiciels de transcodage (type Badaboom).
Je me suis d’abord tourné vers DXVA, qui a l’avantage d’être une solution multi-hardware (ATI/NVIDIA). Malheureusement, passé la simple implémentation dans un lecteur vidéo, je me suis bien vite aperçu que personne ne maitrisait vraiment cette technologie; pas même les développeurs de chez Microsoft, pourtant à l’origine de la norme. Une application pour du traitement semblait donc compromise. Restait donc CUDA, qui s’est avéré beaucoup plus souple d’utilisation.
C’est là que le challenge s’est présenté: entre développer une simple application linéaire (lecture/transcodage), et un moteur capable d’extraire n’importe quelle image à la demande, de façon totalement arbitraire, de plusieurs vidéos en simultané. Et faire en sorte que ce flux aléatoire tire partie au maximum des capacités hardware, autant qu’un flux linéaire le peut.
liste des GPU compatibles
Contacts et négociations
Ce projet n’aurai pas été réalisable sans l’accord et le support des différentes boites propriétaires des technos en jeu. Ainsi, tout ce qui concerne la partie décodage GPU n’est disponible que sous NDA avec NVIDIA.
Je remercie au passage les développeurs de Sony de s’être prêté au jeu, en m’offrant une licence Vegas Pro 9 et en le patchant avant sa sortie pour éviter tout problème de compatibilité avec mon plugin.
Pour obtenir ces contacts, LinkedIn m’a été grandement utile. A l’époque où j’écrivais cet article, j’en supposais les possibilités. Avec ce projet, j’ai pu les vérifier. Grâce à ce réseau, j’ai pu atteindre directement les personnes impliqués dans tel ou tel département de chaque boite, là où le service clientèle me répondait à coté plusieurs semaines après… La fonction mail est payante, mais il est tout aussi possible de faire passer un message en rajoutant les personnes de second ou troisième degré dans son réseau. Le double avantage, c’est qu’au fur et à mesure notre réseau s’agrandit (donc plus de boites joignables). Le projet m’a ainsi fait passé de 110.000 personnes joignables à 2.000.000 (en 3em degré).
Le développement
En 6 mois de développement, je n’ai jamais autant appris sur les subtilités du C++ qu’avec ce projet.
L’obligation de marier différents environnements (Vegas, Premiere, CUDA, et librairies diverses…) m’a obligé à comprendre certaines conventions qui m’étaient jusque-là complètement étrangères (type les conventions d’appels __cdecl / __stdcall), les pointeurs de fonctions au sein de classes, maitriser le fonctionnement des threads, les optimisations assembleur, les subtilités d’encapsulations et d’inclusions qui garantissent la compatibilité quelle que soit l’environnement, et permettent de valider à coup sur chaque étape.
Nécessité d’implémenter aussi une fonction de log, et truffer les différentes étapes du programme de ces logs. Cette boite noire s’avère indispensable à partir du moment où le projet devient complexe, et facilitera grandement le débuggage si un problème arrive chez un client.
J’en recopie ici une version simplifiée, qui génère un journal HTML:
//exemple d'utilisation: logerror("error decoding frame %u from file %s",framenumber, filename);
void logerror(char* format, ...)
{
static FILE* logfile;
logfile=fopen("c:/debug.htm","a");
static char logmsg[512];
va_list args;
va_start (args, format);
vsprintf(logmsg,format, args);
va_end (args);
SYSTEMTIME time;
GetLocalTime(&time);
fprintf(logfile,"<b>%04u-%02u-%02u %02u:%02u:%02u <i>[%s]</i></b><br>\n",time.wYear,time.wMonth,time.wDay,time.wHour,time.wMinute,time.wSecond,logmsg);
fclose(logfile);
}
Bilan
Le beta-test du plugin aura duré 6 semaines, pendant lesquelles plus de 100 fichiers issues de 12 caméras hd différentes ont été testés. Le moteur seul a été soumis à une dizaine de configurations grâce au concours de la communauté NoFrag, qui s’est montré comme toujours ouverte et réactive !
Après 1200h de travail sur 6 mois, et autant de builds, le projet est maintenant prêt pour une diffusion publique. Dans un premier temps, je lance la version Sony Vegas Pro 9 32bit et Adobe Premiere CS3/CS4, puis devrait suivre Sony Vegas Pro 9 64bit, et Thomson/Canopus Edius.
GPU Decoder sur DIVIDEFRAME.COM
http://www.vimeo.com/5181272