Filestream/Video Texture Leak

I’ve been testing a video switching patch, had it looping through switching multiple video files (5 or 6 seperate files at a time) using mjpg, with the ffd decoder and a vmr9 video texture. After a couple of hours its been hanging, last night I disabled undo and left it going, this morning it hadn’t hung bu memory in task manager was reported to be 1.5GB and the TTY was saying that it had failed to load the various movies, I’ve just tried to copy and paste it in but vvvv has hung now :( Ah actually copy and paste seems to be broken in firefox too

but
ds connect from : Output to : VMR Input0
failed to open: “e:\loops\abstract.avi”
removing filter IAT YUV
removing filter RGB transform
removing filter AVI Decommpressor
removing filter AVI splitter
removing node Video Mixing Renderer 9 from filtergraph

is the jist of it…
Any suggestions? Is it FFDshow, vmr9, filestream? Going to try installing the pegasus mjpg codec and see if that helps at all, dont want to loose vmr9 texture as it works so much faster than the old one, but will try that next!

No ffd show, switching avi’s every 2 seconds, 52 minutes later I get this error. These files are pegasus mjpg. VVVV’s System memory was up from 98M ro 500M
The file names are still switching, the file sream is just not reading the new file :(
Obvious don’t need to switch evry 2 seconds for the install but I’m trying to minimise the chance of crashes once its installed!
Cat

09:13:49 : FileStream (DShow9).Audio --> C:\Documents and Settings\cat\Desktop\MTO patch switcher\Mto Switcher\AVI’s\olaf\6 Chorus2.avi.Output
09:13:49 : FileStream (DShow9).Midi --> C:\Documents and Settings\cat\Desktop\MTO patch switcher\Mto Switcher\AVI’s\olaf\6 Chorus2.avi.Output
09:13:49 : FileStream (DShow9).Video --> C:\Documents and Settings\cat\Desktop\MTO patch switcher\Mto Switcher\AVI’s\olaf\6 Chorus2.avi.Output
09:13:49 : Adding node to filtergraph: VideoTexture (EX9.Texture VMR9 YUVMixingMode)
09:13:49 : Connecting from: FileStream (DShow9).Video to: VideoTexture (EX9.Texture VMR9 YUVMixingMode).Video
09:13:49 : ds connect from: Output to: VMR Input0
09:13:49 : No combination of intermediate filters could be found to make the connection.
09:13:49 * : Failed connecting Pins
09:13:49 ERR : The operation cannot be performed because the pins are not connected.
09:13:49 ERR : The operation cannot be performed because the pins are not connected.

Bug.v4p (31.9 kB)

I’ve swapped the videotecture YUV mixing mode for the standard videotexture and the memory leak seems better (going to continue testing), so I think there is still something wrong. This node is so much better than the original, it would be good for it to work properly!
:)
Cat

6 hours later and its still going strong, mem usage up to 144Mb, so there is definately a problem with the YUV mixing mode texture…

22 hours and the memory is at 250MB, so there is still some leakage with the normal texture but significantly less than the mixing mode.

hi catweasel

have you tried a different codec? i am pretty sure that the leak is not produced by the vvvv process since we playback also with mixing mode without a leak. maybe ffdshow?

David

I started using ffdshow, and took that out in case that was the issue. There is a big difference between the 2 video texture nodes too, which suggests a problem there too dosen’t it?

But I’ll try a different codec, although I’m using mjpg, which I’m loathed to loose, mainly due to all my avi’s being mjpg, but also quality to playback, it comes top!
This is for an unattended installation in another country so I’m trying to get it as stable as possible! I can shut down every day so the normal video texture will do the job, but I’d like to use the mixing mode as files switch faster.
I’ll report back later…

Cheers

So I’ve installed picvideoV4 and I can see the memory increase with virtually every file change (this is YUV mixing mode again as the other texture shows up as B/w for some reason)
So ffd does it, microsoft built mjpg does it, and picvideo does it. Next up I’ll try indeo or something…

sure no XPath in use? in beta 20 it has a known memory leak.

No xpath, just a slightly more complicated of the version above…
Just tried wmv’s with yuv mixing mode texture, and memory increased, more slowly than mjpg, but then
00:38:24 ERR : The operation cannot be performed because the pins are not connected.

and the files stopped switching as in the first part of this post, memory had gone from around 130MB on start to around 200M.
Have you tried running the patch above for a while as it seems to show the effect quite quickly…
I’ve been opening task manager to keep an eye on memory in case of vvvv crashes, and you can see it tick up within minutes of starting on my system.

hei cat,

thanks for your extensive bug report. i’ll look into that as soon as possible, which could still take some time…

Cheers Joreg, you know me, always carping on about video playback in a generative software… ;~)