vanille béchamel a écrit:

je suppose que cette latence est inévitable si la lecture commence "au même moment" que le chargement du fichier (opération gourmande en temps : trouver/lire sur le HD)

Mes clips vidéo sont dans le même dossier que le patch, donc ce n'est pas un pb de recherche de chemin.
Reste le chargement du fichier qui doit être longuet...
Les ssd doivent règler le pb, du moins l'améliorer.

vanille béchamel a écrit:

pourquoi ne pas enchainer les clips avec 2 jit.qt.movie en alternance ?

Il faudrait commencer par charger le clip_B dans l'autre jit.qt.movie à X ms de la fin du clip_A, pour qu'au switch le clip_B soit déjà en marche ?
Je me disais que ça allait être du bricolage mais tu m'en encourages à le faire ! Je m'y mets et te tiens au courant.

Dernière modification par Jitcode (2011-09-14 18:30:03)

vanille béchamel a écrit:

tu supposes que maxMSP cherche dans le dossier d'origine du patch en premier ... à voir !

Pas de changement de ce côté avec chemin indiqué ou non.

vanille béchamel a écrit:

Charger A et B.
Lire A.
Fin A : lire B, charger A.
Fin B : lire A, charger B.

J'ai fait un patch qui se contente d'enchaîner 3 clips dans l'ordre avec 2 jit.qt.movie pour étudier les comportements.
Je n'ai pas attendu la fin du clip A avec loopnotify pour lancer B car on avait toujours la pause du départ !
Le problème n'est pas seulement lié au chargement du fichier, il y a une latence avec le message Start que j'ai toujours eue.

J'ai donc anticipé la détection de la fin de A pour lancer B plus tôt (voir patch).
Le switch de A vers B se fait après le démarrage de B, et donc pas de pause ! Jusque-là je suis content.

C'est pour le 3ème clip C, que ça se gâte.
Si je charge C pendant la lecture de B, la micro-pause se reporte sur B en pleine lecture !!!!
C démarre bien mais je n'ai fait que décaler le problème.

C'est très gonflant cette limite, je voudrai passer mon temps à des choses créatives plutôt que contourner les limites soft/hard !
Il faut que j'apprenne à charger plusieurs clips dans un buffer, ça se fait avec de la vidéo ?

J'ai ouvert ton patch.
Ca fonctionne avec les clips de cycling 74, même si j'ai des doutes sur le fichier "crashtest" comme je l'avais signalé plus tôt.

J'ai changé la liste du "coll" pour mettre les miens, c'est toujours pareil que ce soit en mjpeg 25i/s 720x576 ou en mjpeg 15i/s 320x240.
Je n'avais pas mis le son, je constate maintenant les interruptions sonores. Aï.

Quand on branche un jit.fpsgui, ce qui me surprend dans ton patch, c'est que la résolution verticale est divisée par 2 (qu'on laisse l'argument unique ou non).

Lundi, j'essaierai de travailler mes exports vidéo.
Les 15 i/s que je fais apparaissent saccadés, ceux de cycling non (pb de désentrelacement ?).
Tu as essayé avec tes propres clips (4 ou 5s) en pal 720x576 ?

Il semble que la version pc de max n'est pas aussi aboutie que la version mac.

BON WEEK-END!

Sinon, autre piste pour debuger: le menu "Debug" depuis Max 5, de façon à tracer tout le flux et l'ordre des instructions.

Une remarque: pourquoi charger dynamiquement les fichiers, pendant la lecture (ce qui représente une opération supplémentaire et un accès disque) alors qu'il est possible de charger, avec "loadram", autant de fichiers qu'on possède de RAM ?

La piste OVERDRIVE mentionnée par Vanille béchamel est également importante à considérer, c'est un fondement du fonctionnement interne de Max.

Je viens seulement de voir vos messages de la page 2, je ne les ai pas pris en compte dans ma réponse !!! Je regarderai plus tard !!!!

Bonjour,

@ vanille béchamel
Merci au fait pour ton patch.
- L'objet "deferlow" (que je ne connaissias pas) permet de donner la priorité au stop, puis au chargement, or ça paraît plus important de donner la priorité au chargement du fichier non ? Je ne comprends pas.
- Le "colormode uyvy" est le mode d'origine des fichiers vidéo pal, ce qui évite une conversion ?
J'ai la version  7.6.6 de QT, il faut que je voie si je peux améliorer ça.

@ Derrgis
Merci pour tes messages.

Derrgis a écrit:

Une remarque: pourquoi charger dynamiquement les fichiers, pendant la lecture (ce qui représente une opération supplémentaire et un accès disque) alors qu'il est possible de charger, avec "loadram", autant de fichiers qu'on possède de RAM ?

C'est justement ce que je souhaite !
Le message "loadram" est associé à la lecture d'un seul clip, comment charger plusieurs fichiers vidéo d'un coup avec loadram?

Derrgis a écrit:

Sinon, autre piste pour debuger: le menu "Debug" depuis Max 5, de façon à tracer tout le flux et l'ordre des instructions.

J'ai regardé le mode debug, j'ai bien la fenêtre mais je ne sais pas la mettre en marche !
J'ai fait de la programmation en turbopascal il y a longtemps et je me souviens que c'était très utile.


PS : Là, je me demande s'il ne faudrait pas exporter qu'un seul fichier ou tous les plans sont collés les uns aux autres, puis les lire avec le message "time $1".
Ce qui nécessite au préalable de repérer tous ces "times" de début et fin. Fastidieux !

Dernière modification par Jitcode (2011-09-19 16:46:09)

vanille béchamel a écrit:

http://marquesdisparues.voila.net/Codec/Codec.html ;-)

Je ne connaissais pas ! Le consortium des épiciers il fallait y penser !!
Chez moi c'était plutôt coop avec les timbres à coller sur des pages entières pour gagner je ne sais plus trop quoi.

J'ai essayé "ma technique" (mettre tous les plans dans un seul fichier vidéo).
Quand tu pointes n'importe quel endroit de la vidéo c'est nickel, ce qui est compliqué c'est de détecter les fins virtuelles du plan pour passer aléatoirement au suivant. Je ne me suis pas trop attardé.
Comme quoi, ce n'est pas une limite machine mais logicielle, le chargement des clips vidéo n'est pas optimisé sur max.

J'ai essayé les patchs de http://abstrakt.vade.info/?p=147, très intéressant avec l'opengl, mais le pb du chargement de fichiers dans jit.qt.movie est toujours là.


IL FAUT BUFFERISER !!!!!!!!

Dernière modification par Jitcode (2011-09-20 19:36:09)

Merci Derrgis pour le debug, je vais enfin voir comment ça s'utilise.

Derrgis a écrit:

citation :

COMMENT BUFFERISER PLUSIEURS CLIPS VIDEO D'UN COUP ?

c'est possible avec plusieurs buffer~.
Autant de [jit.qt.movie] avec des "loadram" que la mémoire vive le permet.
Le problème va donc devenir "comment mixer plusieurs sources".

Si le nombre de clips est connu et surtout limité, je suis d'accord.
Je ne connaîtrai pas toujours le nombre de clips, je veux pouvoir charger un dossier de clips quelque soit la quantité (mes clips seront courts, pas plus de 10s chaque).
Ou alors je dois faire un maxi patch de 50 [jit.qt.movie] en sachant que charger 50 clips c'est le maximum ?
Peut-être que je vais en arriver là, mais je trouve dommage qu'il n'existe pas une solution au chargement qui s'affranchit des pbs de threads.


L'objet [buffer~] de msp c'est l'équivalent du message "loadram" dans jitter, je ne me trompe pas ?