Alexandre, I'm sorry, I think I may have across as a bit insensitive as well.
As to shipping , Lenard, Rene, and anyone else that is concerned, I was considering that ffplay could be distributed as a statically built executable, so the movie module can, in the worst case scenario, fall back on a working movie player that it knows about, and exactly where it is located. This lessens the need for the user to have vlc, mplayer, or any other video player installed. -Tyler On Tue, May 12, 2009 at 8:44 AM, Lenard Lindstrom <le...@telus.net> wrote: > Hi Alexandre, > > Sorry if I came across a little insensitive on the matter of movie > encoding. As you can tell I'm not very knowledgeable on video encoding. No > one is suggesting Pygame shouldn't support motion-jpeg. Apparently smpeg, > upon which the existing movie module is based, doesn't. The existing module > has problems, not showing an image on XP is one I've recently encountered. > That is why Tyler writing a replacement module using ffmpeg. If ffmpeg > supports Motion-JPEG, then great. > > The thing is the popular ffmpeg binaries for Windows are unsuitable for use > with Pygame. All third party packages used by Pygame on Windows are custom > built for Pygame and distributed with it. The list is long enough already, > and ffmpeg will add to it. If Motion-JPEG requires a separately built > library, another dependency, then there will need to be general support from > Pygame users before it is added to Windows. Of course if you are committed > to seeing general Motion-JPEG support in Pygame there are ways you can help. > Make a short test video available in the desired format. I can check if my > experimental ffmpeg build will accept it. If not then the appropriate > support libraries must be identified and built. Providing links to enabling > Motion-JPEG support in ffmpeg would speed the process. If you are competent > in building libraries with C and MSYS then you can try building ffmpeg > yourself and post the build instructions. I will use them for Pygame. Note > that MSYS 1.0.11 will be needed. But of course ffmpeg distributions for > other operating systems must be considered as well. > > Lenard > > > > Alexandre Quessy 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 >>> >>> >>> >> >> >> >> >> > > -- Visit my blog at http://oddco.ca/zeroth/zblog
