Hi Rene, Perhaps. But SDL_ffmpeg is a separate project, another dependency. FFmpeg is much more likely to be on someone's system. SDL_ffmpeg also uses a completely different build system, complicating the process of using it within pygame. I'm having trouble getting it built against ffmpeg 0.5.0 and I can't find any info or instructions on building it. If I'm having trouble, it'll also be difficult for others. Its just not ready for wide-scale usage, in my personal view.
Like I said, I am definitely leaning towards just using ffmpeg directly. It also means I have greater control over whats going on, and don't have to try to fiddle and be stopped by the limitations of sdl_ffmpeg. -Tyler On Thu, May 7, 2009 at 4:33 PM, René Dudfield <ren...@gmail.com> wrote: > 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 >> > > -- Visit my blog at http://oddco.ca/zeroth/zblog
