[MPlayer-G2-dev] MID proposal

D Richard Felker III dalias at aerifal.cx
Sat Nov 1 21:18:42 CET 2003


On Sat, Nov 01, 2003 at 10:03:08PM +0200, Ivan Kalvachev wrote:
> Alex Beregszaszi said:
> > Hi,
> >
> >> > A new idea: the new swscaler should based on a similar structure.
> >>
> >> new swscaler? r u dreaming? :)
> > Yes, else I wouldn't code on opensource projects.
> >
> > --
> > Alex Beregszaszi <alex at fsn.hu>
> > (MPlayer Core Developer -- http://www.mplayerhq.hu/)
> >
> OK, I am constanly pointing the good side of XvImage
> here is the structure, it is quite clear and quite overloaded,
> strip it ;)
> And don't worry, you wont become blind if you see it (once:)

Most MPlayer developers are already quite aware that stories about
going blind from seeing stuff are just myths...

> typedef struct {
>   int id;                      /* Unique descriptor for the format */
>   int type;                    /* XvRGB, XvYUV */
>   int byte_order;              /* LSBFirst, MSBFirst */
>   char guid[16];               /* Globally Unique IDentifier */
>   int bits_per_pixel;
>   int format;                  /* XvPacked, XvPlanar */
>   int num_planes;
> 
>   /* for RGB formats */
>   int depth;
>   unsigned int red_mask;
>   unsigned int green_mask;
>   unsigned int blue_mask;
> 
>   /* for YUV formats */
>   unsigned int y_sample_bits;
>   unsigned int u_sample_bits;
>   unsigned int v_sample_bits;
>   unsigned int horz_y_period;
>   unsigned int horz_u_period;
>   unsigned int horz_v_period;
>   unsigned int vert_y_period;
>   unsigned int vert_u_period;
>   unsigned int vert_v_period;
>   char component_order[32];    /* eg. UYVY */
>   int scanline_order;          /* XvTopToBottom, XvBottomToTop */
> } XvImageFormatValues;
> 
> OK here are my points:
> 1. merge some strucures so we wont' have different structures for
> different formats (yuv,rgb)

Yes, XvImageFormat is very ugly!

> 2. _period and sample_bits could be in array.
> 3. samplebits is good for and e.g. RGB, but we will need and shift bits(e.g.
> BGR565 B<<10 G <5 R<0 and G=g>>(8-samplebits[g_ofs])

Yes, we already know this.. :)

> 4. component_order is nice idea. but donno how nv12 will be described;)
> I had the idea to have recursive modes, but it will be too complicated.

Yes definitely too complicated!
IMO nv12 is handled just like fully planar modes. Default order is
U,V; set the "swapped" flag if it's opposite.

> 5. rgb mask are good to have, some (sdl) releay on them

Useless. You can generate them from sizes/offsets, and SDL sucks. IMO
SDL shouldn't even be supported in G2 since there's no way to support
it correctly, and since MPlayer's native drivers already support a lot
more than SDL anyway.

> 6. as MID will be static we could also add fourcc code, short name, long
> name etc.... All stuff that will be used only once :)

Yes.

Rich



More information about the MPlayer-G2-dev mailing list