On Tuesday, November 08, 2011 12:46:32 Hiremath, Vaibhav wrote: > > -----Original Message----- > > From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx] > > Sent: Monday, November 07, 2011 7:06 PM > > To: Hiremath, Vaibhav > > Cc: linux-media@xxxxxxxxxxxxxxx > > Subject: Re: [PATCH] v4l2 doc: Added > > FBUF_CAP_SRC_CHROMAKEY/FLAG_SRC_CHROMAKEY > > > > Hi Vaibhav! > > > > This is a bit of a 'blast from the past', but when I went through the > > documentation of the framebuffer flags in the V4L2 spec I noticed that the > > definition of V4L2_FBUF_CAP_SRC_CHROMAKEY seemed to be wrong. > > > > The definition of V4L2_FBUF_CAP_CHROMAKEY says: > > > > 'The device supports clipping by chroma-keying the > > images. That is, image pixels replace pixels in the VGA or video > > signal only where the latter assume a certain color. Chroma-keying > > makes no sense for destructive overlays.' > > > > The definition of V4L2_FBUF_CAP_SRC_CHROMAKEY says: > > > > 'The device supports Source Chroma-keying. Framebuffer pixels > > with the chroma-key colors are replaced by video pixels, which > > is exactly opposite of V4L2_FBUF_CAP_CHROMAKEY.' > > > > As far as I can tell these definitions are really the same. I would expect > > that V4L2_FBUF_CAP_SRC_CHROMAKEY was defined as: > > > > 'The device supports Source Chroma-keying. Video pixels > > with the chroma-key colors are replaced by framebuffer pixels, which > > is exactly opposite of V4L2_FBUF_CAP_CHROMAKEY.' > > > > The only driver that implements this is omap_vout.c. So is the mistake > > in the documentation or in the driver? I think the documentation is wrong > > in this case. > > > I remember long time back we had discussion on this, we consider > V4L2_FBUF_CAP_CHROMAKEY as a destination color keying (term used in OMAP > spec) and V4L2_FBUF_CAP_SRC_CHROMAKEY as a source color keying(term used in > OMAP spec). > > As per OMAP spec the source color key is, replace video pixels by underneath gfx pixels based on chroma-key color. I think we aligned in this at that time, isn't it? AM I missing something? No, just that the current definition in the spec for V4L2_FBUF_CAP_SRC_CHROMAKEY is indeed the wrong way around. It should read: 'The device supports Source Chroma-keying. Video pixels with the chroma-key colors are replaced by framebuffer pixels, which is exactly opposite of V4L2_FBUF_CAP_CHROMAKEY.' I'll make a patch fixing this. Regards, Hans > > > FYI, as per OMAP spec, > > Destination color keying: > The graphics destination transparency color key value defines the encoded > pixels in the video layers to be displayed. The encoded pixel values with > the destination color key value are pixels not visible on the screen and the > pixels different from the transparency color key are displayed over the > video layers. The destination transparency color key is applicable only in > the graphics region when graphics and video overlap; otherwise, the > destination transparency color key is ignored. > > > Source color keying: > The video source transparency color key value defines the encoded pixel data > considered as the transparent pixel. The encoded pixel values with the > source color key value are pixels not visible on the screen, and the > underlayer encoded pixel values or solid background color are visible. > > > Thanks, > Vaibhav > > > Regards, > > > > Hans > > > > On Tuesday, November 10, 2009 15:45:45 hvaibhav@xxxxxx wrote: > > > From: Vaibhav Hiremath <hvaibhav@xxxxxx> > > > > > > > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@xxxxxx> > > > --- > > > linux/Documentation/DocBook/v4l/videodev2.h.xml | 2 ++ > > > linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml | 17 > > +++++++++++++++++ > > > 2 files changed, 19 insertions(+), 0 deletions(-) > > > > > > diff --git a/linux/Documentation/DocBook/v4l/videodev2.h.xml > > b/linux/Documentation/DocBook/v4l/videodev2.h.xml > > > index 9700206..eef7ba4 100644 > > > --- a/linux/Documentation/DocBook/v4l/videodev2.h.xml > > > +++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml > > > @@ -565,6 +565,7 @@ struct <link linkend="v4l2- > > framebuffer">v4l2_framebuffer</link> { > > > #define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010 > > > #define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020 > > > #define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040 > > > +#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080 > > > /* Flags for the 'flags' field. */ > > > #define V4L2_FBUF_FLAG_PRIMARY 0x0001 > > > #define V4L2_FBUF_FLAG_OVERLAY 0x0002 > > > @@ -572,6 +573,7 @@ struct <link linkend="v4l2- > > framebuffer">v4l2_framebuffer</link> { > > > #define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008 > > > #define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010 > > > #define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020 > > > +#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040 > > > > > > struct <link linkend="v4l2-clip">v4l2_clip</link> { > > > struct <link linkend="v4l2-rect">v4l2_rect</link> c; > > > diff --git a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > > b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > > > index f701706..e7dda48 100644 > > > --- a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > > > +++ b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > > > @@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for > > destructive overlays.</entry> > > > inverted alpha channel of the framebuffer or VGA signal. Alpha > > > blending makes no sense for destructive overlays.</entry> > > > </row> > > > + <row> > > > + <entry><constant>V4L2_FBUF_CAP_SRC_CHROMAKEY</constant></entry> > > > + <entry>0x0080</entry> > > > + <entry>The device supports Source Chroma-keying. Framebuffer > > pixels > > > +with the chroma-key colors are replaced by video pixels, which is > > exactly opposite of > > > +<constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry> > > > + </row> > > > </tbody> > > > </tgroup> > > > </table> > > > @@ -411,6 +418,16 @@ images, but with an inverted alpha value. The blend > > function is: > > > output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The > > > actual alpha depth depends on the framebuffer pixel format.</entry> > > > </row> > > > + <row> > > > + <entry><constant>V4L2_FBUF_FLAG_SRC_CHROMAKEY</constant></entry> > > > + <entry>0x0040</entry> > > > + <entry>Use source chroma-keying. The source chroma-key color is > > > +determined by the <structfield>chromakey</structfield> field of > > > +&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref > > > +linkend="overlay" /> and <xref linkend="osd" />. > > > +Both chroma-keying are mutual exclusive to each other, so same > > > +<structfield>chromakey</structfield> field of &v4l2-window; is being > > used.</entry> > > > + </row> > > > </tbody> > > > </tgroup> > > > </table> > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
