Hi Alex, I don't think smpeg, the current movie player, (I think) has
support for mjpeg. Basically the format you are using just isn't
supported.
-Tyler
On Thu, May 7, 2009 at 3:40 PM, Alexandre Quessy <alexandre@xxxxxxxxxx
<mailto:alexandre@xxxxxxxxxx>> wrote:
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 <mailto: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>
>> <mailto: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>>
>> <mailto: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/
--
Visit my blog at http://oddco.ca/zeroth/zblog