Re: MID proposal

On Sat, Nov 01, 2003 at 04:38:14PM +0100, Alex Beregszaszi wrote:
> Hi,
> 
> Here's my idea of a IMGFMT replacement: MID stands for MPlayer Image
> Description.

Here's what I have so far:

// MPlayer Imageformat Description

#define MID_TYPE_YUV        1
#define MID_TYPE_RGB        2
#define MID_TYPE_PALETTE    3
#define MID_TYPE_SPECIAL    4

#define MID_FLAG_SWAPPED      0x1

typedef struct mid_s {
        int type;
        int flags;
        int bpp;
	int depth;
        int csh, csv; // chroma shift, horiz. and vert.
        int num_planes; // 0=packed, 1=gray, 2=semiplanar(nv12), 3=full planar
        int chan_bits[4]; // sizes and offsets of channels (in bits). order is:
        int chan_offs[4]; // R,G,B[,A] for RGB; Y1,Y2,U,V for packed YUV
        unsigned int imgfmt; // legacy "fourcc"
        char *name, *longname;
} mid_t;

Some comments:

Q: Why separate type and flags again?
A: if (mid.type==MID_TYPE_YUV) is cleaner than
   if ((mid.flags & MID_FLAG_TYPEMASK) == MID_TYPE_YUV).

Q: Why have flags if there's only one flag?
A: Good question.

Q: Should num_planes really be the determining factor for what type of
   planar arrangement we have? Or should it just tell how many
   pointers in the planes[] array are valid, and should be use flags
   or different basic types for different planar arrangements?
A: I'm not sure. I would consider something like the following but I
   don't know if I like it:

#define MID_YUV_PLANAR     1
#define MID_YUV_PACKED     2
#define MID_YUV_SEMIPLANAR 3
#define MID_RGB            4
#define MID_PALETTE        5
#define MID_SPECIAL        6

Q: Why is palette a type rather than a flag?
A: Type tells the filter what type of data is stored in the buffers
   which planes[] points to. Indexed (palette) images do not have data
   that can be treated as meaningful colors (RGB or YUV) here, so IMO
   it's a different type in itself. Also it doesn't make sense to
   consider indexed images as YUV or RGB in nature, since the
   colorspace is a property of the palette, not the data itself (in
   fact you can convert the colorspace of the palette at essentially
   no cost!).

Q: What is the "special" type?
A: Anything other than a standard-format YUV, RGB, or indexed image.
   Some examples are compressed images (for hardware decoder boards)
   and dct/mv data for xvmc. Normally filters will reject special type
   images.

Q: Doesn't storing arbitrary channel layout (chan_bits/chan_offs)
   force filters to handle any strange format and thus be slow?
A: No. In fact only standard formats should be supported. This data is
   just here for filters which are written in C, and don't want to
   special case 555/565 or RGB/BGR, but instead use the same generic
   code for all cases. The same information in chan_bits/chan_offs is
   already available via depth, bpp, and the status of the swapped
   flag.

Rich