Bonjour,
J'ai des problèmes d'image figée au démarrage de la lecture d'une vidéo avec jit.qt.movie.
C'est très court (une demi-seconde) et ça passe presque inaperçu au point que j'acceptais celà jusqu'à présent.
J'ai écrit un patch qui enchaîne des fichiers vidéo de manière aléatoire.
Il y a du mouvement (enfants qui courent), et là les images figées en début de clips sont très ennuyantes puisque que ça casse la fluidité.
J'ai suivi les recommandations de cyclin74 concernant les vidéos (15 ips / 320x240 / codec mjpeg qualité maxi) et j'ai essayé le message "loadram" pour précharger les clips, ça ne change rien. Le métro est à 20.
Est-ce ma machine qui est trop poussive ?
Je suis sur portable dell (coreduo 2Ghz, 2 Go de ram).
D'avance merci.
Hors ligne
Bonjour,
difficile à dire sans exemple ...
A/ Optimiser ?
http://abstrakt.vade.info/?p=147
http://cycling74.com/2011/04/07/work-your-framerates/
B/ "le metro est à 20" ; il s'agit bien d'un [qmetro] et non de [metro] ?
Dernière modification par vanille béchamel (2011-09-14 07:42:37)
Hors ligne
Merci beaucoup vanille béchamel.
vanille béchamel a écrit:
difficile à dire sans exemple ...
Un simple "jit.qt.movie" suffit pour constater le problème chez moi. Il suffit de faire read, de charger un fichier, l'image apparaît en pause puis démarre (même avec un message "read, loadram").
Après ça roule, ce n'est pas les éventuelles saccades qui sont ennuyantes.
Je me suis quand même bien planté sur le "metro". En utilisant le "qmetro", j'ai grandement amélioré le fps !!!
Toutefois j'ai toujours cette bon sang de micro-pause au démarrage de mes clips (même en 320x240 15ips mjpg). Et quand ils s'enchaînent, ce n'est pas beau.
J'ai essayé les clips exemples du dossier "cyclin' 74\Max 5.0 \patches \media" et je constate que le problème se pose pour les fichiers "crashtest.mov" et "oh.mov" alors qu'avec "dishes.mov" et "wheel" ça va.
BREF J'AI UN PB A L'ALLUMAGE !!!!
PS : Merci pour les liens intéressant malgré mon anglais limité.
Dernière modification par Jitcode (2011-09-14 13:14:19)
Hors ligne
Bonjour,
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) ... pourquoi ne pas enchainer les clips avec 2 jit.qt.movie en alternance ?
Dernière modification par vanille béchamel (2011-09-14 16:23:31)
Hors ligne
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)
Hors ligne
Bonjour,
tu supposes que maxMSP cherche dans le dossier d'origine du patch en premier ... à voir !
Charger A et B.
Lire A.
Fin A : lire B, charger A.
Fin B : lire A, charger B.
Et patati et patata ...
Dernière modification par vanille béchamel (2011-09-14 18:32:09)
Hors ligne
vanille béchamel a écrit:
Charger A et B.
Lire A.
Fin A : lire B, charger A.
Fin B : lire A, charger B.
Ne pas attendre la fin du premier clip A pour charger B.
La première fois, il faut donc choisir aléatoirement 2 clips d'un coup ? Pourquoi pas, après tout.
Je pensais détecter les x dernières "ms" du clip A en faisant l'opération "duration - time" mais c'est un peu galère.
Hors ligne
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 ?
Hors ligne
Bonjour,
Est-ce que l'overdrive est sur ON ? (maxMSP/Options/Overdrive).
Hors ligne
Bonjour,
Non l'overdrive n'était pas sur ON, c'est censé apporter quoi ?.
Je l'ai donc activé en coupant internet, l'antivirus et le firewall, j'ai toujours la saute au même endroit.
Tu es sur Mac ? Constates-tu la même chose ? Ne serait-ce que pour faire démarrer une vidéo ?
Mon problème est la mise en buffer, non ?
Je me souviens de cette discussion http://codelab.fr/1951, sur un chargeur de vidéos.
Je n'arrive pas trop à le faire fonctionner et j'ai du mal à le comprendre, tu penses que ça pourrait-être une piste ?
Merci encore pour tes réponses.
Hors ligne
Bonjour,
http://cycling74.com/2004/09/09/event-p … -vs-queue/
la majorité des problèmes rencontrés avec maxMSP sont liés aux histoires de "threads" ;
grosso-modo maxMSP déroule trois "processus" en même temps :
- le son (DSP chain),
- les actions prioritaires (high priority thread),
- et les autres (low priority thread) ;
le but étant de garantir un déroulement "temps réél" pour les choses importantes, effectuant les tâches gourmandes en CPU (intéractions avec l'utilisateur, affichage à l'écran, lecture/écriture disque, jitter !) quand il peut.
Overdrive :
OFF : "high priority thread" et "low priority thread" sont gérés pêle-mêle ; donc si on lui demande trop de trucs d'un coup le timing n'est plus du tout correct ...
ON : mon réglage par défaut !
[deferlow] permet de passer une action de la file "High" vers la file "Low".
Est-ce que ce patch fige aussi ?
----------begin_max5_patcher----------
1783.3oc0assjhhCF9Z8ofhp16bsHbPf8pYe.1mftlpqHj1N8fDFHZ28L07t
ugDPIbHDEO0Wnn43++W9OlD987YlqIefJLM9GimLlM62ymMiWTYAyp9+Lysv
OhRfE7lY9FltL6cbZL4cyEh5S2skrilfn7VXWUpnH5mYHwvaZtf8w36UUGQR
H4aIw7ZM2849OqGtLHM5Ub5lmyQQTQessVZsv.XweXC73+aU3RqCCGNlONj0
u82fFzENslr.kk8m4yK+Zgl7JkrYSBpe1DLDahSoG4xA4k1e2Gi3dwXjTz6r
Ard3nnO3zhYlZV6ERJs.+KNiAbYT5.bLSj34sPZN9iVKuh5sVFX665AVv9ku
iusmW4uBb7rCcYKiM38AQqU7u8b4nkSidTRhovsBgn+MGCSL6hi1g8CjMmUT
dE7UgergFmf1ixKvjzFsdlILKqQwyZzkRP+MAW6s3PQ3TQQfCEki1iq6ennP
1R475JqYcWfMWN20mCAABLvw8H6yV12jPh9AhyqV0EFid4zFERFJ8XO3sP5K
4VhSyxQEnTJjVwDMmY3tD5y8K4HW+KvHzfct20zYlaxwwjzRhPpmkEWOcO0i
RUUKRgY8zYJgjrFlWtjrNAIsTyTpfoXlnMhhEzis0g9g2lky00aLVnTHaLds
HJmjjHMThZ12SMwLogHz63X5q7w5HZIYatobVS0coxao1uEUT.2Ta.SV2ufB
yoMqoWa.JrCLfQ9CX9.JzBAPf3gSfvfdikJkZ0s0rCaw.GUtsqKmaorRE6p.
ijr6.JZKgh9SCE8uInnjOHYPjZfMvCih1mIJVpctP1grNtY.9AK8j8ybZ3oy
f3I31fmEnDCKCvvHpyYhnqgoaJgz5m5JmJBbyyts+6SCWA2abk4gBkmbHv2a
pBujcyUNSDIsu2PI0XsgZam1STFkO55BqthGNSUB81HhJkWxHRgJyOYHXAHA
K8DPU6Hru2hSIDXrXg+RqYxGUMEip7hDLMgH26NZlYThm+GYOlE+4U1V24jn
3XKCBw1vIZjzVgxba53X5ixP9foQNTpjs5deoTNPZkCkZoT5ksRwzA.DakBG
p.UHleKM89Syrapl5NZZmtoFobpSZmil5oloepHET8RCcjTQGIczQSIcnzRU
mZp5zSUmhZ+oo1VFtsEoN0OlkIYqS4vzXxVCIespMOMhIJ87SpUHt9q5yly3
1cZa6YUO7VOokI4JP1cvUdQfE+10E9632UmT2ruPvuiR3GbCfe9rcZHrZGsZ
sczd0e2omCjFVWvo8BaDY6Vjvdjo48WtkEtQhw11Q1zC55NQ4Wd5wKZcpG8G
0imEHbkHpGf+JWe9uXOsV0IpmQLBIB7oJJnIqE3qVKnKKk7bLjBasX0Z0prg
6DxCfVCAyQSU2eRZ.5LDrV9Czm8HsUVydXxtCFQVCKcm88VMRVZS4D.TOAQ4
vhWonB5jlDa0SRLt30ROrSXFbTOC4Pb5jFe2QVGRfwXt87yeJ7FAjH+pLH7I
LAqTOAaf4qK2E3oLE9pmBxuHoSaBBFYcNBNogOT8vSygQ+vdZ5aViNEu7BNp
u4nUQR47TNLEv8n3mYF1XVMeFRo4306nhHWUYtBscsHwGPqg+96LqfGp+KF4
HXrweUrj4W65FT1oDPb0VH43dYbFYe2CISfFpAXKsC35jh35T8DqWHWx4klf
SGKMNN2T1N0nVAYWdzAaZhrYL5xfwL2l3zCYz+zgfN5osuhii6lrrXiPhyHL
sfJRW1Hf1RBmKm4bBb1puTbF3D3LmuTbl+IvY1eo3L6Sfy.WSEsFU1zMrNtf
at2oaRHr.3q1f0CdJj1NtA2NuawdANR0Cssjy6hZW+yCNgPxRIT7Ked8NxsQ
OmDOwtj4JdDN0Saa089fR94VDMmvboemN2IfzoB66NwCd5deOPJuao+jtju8
LFeCFCynF.iusKE+ycnxec3RiZTdgQM9VoPMyHF+YNJijSUcqGNWw6F2uQ8u
yCNhcjz0ObZKJA2DY71a23k9.kGeWFkh0e3ajjkzQG1SbtW.vnSf9CGj+v7p
aftLafVGy3XL6w65Xm.4Ox+8EXQCTnaPfchBbnnI5D5Q+QRLbTDJW2NY51VS
51F7XQ2qzEuOS51yJr7ts4txUbnI7aNn7+.UhrA7VBDhtWGtsjI.ZvsAmGy5
ZYWxBNha.sc3g+bk3GcE5benj4BzbQnGYy6IYaqqoofGJx18KIUGnq4zGLv1
9JaN8ZIa6qIc67PQ1NZZI4wJVA+ujZj5Z8y+gSBQK8wGJpN7KqDhNZigWPpt
pv587ar86q9UsS89706d7YdsdEyTTkx8ySfBUuWlb3TNQLwqoY6EwpWVytd.
jVUzQKo6pV+qXcdyQ0kjb0fhZQ1mFIw9yel++T2Qf9B
-----------end_max5_patcher-----------
sur macOS X.4.11 / maxMSP 5.1.9 / avec mon vieux macbook, je n'ai pas de problème, même avec un seul [jit.qt.movie].
Dernière modification par vanille béchamel (2011-09-16 13:39:41)
Hors ligne
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!
Hors ligne
Je n'ai pas regardé en détail, mais certains patches peuvent se corrompre à force de manipulations. Dans ce cas il faut reprendre le patch au format texte et recréer un nouveau patch "vierge" que l'on enregistre dans un nouveau fichier .maxpat sur son disque dur, à partir de ce texte (si je suis clair...)
Hors ligne
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.
Hors ligne
Bonjour,
je n'utilise jamais maxMsp/Jitter pour la vidéo, donc si c'est un problème spécifique de compatibilité entre quickTime et PC, un problème de format, ou un truc du genre, je n'y connais pas grand chose ;-)
Hors ligne
Pages: 1 2