Re: V4L2_PIX_FMT_RAW
Daniel Glöckner wrote:
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.
Yeh, That's something I mean.
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.
That's why we need a user space library to handle all this strange "unknown"
streams.
When the application can not decode (or does not know) the stream, just get it
to the decoding lib. When the stream is known, you get a decoded picture back.
If not you get an error.
Thomas
Daniel
P.S.: If my mail doesn't reach the list, blame its spam filter
--
http://www.kaiser-linux.li
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list