[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] SDL_ffmpeg vs ffmpeg
Hi all !
I am trying to test the ffmpeg player with pygame on Ubuntu.
$ python examples/movieplayer.py ~/clip_0.mov
I get "pygame.error: Could not find the beginning of MPEG data"
...since I am using Motion-JPEG saved exporting pygame surfaces as
JPEG images, and using mencoder to encode JPEG files to a motion-JPEG
movie in the Quicktime container. See
http://code.google.com/p/toonloop/source/browse/trunk/py/toon/mencoder.py
for movie conversion.
How can I specify the codec to motion-JPEG ?
Next, it would be nice to have a PyOpenGL demo. Should be pretty
straightforward to write.
My two cents : YUV seem faster for OpenGL texture uploads. Converting
to RGB should be an option. Hence, maybe it is better to wrap the
ffmpeg library rather than the SDL_ffmpeg.
a
2009/5/7 Lenard Lindstrom <len-l@xxxxxxxxx>:
> Sorry, I don't know how to synch up sound and image. Pyame uses SDL_mixer,
> which is a wrapper for sound support in SDL. I suppose smpeg takes care of
> sound internally. And one has to be careful using SDL directly if SDL_mixer
> is used. But I am unsure of the details. It may just be a matter of not
> directly initializing sound support in SDL if using SDL_mixer.
>
> Lenard
>
> Tyler Laing wrote:
>>
>> Lenard,
>>
>> Thanks for the advice and info. :) It looks like by default the pygame
>> surfaces don't support YUV, but overlays do. The simple case will use the
>> overlay module, via c, to play the movie. This is more than suitable for 90%
>> of usecases, and will be transparent to most people. It also benefits from
>> hardware acceleration.
>>
>> For the other 10% of stuff that people want to do, it looks like a bit of
>> a tougher technical challenge. I like Rene's idea of separate and
>> manipulatable streams, which allows for some neat stuff to be done. If I use
>> the ffmpeg api directly, then I am able to do this. Via ffmovie or ffplay,
>> it is not possible. Do you have any information for how to do sound, any
>> reccomendations on where to look? I'm already beginning to look at mixer.c
>> for how it is done, via SDL.
>>
>> -Tyler
>>
>> On Thu, May 7, 2009 at 10:20 AM, Lenard Lindstrom <len-l@xxxxxxxxx
>> <mailto:len-l@xxxxxxxxx>> wrote:
>>
>> I have built the movie module for both Windows and Linux. It is
>> included in the Windows distribution. movieext.c was a first
>> attempt at using SDL_ffmpeg. I don't know about sdl surfaces and
>> YUV, but the overlay.py example program does try to play a movie
>> using YUV. Unfortunately it rejects the only pgm file in the
>> examples/data directory so I have not gotten it to work. I only
>> know about overlay because I have recently updated the module to
>> Python 3. So I don't know if it will be of any help.
>>
>> Lenard
>>
>> Tyler Laing wrote:
>>
>> Hi Lenard,
>>
>> I'm looking at the movie module now. Are we compiling movie.c
>> or movieext.c? I didn't think of the overlay module, I'll look
>> at that as well, thanks. :) So thats a no, on sdl surfaces
>> being able to playback YUV?
>>
>> And yes, it looks like smpeg does a direct copy to display.
>>
>> On Thu, May 7, 2009 at 9:36 AM, Lenard Lindstrom
>> <len-l@xxxxxxxxx <mailto:len-l@xxxxxxxxx>
>> <mailto:len-l@xxxxxxxxx <mailto:len-l@xxxxxxxxx>>> wrote:
>>
>> Hi Tyler,
>>
>> My opinion is the few dependencies the better. If
>> SDL_ffmpeg can
>> be left out that would be good. As for YUV playback have
>> you had a
>> look at the overlay module? It may be what is needed. Also, did
>> you look at the existing movie module? Maybe smpeg does direct
>> copy to display so it may not be a useful source of ideas
>> in this
>> case.
>>
>> Lenard
>>
>>
>>
>> Tyler Laing 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/