[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] SDL_ffmpeg vs ffmpeg



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>> 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