RE: [RFC] Adding new ioctl for transparency color keying

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

 




> -----Original Message-----
> From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx]
> Sent: Tuesday, January 27, 2009 6:38 PM
> To: Shah, Hardik
> Cc: linux-media@xxxxxxxxxxxxxxx; video4linux-list@xxxxxxxxxx
> Subject: Re: [RFC] Adding new ioctl for transparency color keying
> 
> On Tuesday 27 January 2009 13:53:23 Shah, Hardik wrote:
> > > -----Original Message-----
> > > From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx]
> > > Sent: Tuesday, January 27, 2009 3:21 PM
> > > To: Shah, Hardik
> > > Cc: linux-media@xxxxxxxxxxxxxxx; video4linux-list@xxxxxxxxxx
> > > Subject: Re: [RFC] Adding new ioctl for transparency color keying
> > >
> > > Hi Hardik,
> > >
> > > On Thursday 22 January 2009 05:57:18 Shah, Hardik wrote:
> > > > Hi,
> > > > OMAP class of device supports transparency color keying.  Color
> > > > keying can be source color keying or destination color keying.
> > >
> > > Can it be both as well?
> > >
> > > > OMAP3 has three pipelines one graphics plane and two video planes.
> > > > Any of these pipelines can go to either the TV or LCD.
> > > >
> > > > The destination transparency color key value defines the encoded
> > > > pixels in the graphics layer to become transparent and display the
> > > > underlying video pixels. While the source transparency key value
> > > > defines the encoded pixels in the video layer to become transparent
> > > > and display the underlying graphics pixels.  This color keying works
> > > > only if the video and graphics planes are on the same output like TV
> > > > or LCD and images of both the pipelines overlapped.
> > > >
> > > > I propose to have the one ioctl to set the encoded pixel value and
> > > > type of color keying source and destination.  Also we should have the
> > > > CID to enable/disable the color keying functionality.
> > > >
> > > > Please let us know your opinions/comments.
> > >
> > > Destination color keying is already available through the S_FBUF and
> > > S_FMT ioctls. Selecting source color keying can easily be added to
> > > S_FBUF, but setting the actual chromakey is harder. The logical place
> > > would be the v4l2_pix_format struct, but that is already full. I guess
> > > we should make a new control to set the source chromakey. It's not
> > > ideal, but it prevents duplicating existing functionality.
> >
> > [Shah, Hardik] Hi Hans,
> > This has nothing to do with the frame buffer.  Transparency key is a
> > hardware provided feature.  Driver has just to give the color code and
> > whether it wants the source color keying or destination color keying.
> > Hardware will automatically make the color code transparent so that the
> > below layer color will be seen. So I don't think so that S_FBUF is
> > suitable for this kind of feature. And this will automatically take
> > effect if the graphics pipeline is on the same output device as the video
> > pipeline.
> 
> Why has this nothing to do with the framebuffer? Isn't there a /dev/fbX
> device for the graphics framebuffer? If there is, then it is exactly as I
> described: a video output overlay (aka OSD). Do not confuse this with a
> video overlay which is used to accelerate displaying captured video.
> 
> See also:
> 
> http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-
> single/v4l2.html#OSD
[Shah, Hardik] Hi Hans,
Here the graphics node is created for the graphics pipeline. And graphics pipeline will be controlled by the graphics node /dev/fbx.  Application will set the desired pixel format for the /dev/fbx node and /dev/v4l/videox node.  After that application can select that same output device for both the nodes.  And then user may want to make transparent either the color from the video pipeline of the graphics pipeline.  In any case application will not require frame buffer parameters like base address of the buffer as the blending/transparency processing will not be done in driver.  It will be done by hardware by setting the appropriate register bits.  So do you think that S_FBUF is required?   Please let me know if I am missing something.    If you want I can forward you the link referring to the Technical reference manual explaining the color keying in hardware.

Regards,
Hardik Shah 
> 
> Regards,
> 
>       Hans
> 
> --
> Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
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

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux