[MPlayer-G2-dev] vp layer and config

[Michael Niedermayer]

Hi

On Monday 15 December 2003 11:49, D Richard Felker III wrote:
> On Mon, Dec 15, 2003 at 10:13:02AM +0100, Arpi wrote:
> > - split mp_image to colorspace descriptor (see thread on this list)
> >   and buffer descriptor (stride, pointers), maybe a 3rd part containing
> >   frame descriptor (frame/field flags, timestamp, etc so info related to
> >   the visual content of the image, not the phisical buffer itself, so
> >   linear converters (colorspace conf, scale, expand etc) could simply
> >   passthru this info and change buffer desc only)
>
> I've been working on implementing this, but there's one element of
> mp_image_t I'm not sure where to put. Actually this has been bothering
> me for a while now. The exported quant_store (qscale). In G1 the
> pointer just gets copied when passing it on through filters, but this
> is probably between mildly and seriously incorrect, especially with
> out-of-order rendering.
>
> IMO storing quant table in the framedesc isn't a good idea, since
> quantizers are only valid for the original buffer arrangement.
> Actually, I tend to think they belong in the buffer descriptor, almost
> like a fourth plane. But who should be responsible for allocating and
> freeing the quant plane? IMO the only way it can really work properly
> is to have the same code that allocates the ordinary planes be
> responsible for the quant plane too..
btw, we could also pass other stuff like motion vectors around, these maybe 
usefull for fast transcoding

>
> This would mean:
>
> When exporting buffers, you just set quant to point at whatever you
> like (as long as it won't be destroyed until the buffer is released).
>
> When using automatic buffers, the vp layer would allocate quant plane
> for you (but how does it know the right size?) and you have to fill it
> (or else don't mark it as valid).
>
> When using direct rendering, the target filter has to allocate the
> quant plane (again, how does it determine the size?).
the quant plane is always (width+15)/16 x (height+15)/16 big, but we could use 
something like

enum PlaneType{
    Y_PLANE,
    CB_PLANE,
    CR_PLANE,
    ALPHA_PLANE,
    QUANT_PLANE,
    FORWARD_MOTION_PLANE,
    BACKWARD_MOTION_PLANE,
}
struct PlaneDescriptor{
    int bpp;  //bits per pixel (32bit for 2x16bit motion vectors)
    int log2_subsample[2]; // like chroma_w/h_shift
    int offset[2]; //x/y offsets of the 0,0 sample relative to the luma plane 
in 1/2 sample precission
}

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en