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 <trinioler@xxxxxxxxx>: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 <trinioler@xxxxxxxxx> 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 <renesd@xxxxxxxxx> 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 <trinioler@xxxxxxxxx> 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