I've said it before, whatever codecs and decoders that ffmpeg supports, would be supported. I am not doing format support. ;) So its a fruitless discussion, sorry. I know you really want mjpeg support, but that is not my area of responsibility, expertise, or inclination. Check and see if ffmpeg supports it.
-Tyler On Sun, May 10, 2009 at 10:07 AM, Alexandre Quessy <alexan...@quessy.net>wrote: > 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/ > -- Visit my blog at http://oddco.ca/zeroth/zblog
