Re: MID proposal

On Sat, Nov 01, 2003 at 08:33:43PM +0100, Alex Beregszaszi wrote:
> Hi,
> 
> here comes v2 :)

Alex says write my thoughts to the list, so..

> MPlayer Image Description
> -----------------------------------
> 
> Flags: YUV, RGB, SWAPPED, PALETTE, COMPRESSED, SPECIAL (is this really
> needed?!)
> BPP: bytes (bits?) needed for storing a pixel
> Depth: bits used for a pixel
> CSH: horizontal chroma shift (only used if YUV)
> CSV: vertical chroma shift (only used if YUV)
> Num Planes: 1 for packed, 2 (for y + interleaved uv (NV21/12)), 3, 4
> (for IF04 and maybe later yuv+alpha?)
> Imgfmt: backward compatibility fourcc?!

Agree!

> Btw, imho we need a separate data block for storing palette in mpi (we
> should avoid that planes[1] hack) and also a palette_type or
> palette_bits (currently mplayer treats all palettes as 8->24 bits)

Agree, YUV palettes should also be possible.

> Hm, one new issue come to my mind: ARGB vs RGBA, aka the place of alpha
> byte. I hate these endianess issues :)

A is idiotic, there is no alpha. Just say RGB or BGR with no A.

>From vp.h:

// MPlayer Imageformat Description

#define MID_FLAG_YUV        0x01
#define MID_FLAG_RGB        0x02
#define MID_FLAG_SPECIAL    0x04
#define MID_FLAG_SWAPPED    0x10
#define MID_FLAG_PALETTE    0x20

typedef struct mid_s {
        int flags;
        int bpp;
        int csh, csv; // chroma shift, horiz. and vert.
        int num_planes; // 0=packed, 1=gray, 2=semiplanar(nv12),
        3=full planar
        unsigned int imgfmt; // legacy
        char *name, *longname;
} mid_t;

IMO we still need a way of telling where the channels are stored in
packed modes, especially RGB (list of bit sizes and bit offsets).

Rich