That bug is supposed to be fixed in pygame, so if it's in SDL, great, but I saw it in the pygame changelog I thought.
Hmm, perhaps you are right. In any case it seems to be ok now. :)
Ok, so after Thomas asked me if we needed ffmpeg for anything else in the runtime, which we don't, I reverted to the same ffmpeg used in the previous runtime and the DXR3 patch compiled into SDL CVS with no problems. So, I guess the show is back on.
Uhm... mplayer uses ffmpeg, so reverting isn't such a good idea,
especially since the latest versions have a native sorenson SVQ3
decoder.
The mplayer in the runtime is staticly linked so this isn't a problem (as long as I link it to the CVS ffmpeg, which I do). Plus mplayer builds libavcodec inside its own directory structure.
-Mplayer audio and the audio playing freevo screen. Freevo needs to be updated for the new mplayer track times (mm:ss) and should probably support both old and new.
This is still a problem.
I say release this runtime with the old behaviour, and we'll modify freevo when the next major release comes out. I'd rather people be able to test 'pre' versions without having to rebuild all their apps and I don't think it's worthwhile for the minority of people who use the mplayer cvs to change the code yet.
Can't we support both? That way it won't matter which mplayer people use and we could remove the old behaviour from Freevo once there is a new release of mplayer.
-Rob
------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
