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 <le...@telus.net> 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 <le...@telus.net<mailto:
>> le...@telus.net>> 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

Reply via email to