[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] v4l2 doc: Added FBUF_CAP_SRC_CHROMAKEY/FLAG_SRC_CHROMAKEY



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


[Linux Input]     [Video for Linux]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Photos]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Devices]     [Yosemite Backpacking]

Add to Google Powered by Linux