[MPlayer-G2-dev] Darwin port

[Ivan Kalvachev]

Would this help
I don't have the g200 spec, but is that mode like that:

YYYYYYYYY
UUUUVVVV


Y_width=width
Y_slice=width*2
Y_offset=0;

U_width=width/2;
U_slice=width*2;
U_offset=width; //start after Y line

V_width=width/2;
V_slice=width*2;
V_offset=width+(width/2);//start after Y and U line


Or it have packed UV in the same word (short)-
YYYYYYYY
UVUVUVUV

Best Regards
 Ivan

D Richard Felker III said:
> 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
>
> _______________________________________________
> MPlayer-G2-dev mailing list
> MPlayer-G2-dev at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev