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