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

2011-11-08 Thread Hiremath, Vaibhav 
 -Original Message-
 From: Hans Verkuil [mailto:hverk...@xs4all.nl]
 Sent: Monday, November 07, 2011 7:06 PM
 To: Hiremath, Vaibhav
 Cc: linux-media@vger.kernel.org
 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?


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 hvaib...@ti.com wrote:
  From: Vaibhav Hiremath hvaib...@ti.com
 
 
  Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
  ---
   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-
 framebufferv4l2_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-
 framebufferv4l2_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_CHROMAKEY0x0040
 
   struct link linkend=v4l2-clipv4l2_clip/link {
   struct link linkend=v4l2-rectv4l2_rect/linkc;
  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
  +   entryconstantV4L2_FBUF_CAP_SRC_CHROMAKEY/constant/entry
  +   entry0x0080/entry
  +   entryThe device supports Source Chroma-keying. Framebuffer
 pixels
  +with the chroma-key colors are replaced by video pixels, which is
 exactly

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

2011-11-08 Thread Hans Verkuil 
On Tuesday, November 08, 2011 12:46:32 Hiremath, Vaibhav wrote:
  -Original Message-
  From: Hans Verkuil [mailto:hverk...@xs4all.nl]
  Sent: Monday, November 07, 2011 7:06 PM
  To: Hiremath, Vaibhav
  Cc: linux-media@vger.kernel.org
  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 hvaib...@ti.com wrote:
   From: Vaibhav Hiremath hvaib...@ti.com
  
  
   Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
   ---
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-
  framebufferv4l2_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-
  framebufferv4l2_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_CHROMAKEY0x0040
  
struct link linkend=v4l2-clipv4l2_clip/link {
struct link linkend=v4l2-rectv4l2_rect/linkc;
   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

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

2011-11-07 Thread Hans Verkuil 
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.

Regards,

Hans

On Tuesday, November 10, 2009 15:45:45 hvaib...@ti.com wrote:
 From: Vaibhav Hiremath hvaib...@ti.com
 
 
 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
 ---
  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-framebufferv4l2_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-framebufferv4l2_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_CHROMAKEY0x0040
  
  struct link linkend=v4l2-clipv4l2_clip/link {
  struct link linkend=v4l2-rectv4l2_rect/linkc;
 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
 + entryconstantV4L2_FBUF_CAP_SRC_CHROMAKEY/constant/entry
 + entry0x0080/entry
 + entryThe device supports Source Chroma-keying. Framebuffer pixels
 +with the chroma-key colors are replaced by video pixels, which is exactly 
 opposite of
 +constantV4L2_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
 + entryconstantV4L2_FBUF_FLAG_SRC_CHROMAKEY/constant/entry
 + entry0x0040/entry
 + entryUse source chroma-keying. The source chroma-key color is
 +determined by the structfieldchromakey/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
 +structfieldchromakey/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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] v4l2 doc: Added FBUF_CAP_SRC_CHROMAKEY/FLAG_SRC_CHROMAKEY

2009-11-10 Thread hvaibhav 
From: Vaibhav Hiremath hvaib...@ti.com


Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
 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-framebufferv4l2_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-framebufferv4l2_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_CHROMAKEY0x0040
 
 struct link linkend=v4l2-clipv4l2_clip/link {
 struct link linkend=v4l2-rectv4l2_rect/linkc;
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
+   entryconstantV4L2_FBUF_CAP_SRC_CHROMAKEY/constant/entry
+   entry0x0080/entry
+   entryThe device supports Source Chroma-keying. Framebuffer pixels
+with the chroma-key colors are replaced by video pixels, which is exactly 
opposite of
+constantV4L2_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
+   entryconstantV4L2_FBUF_FLAG_SRC_CHROMAKEY/constant/entry
+   entry0x0040/entry
+   entryUse source chroma-keying. The source chroma-key color is
+determined by the structfieldchromakey/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
+structfieldchromakey/structfield field of v4l2-window; is being 
used./entry
+ /row
/tbody
   /tgroup
 /table
-- 
1.6.2.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html