Version imprimable du sujet

Imaginons qu'on a un script avs très couteux en calcul (par exemple, avec un SoftSharpen quelque part) et on veut faire un (des) encodage(s) en plusieurs passes, avec un(plusieurs) codec(s). Nommons script.avs ce script. Si on laisse ri4m faire comme d'habitude, à chaque passe (pour chaque codec), il exécute script.avs systématiquement avant de faire tourner le codec dessus, ce qui est une énorme perte de temps, et cela d'autant plus qu'il y a de passes et de codecs : en effet, le script avs donne toujours le même résultat quel que soit le codec qui suit dans le cheminement de la compression !

(En ce moment même, je suis en train de comparer différents réglages des codecs xvid, divx et x264 sur une "vidéo softsharpée" : bien que cela représente des dizaines de compressions, il est clair que je n'ai exécuté le script avs qu'une seule fois pour toutes. Ainsi, je vais deux ou trois fois plus vite à chaque passe !).

Comment faire pour n'exécuter qu'une seule fois le script avs. Avec virtualDub, on charge script.avs puis en sauvegarde le résultat en demandant une copie directe du flux vidéo ("video / direct stream copy"). En faisant cela, virtualDub enregistre dans un fichier avi le résultat du script avs (exécuté maintenant, une et une seule fois). Attention, le résultat peut faire des dizaines de gigas octets (puisque le format vidéo sauvegardé n'est pas compressé) !

Ensuite, pour compresser la vidéo, on charge le fichier avi dans Ri4m, et on fait mouliné le codec de choix, autant de fois que l'on veut...

Conclusion : phase préparatoire avs -> avi , puis phases de compression avi -> avi

OK ?



Bon, cela fonctionne bien en théorie (et ça marche dans la pratique évidemment !), mais on s'aperçoit que le processeur (surtout s'il est multi-coeur) peut ne pas travailler à fond lors de l'exécution de script.avs quand on crée le fichier avi lors de la phase préparatoire avec VirtualDub. On perd donc du temps... C'est bateau, hein ?
En effet, avisynth (qui exécute script.avs sur la demande de VirtualDub) est mono-tread "par nature". Mais on peut/veut gagner du temps en utilisant toute la puissance du processeur lors de cette phase préparatoire avs -> avi. Deux solutions :

-- la première est d'utiliser avisynth MT et espérer que le script avs pourra être multi-treadé efficacement. Pas évident (moi, je n'ai pas réussi, mais je n'ai pas tenté très fort et longtemps...), et en plus, ça m'a l'air d'une usine à gaz. Des gens travaillent sur ce projet pour mieux le développer.

-- la seconde (elle est perso, et elle m'est venue très naturellement) et de faire des scripts avs (nommés parall_1.avs , parall_2.avs, ...) qui prennent uniquement une part de la source à traiter (par exemple une moitié, un tiers, un quart, ...). Ca c'est facile, pas de problème (je pourrai montrer ce script parall_n.avs) : chaque parall_n.avs fait appel au script script.avs, et cela se passe très bien, sans même savoir ce qu'il y a dans script.avs. Ensuite, on exécute simultanément tous les scripts parall_1.avs , parall_2.avs ,... : par exemple, parall_1.avs traite le premier quart de la vidéo, parall_2.avs le second quart, etc. Là, il faut un disque assez véloce car les choses dépotent ! En effet, chaque processus avisynth exécute un parall_n.avs (qui appelle script.avs, vous suivez ?!) et virtualDub enregistre sur le disque dur le résultat non compressé : autant dire que les méga-octets défilent à une vitesse folle... Bref, ainsi on obtient rapidement le résultat dans plusieurs fichiers avi : un fichier par script parall_n.avs. Il convient ensuite de les recoller, mais ça c'est facile avec une seule ligne d'avisynth...

OK ?

tu peux mieux détaller ces scripts parallèles?