Re: V4L2_PIX_FMT_RAW

[Daniel Glöckner <daniel-gl@xxxxxxx>]

On Wed, Feb 20, 2008 at 10:11:36PM +0100, Thomas Kaiser wrote:
> H. Willstrand wrote:
> >Well, it can go ugly if one piece of hardware supports several "raw"
> >formats, they need to be distinct. And in the end of the day the V4L2
> >drivers might consist of several identical "raw" formats which then
> >aren't consolidated.
> 
> I don't really understand what you try to say here.

Think about an analog TV card.
In the future there might be one where RAW could mean either sampled
CVBS or sampled Y/C. The card may be able to provide the Y/C in planar
and packed format. It may be capable of 16 bit at 13.5Mhz and 8 bit at
27Mhz, ...

If we start defining raw formats, there needs to be a way to choose
between all those variants without defining lots of additional pixel
formats.

Maybe an ioctl VIDIOC_S_RAW where one passes a number to select the
variant. An application would then have to check the driver and version
field returned by VIDIOC_QUERYCAP to determine the number to pass. This
way drivers may freely assign numbers to their raw formats.

Application writers would need to look into all drivers' docs/sources to
find the possible values. They would need to do it anyway to see if they
can decode the raw format.

  Daniel

P.S.: If my mail doesn't reach the list, blame its spam filter

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list