Re: MID proposal

D Richard Felker III <[email protected]>
Newsgroups gmane.comp.video.mplayer.g2.devel
Message-ID <[email protected]>
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 <[email protected]>
> > (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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.