Memory usage


my game is crashing after playing 5 minutes or more. I discover the problem is related to setTexture inside my Tasks. If I comment the setTexture, the memory is stable, if I do nothing, the memory still increasing.

def __animation__(self, task):
    taskTime = math.floor(task.time / self.animationRate)
    if self.currentTime < taskTime:
        self.currentTime = taskTime
        self.framecount += 1
        if self.framecount == self.frames :
            self.framecount = 0
        self.pCard.setTexture(self.sprite[self.framecount], 1)
    return Task.cont

help me.

Sounds like trouble. Can you put together a small but complete application that demonstrates the problem?


I did this very simple program, it increases the memory usage a bit in this case, windows system indicates 4k here. The original program increases 300 to 600K or more, very fast.


mhm. for me it starts with 32megs, then over time increases to 35. but doesnt grow further. i modified it to run at 1300fps swapping textures each frame. it grew a lot faster from 32 to 35megs. but didnt increase further. tested on ubuntu 9.04 fully updated, 64bit.

Could a faulty driver increase memory usage?

thank you for testing.

I will test in other hardware/system to be sure that is my hardware/system and not panda that is causing this problem.

I developed a game that uses 4 second video clips that are played in random order as the background animation but while testing discovered the game crashes when running it for several days. A requirement of the game is that it runs 24 hours a day in an arcade.

I’m running it under Ubuntu 10.10 32-bit with Panda3D 1.7.2. The problem has been reproduced on three machines all with the same hardware specs: Celeron 430 (1.80GHz), 4GB DDR3, NVIDIA GeForce 8400 GS (512MB)

I have tried encoding the videos using H.264 and MPEG4 Xvid. I noticed when using the videos encoded with MPEG4 Xvid, the memory leak is actually slower than when using H.264.

For example when using MPEG4 Xvid, it took almost 3 hours to increase memory usage by 0.6%. But using H.264, the memory usage increased by 2.4% in only 45 minutes. I’m using the System Monitor in Ubuntu for monitoring the memory usage.

The small program below demonstrates this problem. I can’t provide the videos for the example code since the game has not been released yet. If it would help I could find some free stock videos and provide those.

from direct.showbase.ShowBase import ShowBase
from panda3d.core import *
from pandac.PandaModules import *

# Video dimensions

class Application(ShowBase):
    def __init__(self):

        props = WindowProperties()
        props.setOrigin(0, 0)
        props.setSize(VIDEO_WIDTH, VIDEO_HEIGHT)

        cm = CardMaker("backgroundPlane")
        cm.setFrame(-1, 1, -1, 1)
        self.backgroundPlane = render2d.attachNewNode(cm.generate())
        self.movies = [BackgroundAnimation("Background01.avi", "videoEnded"),
                       BackgroundAnimation("Background02.avi", "videoEnded"),
                       BackgroundAnimation("Background03a.avi", "videoEnded"),
                       BackgroundAnimation("Background03b.avi", "videoEnded"),
                       BackgroundAnimation("Background04.avi", "videoEnded"),
                       BackgroundAnimation("Background05.avi", "videoEnded"),
                       BackgroundAnimation("Background06.avi", "videoEnded"),
                       BackgroundAnimation("Background07.avi", "videoEnded"),
                       BackgroundAnimation("Background08.avi", "videoEnded"),
                       BackgroundAnimation("Background09.avi", "videoEnded")]

        self.accept("videoEnded", self.videoEnded)

        self.currentMovie = 0

    def videoEnded(self):


        self.currentMovie += 1

        if (self.currentMovie >= len(self.movies)):
            self.currentMovie = 0

        self.backgroundPlane.setTexScale(TextureStage.getDefault(), self.movies[self.currentMovie].getVideo().getTexScale())


class BackgroundAnimation:
    # videoFile - video file
    # finishEventName - event that is fired when the video finishes playing
    def __init__(self, videoFile, finishEventName): = loader.loadTexture(videoFile)
        self.sound = loader.loadSfx(videoFile)

    # Start playing the video
    def play(self):

    # Stop playing the video
    def stop(self):

    # Return the video object
    def getVideo(self):


Hmm, that’s troublesome. I don’t want to be the one to always be pointing the finger at anything other than Panda, but from what you say it sounds like ffmpeg is the one to blame here. If the leak were in Panda, it wouldn’t have anything to do with the video codec. Panda just asks ffmpeg to decode the video into frames, and then copies those frames into the specified Texture object.

It’s certainly possible (maybe even probable) that we’re doing something wrong with our use of the ffmpeg library–we’re supposed to be making some per-frame call to tell ffmpeg to release its previously-decoded frame or something that we’re not making. But documentation on ffmpeg is really obtuse, and seems to consist largely of example code (which we’re more-or-less following). If you or anyone else has some specific advice about this, I’d love to hear it.


I remember from another thread I had a question about why video playback was hesitating and you had me try a nightly build to see if that fixed it. You had said that 1.8.0 used a newer version of ffmpeg. My only problem with running one of the nightly builds is it could be unstable and I wouldn’t want to use it for production.

Not knowing much about ffmpeg, is it possible to just locate the newer version of the library from 1.8.0 and use that with 1.7.2?

Here is the thread I’m referring to: [url]Video looping pauses]


You can certainly install the latest version of ffmpeg and drop it into the thirdparty directory, replacing the older one there already, and use it to rebuild Panda3D 1.7.2 from source.

I’m not 100% sure that Panda 1.7.2 will build successfully with the latest ffmpeg–they change the API from time to time, and we have to change the code to keep up–but it’s certainly worth a try.


You could install VirtualBox and make a new virtual machine where you’ll install a Linux distribution (if you don’t want to pay licenses for experiments). This way you don’t modify your production setup, and you can do experiments (if the virtual machine has troubles while executing the built programs you can put them in a shared folder and test them with the physical machine).

yaio thanks for the VirtualBox tip. I downloaded the nightly build from 11/18/2011 and tried it out with the game. The frame rate dropped significantly in many places and the video playback for the background had all kinds of artifacts that never were there before.

I installed the nightly build on my test machine after uninstalling 1.7.2. I didn’t use VirtualBox because I doubt a VM could handle the video playback.

Any ideas why this build is so slow?

No ideas. If anything, video playback should have been much faster (though other operations may be about 10% slower due to enabling threading in the build).

Still, I wouldn’t expect a “significant” frame rate drop, nor new video artifacts. Is this something you can replicate with a simple code snippet that I can try out?


I can reproduce the video artifact problem with the code in my first post, I just can’t provide the video files.

I’m starting to think I’d be better off not using videos for the background animation. The animations were originally done in Adobe Flash so I could split apart the scenes into separate animations and reassemble them in the game.

OK, I understand. It’s too bad you can’t provide the video files, because I would like to see examples of videos that are producing artifacts in the current build that worked well in a previous build–I don’t want the latest build to be less robust than older builds.

But all of my video files work fine in the current build.


Let me try to talk my client into allowing me to share the animations with you…


Did you get my private message?

Yes, thanks! I’ll be able to look into it shortly, but I’m a little busy at the moment, my apologies.