[MPlayer-G2-dev] Darwin port

[D Richard Felker III]

On Thu, May 08, 2003 at 01:51:48AM +0200, Arpi wrote:
> Yes. You can either export your buffers as-is (as pointers and
> bytes-per-line (aka. stride) values), in this case all teh rendering
> will be handled by vf_vo2.c
> Or if your device doesn't have such buffers (special cases, when the
> driver have functions to blit data, but you have no direct access)
> then you can implement draw_slice() (just like in mplayer g1) to blit
> parts of the image.

Arpi, I'm trying to decide how to best implement G200 support in G2.
You're prolly already aware, but just to remind you, G200's "YV12"
mode gives you 4:2:0 semi-planar, with Y in a plane by itself, but U
and V packed together in a w*(h/2) byte buffer. I see a couple
possible ways of handling this:

1) Same as G1: don't allow DR, but use draw_slice instead, and
   interleave slices as they're drawn. Easy, but slow when the last
   filter has to copy to a temp buffer rather than DR.

2) Export DR buffers, but allocate fake U/V planes in system memory.
   Let the codec/filters DR into real Y and fake U/V planes, then
   interleave U/V when put_image is called. This method is nice when
   the codec/filter can DR, but for non-B frames with IP[B] codecs, it
   will result in extra senseless copying from the readable buffer in
   system memory to the fake U/V buffers, then interleaving into the
   real U/V buffer.

3) Have vo_mga report that YV12 is NOT available for G200, and define
   a new image format for this 'semi-planar' mode. Then vf_scale can
   get automatically inserted, and use a super-fast interleave-only
   converter without scaling. With the appropriate enhancements (which
   should be there for planar 4:1:1/4:1:0 modes anyway), vf_scale
   could allow direct rendering straight through it for the Y plane,
   but use its own buffers for U/V which need to be converted. It
   could do a similar trick for slice rendering through scale, and
   likewise by setting up an EXPORT type image when not using DR or
   slices.

Personally, I think option (3) is the cleanest solution, if it can be
done without a performance hit. That way we don't clutter up vf_vo2.c
or vo_mga.c with all sorts of hacks. Maybe you have another better
idea, though?

Rich