On Tue, May 12, 2009 at 8:44 AM, Lenard Lindstrom
<len-l@xxxxxxxxx> 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 <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