Hi, Here's my idea of a IMGFMT replacement: MID stands for MPlayer Image Description. MID { imgfmt (?) type (rgb or yuv) bpp depth chroma_x_shift chroma_y_shift num_planes (>1 -> planar) fields (interlacing) } MPI { mid flags type width, height x,y,w,h planes stride ... } The advantage of this is that it would be safe to change query_format to the following: query_format(vo_instance, mid, width, height) and other apperances of complicated imgfmt usage, it would reduce code. -- Alex Beregszaszi <alex@fsn.hu> (MPlayer Core Developer -- http://www.mplayerhq.hu/)
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.
MID { imgfmt (?) type (rgb or yuv) bpp depth chroma_x_shift chroma_y_shift num_planes (>1 -> planar) fields (interlacing) }
MPI { mid flags type width, height x,y,w,h planes stride ... }
The advantage of this is that it would be safe to change query_format to the following: query_format(vo_instance, mid, width, height) and other apperances of complicated imgfmt usage, it would reduce code.
I agree something like this is _definitely_ desirable. Having a switch statement in query_format where you have to list every single planar format is idiotic... As for the specifics, I'm not sure it's complete. IMO there should more than just num_planes, but a way to specify packed(yuy2)/planar(yv12)/semiplanar(nv12)... Maybe 1/3/2 planes is a suitable way to identify this...? From my perspective, the main info filters need is just the type of planar layout; beyond that, most filter's don't care about the specifics. Rich
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.
Some more questions...
MID { imgfmt (?)
Rename to fourcc.
type (rgb or yuv)
Rename to colorspace or something.
bpp depth
What is the point of depth? How is it defined?
chroma_x_shift chroma_y_shift
I always found these names excessively verbose to type when writing filters. Any better ideas?
num_planes (>1 -> planar)
See my other mail.
fields (interlacing)
Hm? Does this just tell if the image is interlaced, or does it contain other flags about the interlacing format?
}
MPI { mid flags type width, height x,y,w,h
The whole width, height, x, y, w, h system is nonsense. x,y are never used and not even supported. They're much better handled by just adjusting the actual pointers. Also lots of filters don't understand the difference between w and width, which is very silly to begin with. In the new vp code I'm working on, width/height/x/y are entirely eliminated, and the stride restrictions are cleaned up a lot. There's now: #define VP_STRIDE_MB_ALIGNED 0x1 // stride%(16*bpp) == 0 #define VP_STRIDE_PIXEL_ALIGNED 0x2 // stride%bpp == 0 #define VP_STRIDE_EXACT_WIDTH 0x4 // stride==bpp*w #define VP_STRIDE_COMMON 0x8 // stride[1,2]==stride[0]>>shift Codecs which wanted MP_IMGFLAG_ACCEPT_WIDTH before can now just use VP_STRIDE_PIXEL_ALIGNED and stride/bpp will be the old width field. (Note for simplicity here I use bpp=bytes/pixel, even though it really means bits... :) Rich
Hi,
MID { imgfmt (?)
Rename to fourcc. Why?
We could create a new list of format fourccs which could indicate only one format described by MID, but the imgfmt is the ancient fourcc.
type (rgb or yuv)
Rename to colorspace or something. See the mail from Arpi.
bpp depth
What is the point of depth? How is it defined? Depth is the number of bits used for describe a pixel, bpp means the bytes which are used to store a pixel. RGB24 has depth=24 but can have both bpp=24 and bpp=32.
chroma_x_shift chroma_y_shift
I always found these names excessively verbose to type when writing filters. Any better ideas? See my other mail (cr_h/v)
fields (interlacing)
Hm? Does this just tell if the image is interlaced, or does it contain other flags about the interlacing format? If we leave it in MID it could contain more flags. Dunno if it should be present or not.
[snip]
The whole width, height, x, y, w, h system is nonsense. x,y are never used and not even supported. They're much better handled by just adjusting the actual pointers. Also lots of filters don't understand the difference between w and width, which is very silly to begin with. Imho it has sense, but lot of filter/vo writers are dumb and can't make difference.
Width/height defines the dimensions of the whole image pointed by MPI. x,y,w,h descibre a rectangle of which part of the image should be drawn. Yes, there are two ways: only pass a MPI with the actual image, but that would still need x,y to be defined to place it correctly on the screen. The other way is to leave our current scheme and fix the filters. Imho this is a better approach. Probably you will ask about the sense of this whole partial mpi stuff: it has not much sense currently, but we could have some filters/decoders which will support partial decoding / filtering. -- Alex Beregszaszi <alex@fsn.hu> (MPlayer Core Developer -- http://www.mplayerhq.hu/)
On Sat, Nov 01, 2003 at 08:14:21PM +0100, Alex Beregszaszi wrote:
Hi,
MID { imgfmt (?)
Rename to fourcc. Why?
We could create a new list of format fourccs which could indicate only one format described by MID, but the imgfmt is the ancient fourcc.
type (rgb or yuv)
Rename to colorspace or something. See the mail from Arpi.
bpp depth
What is the point of depth? How is it defined? Depth is the number of bits used for describe a pixel, bpp means the bytes which are used to store a pixel. RGB24 has depth=24 but can have both bpp=24 and bpp=32.
I know that much. But how is depth defined for YUV? Is there even any point of knowing the depth..?
fields (interlacing)
Hm? Does this just tell if the image is interlaced, or does it contain other flags about the interlacing format? If we leave it in MID it could contain more flags. Dunno if it should be present or not.
IMO not. Info about interlacing does definitely belong in the video pipeline, BUT most of the time it wouldn't even be known yet when you're using MIDs, and like Arpi said MIDs should come from a table of constants.
The whole width, height, x, y, w, h system is nonsense. x,y are never used and not even supported. They're much better handled by just adjusting the actual pointers. Also lots of filters don't understand the difference between w and width, which is very silly to begin with. Imho it has sense, but lot of filter/vo writers are dumb and can't make difference.
Width/height defines the dimensions of the whole image pointed by MPI. x,y,w,h descibre a rectangle of which part of the image should be drawn.
But that's not how it is right now. As it stands, width is essentially the same thing as stride/bpp, which filters should not even care about.
Yes, there are two ways: only pass a MPI with the actual image, but that would still need x,y to be defined to place it correctly on the screen. The other way is to leave our current scheme and fix the filters. Imho this is a better approach.
Probably you will ask about the sense of this whole partial mpi stuff: it has not much sense currently, but we could have some filters/decoders which will support partial decoding / filtering.
This is NOT a clean way to do it. It's very limited (forces you to only have one rectangle) and also forces all filters to support this bloated ugliness of working on partial images explicitly. I have a much better design for new vp layer: Let's say you want to blur a small rectangle of your picture. Here's how the filter chain works: vd ----> vf_subfilter ----> vo | ^ | | V | vf_blur vf_subfilter would pull an image from vd, then pull an image from vf_blur, which would in turn pull from vf_subfilter, getting only the small part of the image it was supposed to work on. The blurred image would be returned to vf_subfilter, and then vf_subfilter would finish things up and return the final image to vo. Of course direct rendering and/or exporting would happen all over the place, so it would be very fast. Anyway, IMO the x,y stuff is not acceptable. It's too much of a burden to ask every single filter to know how to process partial images by itself, and there's no advantage. Rich
Hi,
What is the point of depth? How is it defined? Depth is the number of bits used for describe a pixel, bpp means the bytes which are used to store a pixel. RGB24 has depth=24 but can have both bpp=24 and bpp=32.
I know that much. But how is depth defined for YUV? Is there even any point of knowing the depth..? For YUV you must round down depth, but imho it has not much sense to speak about depth in case of YUV. Depth field is only usable for RGB
colorspace so we wouldn't need those IMGFMT_RGB/BGR_DEPTH macros.
IMO not. Info about interlacing does definitely belong in the video pipeline, BUT most of the time it wouldn't even be known yet when you're using MIDs, and like Arpi said MIDs should come from a table of constants. Let's drop this field for now.
[snip]
Anyway, IMO the x,y stuff is not acceptable. It's too much of a burden to ask every single filter to know how to process partial images by itself, and there's no advantage. Your mechanism is interesting, and yes, it's up to you if you drop these fields or not. Note: I only copied MPI from the current headers. If we all agree on a MID definition, we can work on a new MPI using MID.
-- Alex Beregszaszi <alex@fsn.hu> (MPlayer Core Developer -- http://www.mplayerhq.hu/)
Hi,
What is the point of depth? How is it defined? Depth is the number of bits used for describe a pixel, bpp means the bytes which are used to store a pixel. RGB24 has depth=24 but can have both bpp=24 and bpp=32.
I know that much. But how is depth defined for YUV? Is there even any point of knowing the depth..?
for planar formats, it should be component depth, imho ie. 8 for most YUV formats, even NV12 mayeb we should add 'component' field too it could help for nv12 (comp=3 planes=2), rgb vs rgba (comp=4) etc
fields (interlacing)
Hm? Does this just tell if the image is interlaced, or does it contain other flags about the interlacing format? If we leave it in MID it could contain more flags. Dunno if it should be present or not.
IMO not. Info about interlacing does definitely belong in the video pipeline, BUT most of the time it wouldn't even be known yet when you're using MIDs, and like Arpi said MIDs should come from a table of constants.
yes. MID shouldnt contani variables at all. every single field in MID struct must be constant for a given imgfmt
The whole width, height, x, y, w, h system is nonsense. x,y are never used and not even supported. They're much better handled by just adjusting the actual pointers. Also lots of filters don't understand the difference between w and width, which is very silly to begin with. Imho it has sense, but lot of filter/vo writers are dumb and can't make difference.
Width/height defines the dimensions of the whole image pointed by MPI. x,y,w,h descibre a rectangle of which part of the image should be drawn.
But that's not how it is right now. As it stands, width is essentially the same thing as stride/bpp, which filters should not even care about.
yes
Yes, there are two ways: only pass a MPI with the actual image, but that would still need x,y to be defined to place it correctly on the screen. The other way is to leave our current scheme and fix the filters. Imho this is a better approach.
Probably you will ask about the sense of this whole partial mpi stuff: it has not much sense currently, but we could have some filters/decoders which will support partial decoding / filtering.
This is NOT a clean way to do it. It's very limited (forces you to only have one rectangle) and also forces all filters to support this
agree. x,y must go, it's unused in g1 too in my original plans (for g1's vf) it was for crop/expand stuff, i wanted to implement crop/expand by just changing those fields... was bad idea
bloated ugliness of working on partial images explicitly. I have a
sure. we need well working slices, with x and w parameters (not y-only as in g1)
much better design for new vp layer:
Let's say you want to blur a small rectangle of your picture. Here's how the filter chain works:
vd ----> vf_subfilter ----> vo | ^ | | V | vf_blur
huh A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
On Sat, Nov 01, 2003 at 11:50:06PM +0100, Arpi wrote:
Probably you will ask about the sense of this whole partial mpi stuff: it has not much sense currently, but we could have some filters/decoders which will support partial decoding / filtering.
This is NOT a clean way to do it. It's very limited (forces you to only have one rectangle) and also forces all filters to support this
agree. x,y must go, it's unused in g1 too in my original plans (for g1's vf) it was for crop/expand stuff, i wanted to implement crop/expand by just changing those fields... was bad idea
bloated ugliness of working on partial images explicitly. I have a
sure. we need well working slices, with x and w parameters (not y-only as in g1)
Yes, perhaps. I don't see how slices will help performance much if you do them in a strange order tho. Anyway slices aren't really related to this mess in mp_image.
much better design for new vp layer:
Let's say you want to blur a small rectangle of your picture. Here's how the filter chain works:
vd ----> vf_subfilter ----> vo | ^ | | V | vf_blur
huh
Just a cool example of nonlinear filter chains. The (hypothetical) vf_subfilter attaches an entire chain to itself at both ends to allow you to apply filters to just a part of an image. Rich
Hi,
Here's my idea of a IMGFMT replacement: MID stands for MPlayer Image Description.
MID { imgfmt (?) type (rgb or yuv) or special: mpeg, mjpeg, cymk etc
bpp depth chroma_x_shift chroma_y_shift num_planes (>1 -> planar)
imho: 0 -> packed
=1 -> planar (think of grayscale)
fields (interlacing)
why here? whats the purpose of it? btw the definitions of MID should be constant, from a big table also used for config layer's TYPE_IMGFMT and so on.
MPI { mid flags type width, height x,y,w,h planes stride ... }
The advantage of this is that it would be safe to change query_format to the following: query_format(vo_instance, mid, width, height) and other apperances of complicated imgfmt usage, it would reduce code.
agree, i also had this in mind, but i dropped due to big changes all over the code (i wanted to avoid big changes which delay g2 a lot) A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
On Sat, Nov 01, 2003 at 07:33:13PM +0100, Arpi wrote:
Hi,
Here's my idea of a IMGFMT replacement: MID stands for MPlayer Image Description.
MID { imgfmt (?) type (rgb or yuv) or special: mpeg, mjpeg, cymk etc
Hmm..what do you mean? Maybe type (colorspace) should be able to take on 3 values (and more in the future if needed): RGB, YUV, and "SPECIAL". Filters then could reject "SPECIAL" type outright unless they recognize the imgfmt.
imho: 0 -> packed
=1 -> planar (think of grayscale)
Agree.
fields (interlacing)
why here? whats the purpose of it?
I agree it doesn't belong.
The advantage of this is that it would be safe to change query_format to the following: query_format(vo_instance, mid, width, height) and other apperances of complicated imgfmt usage, it would reduce code.
agree, i also had this in mind, but i dropped due to big changes all over the code (i wanted to avoid big changes which delay g2 a lot)
Porting filters will require changes anyway. I volunteer to do most of it once I'm done with vp layer. Rich
Hi,
MID { imgfmt (?) type (rgb or yuv) or special: mpeg, mjpeg, cymk etc Let's see the actual cases: 0: yuv 1: rgb 2: mpeg 3: mjpeg further types (cmyk :D)
Or what about adding a 'compressed' type that would indicate mpeg1/mjpeg/mpeg4/asv2 (you know, asus cards can en/decode asv) and others.
chroma_x_shift chroma_y_shift What about naming them cr_h/v (chroma horizontal / vertical)
num_planes (>1 -> planar)
imho: 0 -> packed
=1 -> planar (think of grayscale) Or the flags field from mpi: (i forgot it first :) MPI_IMGFLAG_PLANAR, YUV, SWAPPED, RGB_PALETTE
fields (interlacing) why here? whats the purpose of it?
Or what about merging flags with type? probably it has not much sense (i can see only one, if you read the thread about jpeg_enc)
agree, i also had this in mind, but i dropped due to big changes all over the code (i wanted to avoid big changes which delay g2 a lot) but without big changes it will become the same bloat as g1 after some time
A new idea: the new swscaler should based on a similar structure. And also we could make a mid_to_imgfmt function, so we could really get rid of internal imgfmt usage, only some filters/modules/whatever which need to convert to the ancient format could use it. -- Alex Beregszaszi <alex@fsn.hu> (MPlayer Core Developer -- http://www.mplayerhq.hu/)
Hi,
MID { imgfmt (?) type (rgb or yuv) or special: mpeg, mjpeg, cymk etc Let's see the actual cases: 0: yuv 1: rgb 2: mpeg 3: mjpeg further types (cmyk :D)
Or what about adding a 'compressed' type that would indicate mpeg1/mjpeg/mpeg4/asv2 (you know, asus cards can en/decode asv) and others.
i vote for yuv, rgb, special or maybe yuv, rgb, special, compressed so uncompressed but non-rgb non-yuv could go to special
chroma_x_shift chroma_y_shift What about naming them cr_h/v (chroma horizontal / vertical)
or csv/csh (ala scale filter's shift params)
num_planes (>1 -> planar)
imho: 0 -> packed
=1 -> planar (think of grayscale) Or the flags field from mpi: (i forgot it first :) MPI_IMGFLAG_PLANAR, YUV, SWAPPED, RGB_PALETTE
we still need a plane number
Or what about merging flags with type?
yes, it would be the best!!
fields (interlacing) why here? whats the purpose of it? probably it has not much sense (i can see only one, if you read the thread about jpeg_enc) i didnt read that yet
agree, i also had this in mind, but i dropped due to big changes all over the code (i wanted to avoid big changes which delay g2 a lot) but without big changes it will become the same bloat as g1 after some time
A new idea: the new swscaler should based on a similar structure.
new swscaler? r u dreaming? :)
And also we could make a mid_to_imgfmt function, so we could really get rid of internal imgfmt usage, only some filters/modules/whatever which need to convert to the ancient format could use it.
dunno as Rich said, if it's well done, we dont need imgfmt anymore btw, what about adding short name and longer description too? for config_type_imgfmt and various debug/nondebug printfs... A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
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@fsn.hu> (MPlayer Core Developer -- http://www.mplayerhq.hu/)
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@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:) 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) 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]) 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. 5. rgb mask are good to have, some (sdl) releay on them 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 :) Best Regards Ivan Kalvachev iive
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@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
D Richard Felker III said:
On Sat, Nov 01, 2003 at 10:03:08PM +0200, Ivan Kalvachev wrote:
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 { [snip] } 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. Ok i got another idea, just in for the protocol, probably it is too complicated to be used for something else than learning formats. The basic is that in the plane cannot have another plane format, so it can be only packed format.
e.g. for some imagine format we have num_planes=3 plane 0 (bytes) - Y(bits=8, shift=0) plane 1 (words) - U (bits=3, shift=5), V(bits=3, shift=2), None(bits=2,shift=0) plane 1 (bytes) - A (bits=8,shift=0)
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.
Agree. Best Regards Ivan Kalvachev iive
On Sat, 1 Nov 2003 16:38:14 +0100 Alex Beregszaszi <alex@fsn.hu> wrote:
bpp depth
Sorry, for my ignorance, but what's the difference between bpp and depth ? Attila Kinali -- egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger -- reeler in +kaosu
Hi, here comes v2 :) 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?! 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) Hm, one new issue come to my mind: ARGB vs RGBA, aka the place of alpha byte. I hate these endianess issues :) -- Alex Beregszaszi <alex@fsn.hu> (MPlayer Core Developer -- http://www.mplayerhq.hu/)
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
On Sat, 1 Nov 2003 14:52:59 -0500 D Richard Felker III <dalias@aerifal.cx> wrote:
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.
Not really, think about subs or osd. It'll be imho nice if we just could handle them as a stream like normal video too. But on the other hand it may complicate things for the normal filters which dont need it. Attila Kinali -- egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger -- reeler in +kaosu
On Sun, Nov 02, 2003 at 11:29:51AM +0100, Attila Kinali wrote:
On Sat, 1 Nov 2003 14:52:59 -0500 D Richard Felker III <dalias@aerifal.cx> wrote:
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.
Not really, think about subs or osd. It'll be imho nice if we just could handle them as a stream like normal video too.
Handling them this way is slow. That's why Arpi designed a special format for OSD data that facilitates optimized alphablending. Even if you ever did want to treat them as images, RGBA would be silly...YUVA maybe, but...?
But on the other hand it may complicate things for the normal filters which dont need it.
Yes... Rich
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
Hi On Sunday 02 November 2003 01:00, D Richard Felker III wrote:
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). hmm if(mid.flags & MID_TYPE_YUV) would be an option too
[...] -- 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
participants (6)
-
Alex Beregszaszi -
Arpi -
Attila Kinali -
D Richard Felker III -
Ivan Kalvachev -
Michael Niedermayer