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

Re: [pygame] SDL_ffmpeg vs ffmpeg



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