Re: Double Buffered display vs Overlays

On Saturday 17 September 2005 06:49, Pete Shinners wrote:
> On Fri, 2005-09-16 at 20:29 +0100, Michael Sparks wrote:
> > Out of interest can a movie object take raw YUV frames in the same sort
> > of way the Overlay buffer can?
>
> Pygame has an Overlay class, but it's a but experimental. 

I suppose I wasn't clear enough. We are using Pygame overlays, and finding it 
works very nicely for playback of video, even on unaccelerated displays. If 
that's all you want it's fine :-)

You can dump raw YUV data into it and it works very nicely. It does however 
have 2 minor issues as far as we're concerned:

  1. If you draw surfaces over vdeo overlay, the display flickers. The
     overlay is drawn & rendered, then anything you draw is rendered over it.
     This process is visible, and hence flickers if you render surfaces over
     video in an overlay. (If the surfaces & video overlap, but the video is
     in front, this doesn't flicker)

     If this sort of thing simply hasn't had much exercise, no problem, I'll
     dig around and see if overlays can be rendered off screen. (There seem
     to be a few options in SDL that aren't in the pygame interface)

     I tried seeing if setting the display double buffered would automagically
     solve the problem, but unfortunately that doesn't  work. (hence the
     subject line :)

   2. This doesn't appear to be a pygame issue, but rather SDL but probably
     worth knowing about. Essentially for overlays to display correctly across
     all X versions (that we've tried) your overlay leads to be 2 pixels
     narrower than your video frames (or multiples of two). eg video 352*288
     on an overlay 352*288 displays corrupt on *some* X displays, but if the
     overlay is 350 then it always displays correctly. 

     NB, because the obvious thing (352 width for 352 width video) works with
     some hardware/X combos and not others we view that as an SDL/X issue not
     a pygame issue, so I'm just mentioning for people in case they think
     pygame is bust when it might not be.

Incidentally we're not using pymedia for decode, but rather some python 
bindings we've created for our Dirac codec (dirac.sourceforge.net). Those 
bindings naturally spit out decode YUV data - much like any other codec.So 
that's why we started looking at pygame overlays.

Anyway, that was why I was asking whether anyone knew whether pygame.movie
can take raw YUV data. If no-one's tried/knows I'll play around and report
back, but any gotchas would be nice to hear if anyone has any :-)

The alternative of course is to try and get SDL overlays to target an
offscreen surface, which might be a pipedream (since it seems a
contradiction in terms), but might be useful. (Especially given it sounds
like that's how smpeg works behind the scenes)

Best Regards and thanks,


Michael.