Hi ! Supporting only MPEG and AVI ? Well, first of all, MPEG can be either a codec or a container, whereas AVI is a container that can contain many different codecs. This said, I guess "MPEG" here refers to the MPEG container. In this container, there can be MPEG-2, which is a video codec.
My two cents : I would recommend supporting also the Motion-JPEG codec. It is faster to decode in realtime than MPEG-family time-based codecs. For a game, a developer would most likely either : 1) play a movie as a transition betwen game levels. MPEG-2, H.263 or H.264 would be best suited for this. 2) play different frames from a movie to make a character or landscape change over time. Motion-JPEG or Motion-PNG are best for this, since their compression is not time-based, it is faster to decode when reading random-access frames. Hence, in the case #2, motion-JPEG is pretty handy. The picture would also look a lot better than with a time-based compression. I think there is also a motion-PNG codec, which supports a transparency channel. The Animation codec is a lossless codec from Apple that also supports a transparency channel. It would nice to have it too. I guess ffmpeg supports them all. Ciao, 2009/5/8 Tyler Laing <trinio...@gmail.com>: > Another significant difference I just found is that SDL_ffmpeg has no > support for subtitle streams. Supporting subtitle streams is smart, it > allows for it to be easier to internationalize games by having the game > select the subtitle stream it wants to play. Plus, I like my cutscenes to > have subtitles in english, as I'm hard of hearing. :) > > -Tyler > > On Thu, May 7, 2009 at 4:59 PM, Tyler Laing <trinio...@gmail.com> wrote: >> >> 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 > > > > -- > Visit my blog at http://oddco.ca/zeroth/zblog > -- Alexandre Quessy http://alexandre.quessy.net/
