Wait a minute. When did OpenAL get released? Did I miss something? Or is it just in testing right now?
I was just in the process of building panda 1.4.1 on Friday, which includes the new OpenAL stuff. I seem to recall that I ran into a minor snag of some sort, not related to OpenAL. I would have worked on it over the weekend, but I had a houseguest. So basically, any time now.
Update: OpenAL runs fine under windows and debian etch. But it crashes horribly under most versions of linux.
I don’t have time to fool with this any more, so I’m going to release 1.4.1 with OpenAL disabled under linux. I’m hoping that a few brave souls will help me debug it. (Ie, download the 1.4.1 source, compile it up, turn on OpenAL, then see what the heck is going on).
I’ll download and attempt it as soon as the source is posted. Although, I am running Debian sid and I don’t know if that’ll be much different from etch.
Maybe it is time I created a new partition for Fedora 6 or something…
I’d be happy to help , alas im running ubuntu based linuxmint, but id be happy to Xen this…
( though I might install something else as base soon so if so ill def. grab and compile )
cheers
nl
Compiled 1.4.1 source on Fedora Core 7 (disabled building fmod audiomanager) successfully.
I enabled the OpenAL audiomanager and am now watching a movie synchronized to its soundtrack without problem.
The only thing I’d like to complain about is the framerate: 10-20 fps when watching a 640x368 XVID file…
/tries something else
I resized the movie file to 512x512. Now I get a framerate of 40-50 fps. Would there be a way to easily do the rescaling to power of 2 texture size on the fly? I am guessing ffmpeg could do this.
The way it handles NPOT movies is as follows:
-
If the config variable “textures_power_2” is set to ATS_none, meaning that textures should not be rounded to a power of two, then the movie player will simply create a texture the same size as the movie.
-
If the config variable “textures_power_2” is set to anything other than ATS_none, meaning that textures should be rounded to a power of two, then the movie player will round the movie size UP to the next power of two. Then, it will load the movie into the lower-left corner of the texture, and show only that portion of the texture.
The default value for the config variable is ATS_down, so the default behavior is to stick the movie in the lower-left-corner of the texture.
Now, if you edit the config variable and tell it to use NPOT textures, but the video card can’t handle NPOT textures, then at some point something in the system is going to have to rescale the data — a slow operation.
Check and see if that’s the problem.
Wait, I just realized - assuming that you haven’t altered the config variable, the 640x368 movie is being loaded into a 1024x512 texture. So by reducing the movie to 512x512, you’ve cut the size in half.
It occurs to me that the way the code currently works, the texture object doesn’t have any concept of “active region” - ie, even though only the lower 640x368 portion of the texture is “in use,” the whole 1024x512 texture is getting uploaded to the video card every frame. That’s twice as many pixels as need to be uploaded. Modifying the texture object to record some sort of active region would probably be a worthwhile optimization.
One could even go a step further and modify the texture object so that it only stores the active region in the texture’s RAM image. However, that would be a major code overhaul. I doubt it’s worth the trouble.
I did not change any config variable and the behavior was as your scenario 2.
I have now rescaled the movie file to 1024x512 and get the same performance as with the 640x368 file.
So the bottleneck is the uploading of these large textures to the video card in OpenGL?
I just tested it myself. I’m getting 215 FPS on a sempron 1.8GHZ with integrated GeForce 6150LE video. So the problem must be something that’s being triggered only on your PC, and not on mine. What kind of PC do you have? Maybe I can find something similar and duplicate the problem.
I have an AMD 1800+ XP (1.5 GHz) cpu with an AGP Geforce 7600 GS video card.
I found that if the motion in the video is faster, the framerate drops a bit, but I don’t think a factor of 10 difference in fps can be explained by us watching different movies.
I will see if there is a new driver for my video card available. I assume you are running debian? Which version of the nvidia driver are you using?
You’re using a different movie? What happens with the movie in the distro?
Running the sample program Tut-Media-Player.py using the movie with the sneezing panda, I get 60-70 fps. This is a 450x360 movie, so I guess it uses a 512x512 texture.
Just to be clear: earlier I was watching a Battlestar Galactica episode 
. With the 512x512 version of this movie file I got 40-50 fps. The bitrate of this movie is about 2 times higher than the sneezing panda movie, which might explain the ~20 fps difference.
Hm. I was watching music videos with it, and I didn’t notice any slowdown, but maybe I should try your movie. Where can I get a copy? Emule/Bittorrent?
Josh wants to see battle star galactica! 
You can get the 512x512 and 1024x512 movies I used here:
phys.uu.nl/~keek/panda/bsg.tar.gz (~20MB)
They show the first minute (more or less) of the episode. The sound starts with a crackle.