Bienvenue invité ( Connexion | Inscription )
29/08/2009 00:36
Message
#1
|
|
Ri(n)oModo Groupe : Super Modérateurs Messages : 7.488 Inscrit : 18/10/2003 Lieu : Manaus, au centre de l'Amazonie Membre no 443 |
Je poste une copie de ce post de Leon pour continuer la discussion.
Citation Exact : le but étant de n'exécuter qu'une seule fois le script avs (qui est plus coûteux en calcul que la compression en deux passes !) Une fois le script avs exécuté avec VirtualDub et enregistré sans compression dans un fichier .avi, on fait mouliner le codec (via VirtualDub encore) sur le fichier .avi. Résultat de la manip : on n'exécute qu'une seule fois le script avs, pas deux ! ça m'intéresse cette méthode! 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 ? (IMG:style_emoticons/default/rolleyes.gif) 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 ? (IMG:style_emoticons/default/glass.gif) tu peux mieux détaller ces scripts parallèles? (J'ai édité pour corriger plein de coquilles... Je ne me relis pas assez. Léon1789) Ce message a été modifié par leon1789 - 29/08/2009 11:19. |
|
|
29/08/2009 10:56
Message
#2
|
|
Monteur Groupe : Rédacteurs Messages : 2.959 Inscrit : 04/05/2007 Lieu : Poitiers Membre no 26.133 |
tu peux mieux détaller ces scripts parallèles? Ok, imaginons que l'on veuille couper en 4 une vidéo créée par un script initial script.avs, et lancer 4 processus avs -> avi en parallèle (avec 4 virtualDub). Chaque processus avs -> avi est donné par un script parall_n.avs . Voici le premier (à placer dans le même répertoire que le cript initial script.avs) : Code import("script.avs") function coupe(clip video, int P, int N) { NBImages = video.FrameCount video.Trim(NBImages*(P-1)/N, NBImages*P/N-1) } coupe(1,4) La première commande import("script.avs") indique évidemment le script initial. C'est la dernière commande coupe(1,4) qui indique que ce script est parall_1.avs, et qu'il y a 4 parts découpées. Les autres parall_2.avs, parall_3.avs, parall_4.avs sont exactement pareils, mais on y place les commandes coupe(2,4), coupe(3,4), coupe(4,4) respectivement. coupe(P,N) : P indique la part à traiter, N indique le nombre total de parts. OK ? (IMG:style_emoticons/default/cling.gif) PS. Au fait, cela fonctionne aussi si la vidéo traitée est accompagnée d'une piste audio. (IMG:style_emoticons/default/aga.gif) Ce message a été modifié par leon1789 - 29/08/2009 11:22. |
|
|
Discussions similaires à la discussion "Accélération de l'exécution de l'encodage avec scripts avisynth"
Sujets récents
Nous sommes le : 25/04/2024 18:25 |