G200+NV12 (Re: [MPlayer-G2-dev] Darwin port)
Arpi
arpi at thot.banki.hu
Fri May 9 01:32:22 CEST 2003
Hi,
> 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?
No, 3) is the best (and only acceptable, imho) solution.
As you wrote, it will try to get DR (get_image()) buffers, then passthru
Y buffer for the upper level (prev. filters/codec) while doing per-slice
(using draw_slice()) for UV conversion.
Actaully it's possible in g1 too, but in g1 DR and slices are mutually
exclusive, you can't do both at the same time. In g2 you can.
(so even if you do DR, unless you mask out DRAW_CALBACKS flag, your
draw_slice also will be called - note this feature is not yet well tested
(nothing supports/use it yet), but in theory it's supoprted and should work)
Btw Vektor mentioned scanline buffers yesterday, and I think it's a very
interesting approach. ie. replace plane+stride with array of scanline
pointers :)
It would allow very amazing optimizations, like DR scanlines without OSD,
and copy the rest. But I guess such feature won't go into g2 soon, maybe
into g3, or in g2 v2.0 :))
A'rpi / Astral & ESP-team
--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
More information about the MPlayer-G2-dev
mailing list