XP sp3 beta23
VVVV alone with the patch waiting for orders:
72% of the UC the 4 cores equally busy.
whitecat launched on core 2 94% UC busy. 4 cores equally more busy
perfmeter not stable, oscillating between 20 and 28fps
when file is finished to be played going down at 10/13fps ( play on on filestream but length finished)
i have a mainloop setted foreground and background to 60fps ( videoprojector is at 60Hz, and i have setted this for flashing texture quickly without black bands on the flash)
while doing video file nothing else in the patch is playing.
if you think this is a performances problem, i m thinking of process to set VVVV on one core and see, but where could i gain more ressources ?
swap memory is only used at 808Mo where i have 4Go Ram.
Since vvvv is generally is single-threaded I think it´s not possible to assign it to more than one core.
You could try ffdshow tryouts which can decode videos multithreaded on different CPU cores and it´s possible to specify the number of cores to be used. So if your CPU has 4 cores allow video-decoding on 3 cores and leave the fourth vor vvvv. (Uninstall all other codec(packs).)
Also try setting Wait for every Nth frame to 0.
And again worth a try: enable Increase Timing Precision on MainLoop (VVVV).
hi karistouf, did you try set Renderer (EX9) FreshRate to 50 or 75 (relative to 25 fps) and same to MainLoop foreground fps. Keep wait for frame at 1. All patch will run at 25fps, but it should be ok with synch .
getted back another computer to remote all the pacth from external in art-net. Desynchronisation is less than having white Cat on same computer.
Now, what i can say, is that there is still delay between audio and video, on my patch running alone on the computer.
about 1 second on 2mn 40 sec video. Maybe i didnt noticed this until now (i have done the editing so i know by heart relation between sound and images ;-) ).
I have a video at the beginning of the show being 30 minutes length with people talking… very very very nice…
Moving foreground mainloop rate from 25 to 30 or 120 fps is doing peanuts in this trouble, video is still taking a growing delay on audio.
a manual one, depending of levels received in midi
an artnet one, receiving same levels, but from artnet node
The artnet patch is lighter because it doesnt have any GUI based in a renderer.
The two patchs are exactly the same except reception of signal: midi or artnet.
In my opinion this is the art-net node giving somehow a blocking effect during the playing mainloop resulting this desynchro.
I m just testing in every sense actually, and i think this should be it. the two patches are exactly the sames. only the input technique differs.
Devvvvs ? your opinion ? i m sending artnet signal 50/second
EDIT: done two patches to check this artnet idea thing, the videoplayer alone, and an artnet sender.
Result is: no desynchronisation. So coming back to this statement:
a problem of ressources… not a problem from artnet node.
I’ve experinced this but I was using aviscript to play the videos to stop delays in swapping files, TBH I’ve don’t play audio and video often.
Have you tried splitting the audio from the avi and playing separatly?
You could use a syncing method like tonfilms video sync patch to sync the avi to the audio timeline…
I’d also use picvideo codec as I hate the look of wmv ;) and it gives a keyframe avery frame rather than every 24 or so with wmv.
Hi cat and thanks. I stopped to try to do somthing else as this trouble seems to come from an impossible part in vvvv to define. Thanks for your suggestions. Next time i will try the vlc plugin, in the hope it will work better than a nativ node .
Why “avi exporting generate a 13.2Gb file not readable”? If it’s your “30 minutes length with people talking” you dont need high bitrates?
720p - i would say 2-3Mb should be fully adequate if you use Xvid
I had project (not with v4) , where i had to play video synchro with life orchestra.
for 17 min piece I had to place 16 “frame-precise waiting points” to be able to correct and stay with tempo (“live editing”). first i start with wmv, but after while i had to move to Xvid because of precise keyframe setting feature.