pure-data : Fuidité video Gem + windows7

alwentio · 2012-05-10 17:57:37

Bonjour à tous,

Sur un projet video on est obligés d'être sur windows7, et bien que tout marche à peu près bien, le plus gros problème auquel je me frotte actuellement c'est la fluidité des videos avec Gem et pix_film.

Après des séries de tests il apparaît que le mjpeg en avi est le mieux supporté sur windows7 (avec Gem 0.93.3 et pd-extended 0.42.5 sur windows 7 64 bits), du moins sur mon système.
J'ai réencodé toutes nos videos avec ffmpeg, et certaines sont à peu près fluides, d'autre saccadent complètement, c'est moche. C'est aussi apparemment assez aléatoire.

Je ne comprend pas du tout pourquoi.

Le proc n'est pas à fond, le bitrate des videos est d'environ 3000k, ce qui ne pose pas de gros problème de lecture au disque dur, la mémoire de la carte grpahique n'est pas saturée, bref, je vois pas d'où ça peut venir.

Le [metro] du pix_film, lui, n'est pas stable, comme si le décodage de certaines frames prenait plus de temps que les autres...

Je me suis aussi essayé à faire pas mal de réglages pour pd.exe dans le panneau de configuration nvidia, enlever du FSAA, etc, mais pas de différences visibles. J'ai aussi essayé de mettre le processus pd.exe en realtime, pas plus de succès.

Des idées ?

Merci merci !

David

jona · 2012-05-10 21:03:55

Salut!

T'as du son dans ta vidéo?
Si tu en à, le mieux est d'ouvrir deux instances PD : une pour le son, l'autre pour l'image.

Il est aussi préférable de ne pas utilisé un [métro] ou [counter] pour lire l'image mais
un [snapshot] relier à la [tabread~] du son (donne le position sur le sample).
Ceci, toujours si tu manipule le son avec le visuel.

Après je crois qu'il est possible de loader l'image dans le RAM si c'est une grosse vidéo en Octet,
Je crois que c'est l'objet buffer..quelque chose.

alwentio · 2012-05-11 12:23:23

Salut Jona,

Le son est géré par un autre ordi indépendamment, mais j'essaierai bien quand même cette histoire de snapshot, pour voir.
Les videos sont quand mêmes trop nombreuses pour être chargées en RAM dans un buffer.
D'ailleurs ça m'a fait découvrir le [pix_buffer_filmopen] qui charge les images d'un film dans un buffer tout seul.
Là tout est décodé donc youpi ça doit être ultra fluide.
Mais la RAM va saturer trop vite, dommage...

Merci quand même!

jona · 2012-05-12 17:22:04

n'empêche, je comprend pas pourquoi tes vidéos rament comme ça.
Moi j'ai pas trouver plus fluide (et gratuit) que pure data pour faire de la vidéo temps réel.
Y'a aussi vvvv mais là ça rame vraiment.
Essaye peut être TouchDesigner de Derivative, un bon petit logiciel sous windows pour faire du temps réel.
Il est payant mais il y a une version gratuite.

Ton problème est peut être lié à windows7. Moi je tourne sous XP et aucun problème.
tchuss

pob · 2012-05-12 18:48:38

GEM utilise quicktime. Ta version de quicktime est-elle à jour ?

rep · 2012-05-13 13:42:42

pob a écrit:
GEM utilise quicktime. Ta version de quicktime est-elle à jour ?

je sais pas sous windows mais sous linux le dernier GEM utilise des plugins (en particulier pour la lecture de vidéos) : ça veut dire que GEM charge (ou pas) des fichiers objets qui s'interfacent avec V4L, FFMPEG, quicktime, imageMagick, etc etc
genre :

  video-support
    use mpeg             : yes
    use mpeg-3           : yes
    use QuickTime        : yes
    use aviplay          : yes
    use ffmpeg           : no

(http://lists.puredata.info/pipermail/pd … 39319.html)

Bref, sous linux, à la question : 'mon flux vidéo broute, que faire ?'
la première piste serait déjà de savoir quel est le backend que tu utilises ?
(voir aussi la conf de IOhannes à ce sujet : http://vimeo.com/36598445)

Bon, c'est peut être pas du tout le cas sous windows et quicktime est peut être le seul truc supporté, m'enfin ça vaut le coup de vérifier.

Sinon de manière générale si tu veux absolument éviter les lags :
- chargement des vidéo en ram avec [buffer], pour éviter les lags disque
- encodage des vidéos aux mêmes dimension/bitrate/option de codec/etc, pour éviter les lags processeur
(le mieux étant d'encoder les vidéos avec le moins de compression possible pour que le décodage soit simple)
- plusieurs instances de pd si besoin, pour éviter les lags audio si tu fais de l'audio
- éviter les interfaces trop compliquées, pour éviter les lags tcl/tk
- tisser ses patchs avec des fils droits, parce que ça fait plaisir à Olivier et que le [gemframebuffer] va plus vite quand ya pas de tournants (voir : http://codelab.fr/2469#p12526)

alwentio · 2012-05-14 11:09:47

Mais bien sûr ! Rep, tu as raison, mes fils n'étaient pas droits !
Quel con, maintenant ça va plus vite.

En fait pour ce projet je dois lire plusieurs videos en même temps.
Le moins possible simultanément mais en général 3 videos tournent en même temps, jusqu'à 6 ou 8 au maximum (mais là je n'espère rien)
Les 3 videos sont sur 3 disques durs différents, sur 3 instances de pure data/GEM différents, sur 2 videoprojecteurs, reliés à 2 cartes graphiques.

Je n'arrive toujours pas à des résultats vraiment fluides.
La libquicktime est à jour.

Sur mon système, le [pix_film] supporte DirectShow, QuickTime et AVI.
D'après ce que j'ai compris, Gem utilise le premier backend qui marche (ici DS)
On peut changer ça en rajoutant un numero après le message [open ( du [pix_film]
J'ai remarqué que c'était le backend qui quicktime qui était le plus fluide.

Evidemment c'est pour un live video avec plein de videos, qui changent souvent, et vite, donc faut oublier le chargement en RAM.
J'ai enlevé toutes les petites boîtes Tcl/Tk qui bouffent et mis des [speedlim] sur tout ce qui bouge (même si en fait c'est un autre processus gui gère ça)
Par contre, effectivement lire une video en avi non compressé est beaucoup plus fluide (mais ingérable en temps d'accès disque, pour en lire 2 par exemple)
Il y a donc un compromis à faire, qu'on a pas encore fait au niveau de la compression, entre bitrate faible pour un accès disque fluide et souple, et compression légère pour un processeur plein de vitalité, dès le matin.

Toutes les videos sont encodées par ffmpeg comme ça:
FOR %i IN (*.avi) DO ffmpeg -i %i -sameq -s xga -vcodec mjpeg -deinterlace %i[mjepg].avi

On obtient du 3000ko/s, à peu près, ce qui est confort pour le disque mais peut être que le proc n'aime pas.
Mais il ne sature pas pourtant (ou alors si mais on ne le voit pas sur le monitor ?)

Si quelqu'un a trouvé mieux je suis preneur !

Ah oui je précise aussi les videos sont des shoot cameras retraités par after effects exportés en avi non compressé (c'est lourd!!!)

Bon voilà, en tout cas c'est un vaste sujet, ça fait des années que ça dure donc voilà comparons nos solutions !
Mon prochain test pour la prochaine résidence : 3 ordis en réseau plutôt qu'un... quasi pas de compression, on verra.
Salutations !

sakramh · 2012-05-14 12:38:39

c'est pas le -sameq(uality) qui est en trop ? as-tu essayé la qualité par défaut décidée par fffmpeg ?

rep · 2012-05-14 13:01:44

alwentio a écrit:
Il y a donc un compromis à faire, qu'on a pas encore fait au niveau de la compression, entre bitrate faible pour un accès disque fluide et souple, et compression légère pour un processeur plein de vitalité, dès le matin.

je crois que le nerf de la guerre est la

alwentio a écrit:
Toutes les videos sont encodées par ffmpeg comme ça:
FOR %i IN (*.avi) DO ffmpeg -i %i -sameq -s xga -vcodec mjpeg -deinterlace %i[mjepg].avi

On obtient du 3000ko/s, à peu près, ce qui est confort pour le disque mais peut être que le proc n'aime pas.
Mais il ne sature pas pourtant (ou alors si mais on ne le voit pas sur le monitor ?)

oui le proc n'est peut être pas utilisé à 100%, mais selon mon expérience une faible participation du proc avec pd ne veut pas dire absence de lags...

à mon avis il va falloir que tu baisses ton bitrate, fais des tests, bloque le genre à 1500 et voit ce que ça donne visuellement, si ça se trouve c'est pas si moche...
Et sakramh à peut être raison : le -sameq est peut être en trop...
FFMPEG c'est tout un art... (et j'ai pas la solution ultime, va falloir que tu tatonnes peut être un peu )

alwentio · 2012-05-14 15:04:27

Ben oui, mais sans le -sameq la qualité est vraiment crade...

Ca fait un moment qu'on tatonne, mais bon on va continuer si je trouve une bonne solution, je la posterai ici.

Merci encore.

Et sinon pour infos sous Linux c'est quoi votre codec/bitrate/conteneur préféré beau et sans lags ?

rep · 2012-05-14 15:16:03

alwentio a écrit:
Et sinon pour infos sous Linux c'est quoi votre codec/bitrate/conteneur préféré beau et sans lags ?

mjpeg / libquicktime, après le bitrate ça varie...
vires le -sameq et joues sur le bitrate, et sur les dimensions aussi si c'est possible (720p est déjà pas mal)
au fait c'est quoi les caractéristiques des tes vidéos ?
t'aurais un exemple ?

alwentio · 2012-05-17 12:42:31

Arg, désolé pas le temps de tester tout ça je suis parti sur autre chose...

Mais vite fait, j'ai remplacé le -sameq par -qscale 1, et c'est plutôt pas mal.

Merci merci en tout cas, et puis si la science occulte des encodages ffmpeg révèle des secrets intéressants je reposterai ici.

Annonce

#1 2012-05-10 17:57:37 Fuidité video Gem + windows7

Fuidité video Gem + windows7

#2 2012-05-10 21:03:55 Re : Fuidité video Gem + windows7

Re: Fuidité video Gem + windows7

#3 2012-05-11 12:23:23 Re : Fuidité video Gem + windows7

Re: Fuidité video Gem + windows7

#4 2012-05-12 17:22:04 Re : Fuidité video Gem + windows7

Re: Fuidité video Gem + windows7

#5 2012-05-12 18:48:38 Re : Fuidité video Gem + windows7

Re: Fuidité video Gem + windows7

#6 2012-05-13 13:42:42 Re : Fuidité video Gem + windows7

Re: Fuidité video Gem + windows7

pob a écrit:

#7 2012-05-14 11:09:47 Re : Fuidité video Gem + windows7

Re: Fuidité video Gem + windows7

#8 2012-05-14 12:38:39 Re : Fuidité video Gem + windows7

Re: Fuidité video Gem + windows7

#9 2012-05-14 13:01:44 Re : Fuidité video Gem + windows7

Re: Fuidité video Gem + windows7

alwentio a écrit:

alwentio a écrit:

#10 2012-05-14 15:04:27 Re : Fuidité video Gem + windows7

Re: Fuidité video Gem + windows7

#11 2012-05-14 15:16:03 Re : Fuidité video Gem + windows7

Re: Fuidité video Gem + windows7

alwentio a écrit:

#12 2012-05-17 12:42:31 Re : Fuidité video Gem + windows7

Re: Fuidité video Gem + windows7

Pied de page des forums