Hi, I think you will end up re implementing many of the things from SDL_ffpmeg anyway.
Overlay is pretty good - and is designed for movie playback. However it has limitations. The C docs are here: http://sdl.beuc.net/sdl.wiki/SDL_Overlay It's probably a good idea to get basic playback working first, and then worry about other features. SDL_ffmpeg has most of what is needed to remake the current Movie module using ffmpeg. cu, On Fri, May 8, 2009 at 2:27 AM, Tyler Laing <trinio...@gmail.com> wrote: > Hello all, > > I've been looking at SDL_ffmpeg and ffmpeg. > > There are some considerations for choosing each. SDL_ffmpeg is fairly > simple to interact with, load, play, pause a movie. You can interact with > each frame, and so on. However, SDL_ffmpeg converts every frame from YUV to > RGB, to make it easier on the programmers to use image manipulation > functions and so on. This is a performance hit, for sure. Considering > Python's reputation already for being slow, having a movie module take that > kind of hit will result in a further stain to the reputation, when > sometimes, rarely, movies stutter or pause when they shouldn't. It can take > a long time to recover from a negative reputation. > > For ffmpeg, it offers much the same capability, but without the SDL > conveniences. It does offer far more capability with movie files than > SDL_ffmpeg does though. I think, but I'm not sure, that the pygame surfaces > do not need to have the frames of the movie be in YUV format? Or its a quick > operation to convert the surface for YUV then back to RGB. Something like > that, correct me if I'm wrong. So we don't need every frame to be converted > to RGB, except when we do need it. > > If I went with ffmpeg, I was considering a design where we explicitly > convert the movie from YUV to RGB, with a simple convert function. From the > point its called, to the point it is called again, the movie is in RGB > format. It fits with the python philosophy that "Explicit is better than > implicit." (-The Zen of Python, by Tim Peters) > > Personally, I would prefer to work with ffmpeg, because of the greater > functionality, and the lack of conversion performance hit. > > -Tyler > > -- > Visit my blog at http://oddco.ca/zeroth/zblog >
