OpenMovie()/CloseMovie() memory leak?
Blitz3D Forums/Blitz3D Programming/OpenMovie()/CloseMovie() memory leak?
| ||
I've just cracked playing a movie onto a textured cube (based on someone else's code of course) but I've noticed that AvailVidMem() returns a progressively lower figure each time the movie is restarted (in order to loop). I thought CloseMovie(), then OpenMovie() would cure this but it didn't. Check out the example with your own avi or mpg (gifs work fine with no memory loss). I can't see any way around this since there is no movie equivalent of FreeEntity() . The danger is that if a movie is left to run (say, simulating a TV screen) then eventually the user's system will lock up. Graphics3D 800,600,32,2 SetBuffer BackBuffer() font=LoadFont("arial",20) : SetFont font camera=CreateCamera() : light=CreateLight() cube = CreateCube() : MoveEntity cube,0,0,3 : ScaleEntity cube,1,0.5,1 movietex = CreateTexture(256,128) : EntityTexture cube,movietex movie$ = "sample.avi" : hmovie = OpenMovie(movie$) ; any AVI or MPG framePeriod = 1000/30 : frametimer = CreateTimer(framePeriod) While Not KeyHit(1) WaitTimer frametimer If t>5 t=0 If Not MoviePlaying(hmovie) CloseMovie(hmovie) hmovie = OpenMovie(movie$) frame = 0 Else SetBuffer TextureBuffer(movietex) DrawMovie(hmovie) frame = frame + 1 : Color 255,255,255 : Text 0,0,"Frame "+frame SetBuffer BackBuffer() EndIf EndIf t=t+1 TurnEntity cube,0,.4,0 UpdateWorld() : RenderWorld() Text 0,0,"AvailVidMem() "+AvailVidMem() Flip() Wend End |
| ||
doubt this will make any difference to the memory issue, but you might wanna replace DrawMovie(hmovie) with DrawMovie hmovie,0,0,256,128 when testing that code. |
| ||
maybe they have a system in place for flushing the oldest data from memory when you have used up all the available buffer and try to load a new movie, dunno. Deffinatly doesn't seem to flush it immediatly on close tho. |
| ||
Thanks Rroff, I already do DrawMovie hmovie,0,0,256,128 etc in my main code. It might be that only Blitz Support can answer his one. Hell, Blitz Support? Any ideas? |
| ||
heh I was testing it and getting a black cube with the frame counter on it and was like "eh?" I played with a bunch of stuff but I can't see any way myself to clear the memory without having access to the blitz code itself, tho I thought of several possible work arounds, but they aren't 2 second coding jobs. |
| ||
I think it's time to bounce this over to the bugs forum. |
| ||
Since we are taking about Movies, I hope Mark will also add exact Frame Access and Pause / seek, cause I tried to use MCIsendstring as a replacement, but MCI is definitively driving me crazy. Everything works nicely - sometimes, depending on the color of my neighbours socks and the weather. |
| ||
John, I had this same problem a while back - did not find a solution I'm afraid. Can also confirm your suspicions are true - the system did die a death after a (substantial) amount of continuous play. The program in question was used at an exhibition, 3 days of 9 hours each - the memory would run out around lunchtime each day, so I restarted the app. about every three hours to be safe. After the show tracked the leak down to the movie section - had a menu system where a random movie was called in as a background to the options screen. Sorry to be no help - but can at least confirm your findings. Funky Frank |
| ||
Thanks Frank. At least it's good you've confirmed this. As I say, I've bounced this over to the bugs forum. jfk, I've also used MCIsendstring quite extensively, but not with Blitz3D. I'm puzzled how you could do this. Any chance of sharing? |
| ||
It's in the code archives. The sucker simply refuses to actually go to a frame when I tell it to SEEK and Update etc :) - well sometimes. and sometimes not... (Note: you can only access the frames (eg using copyrect) when you are in fullscreen mode, on the frontbuffer) |
| ||
"The sucker simply refuses to actually go to a frame" Yeah that sounds like MCIsendstring! Oh god, we really need an update to the movie and sound systems in Blitz. Mark???? |