Salut,

Je n'ai pas vu dans ton patch des trucs qui pourraient poser problème. Ya des trucs qui ne fonctionne pas chez moi, mais comme je n'ai pas tous les patchs...

J'ai eu aussi un patch qui plantait de façon aléatoire. Il s'est avéré que c'était la communication IP qui en était la cause. J'avais 1 patch qui toutes les 5sec. vérifiait qu'un autre patch était bien ouvert sur 1 autre ordi, et régulièrement, l'un ou l'autre plantait. J'ai changé la fréquence de comm. (je ne vérifie plus que le patch est ouvert, je vérifie qu'il reçoit bien les infos que je lui fait parvenir) et le patch tourne désormais 12h sans problème.

C'est peut-être une piste.

Enfin, pour lire une vidéo, j'utilise l'objet [pdmtl/gems.movies~] qui gere la video et le son

Bon courage

Hello,
[pd~] fait communiquer 2 instances de pure data, mais c'est l'instance maitre qui s'occupe de la diffusion, donc si il y a des lags dans l'instance maitre, ça fait aussi des sautes.
En vrac en plus du commentaire de tepaze:
La première chose que je ferai, c'est d'optimiser les vidéos : codec adapté (prores sous mac H264 sous linux, mais il y en a d'autres on a déjà eu ce genre de discussions dans ce forum.), résolution adaptée (les 3/4 du temps sur le mapping, un film de 480p suffit.)
Je sais qu'il y a une option de threading sur le pix film, tu peux tester, mais je doute que cela ne fasse grand chose, sauf pour les clicks audio.
Si tu peux te passer des delays, c'est mieux...
Ouvrir l'instance de pure data en mode verbose pour voir là où ça crashe, (et tant qu'à y être, -noaudio, -nrt, -nomidi, -nogui)
bourriner sur ton patch afin d'essayer de reproduire l'erreur.
Peut être aussi ne pas arrêter le flux gemhead, mais mettre un spigot après le pix-film plutot.
Et ca m'arrivait de faire planter pure data quand je chargeait un film qui n'existait pas.
Pas d'autres idées...
++

Bonjour à tous.
Je m'y recolle, j'ai la semaine pour m'en sortir...
Là, je suis en train d'explorer la piste Pdmtl.
Premiers trucs étranges :
j'ai pas [gems.movies] mais [gemsMovies]
pas de sortie audio de l'objet
pas de bang de fin alors qu'il est indiqué en outlet 3 dans l'aide
un peu bizarre, problèmes de versions ?
Mais ça me semble tout de même à première vue plutôt souple et stable.
Si vous avez des éléments de réponse qui me font gagner du temps ce serait formidable !
Merci d'avance.
J'y retourne.

albdet a écrit:

Ça serait jouable à partir de [readanysf~] d'obtenir un compteur correct à envoyer dans le [pix_movie] ?

Ouep pour ma part c'est ce que je fais (il y a un post de Philippe Boisnard qque part sur ce forum à ce sujet...) et c'est pour moi la meilleure manière(*) de faire de l'audio/vidéo avec pd/gem.

(*)pas de lags, bonne synchro, pas de plantages pourvu que l'on travaille avec les 'bons' codecs

Hello,

pour un projet de synchro audio vidéo, j'ai utilisé GEM avec vidéo en mjpeg et le lecteur audio moonlib/sfread2~ séparés en 2 instances et reliés par un netsend/netreceive qui envoie depuis le lecteur vidéo la frame à jouer en audio (convertie en secondes modulo le FPS)
ça marche plutôt bien sans click et je n'ai a priori pas à augmenter la latence
idem avec le lecteur readanysf~ (le tout sous linux)
tu utilises toujours 2 instances dissociées ? ça semble ne aps être le cas dans ton patch (pd~)
pour pd-l2ork, il faut effectivement utiliser le flag -unique
si ça click, c'est que l'instance audio "sature" de calculs,
si c'est simplement pour déclencher la lecture vidéo audio, un nom de vidéo/audio à lire envoyé via netsend au deuxième patch ne devrait pas provoquer de clicks d'autant plus si tu as plusieurs coeurs sur ton ordi
ça doit marcher comme cela dans ces patchs https://github.com/b01xy/cyberlapsus

++
b

Dernière modification par benjamin (2017-05-11 23:44:31)