V4L2_PIX_FMT_RAW

Quoted 38 lines · Thomas Kaiser

Quoted 27 lines · H. Willstrand

Quoted 25 lines · Thomas Kaiser

Quoted 11 lines · H. Willstrand

Quoted 6 lines · Thomas Kaiser

Why is V4L2_PIX_FMT_RAW not included as a pixel format in V4l2?

I would like to just forward the stream from my webcam "as it is" to user space .

V4L2_PIX_FMT_RAW looks as it is the right thing I need.

V4L2 drivers should not perform any video transformations, the driver provides user space with hardware supported formats.

Ok, so, I need a entry for Pixart chips.
PAC207: a line based coding algo.
PAC7311: the interpretation of JPEG from Pixart
PAC7302: the _new_ interpretation of JPEG from Pixart

V4L2_PIX_FMT_RAW would make my live easier.

The option to forward the stream "as it is" would be really nice. When the manufacture of some video streaming devices (like webcams) do their own thing, you can forward the raw stream and the user application can take care of the decoding of the stream.

Quoted 5 lines

Quoted 2 lines

For me it looks not like such a bad idea!!!???

Yes, it might be a good idea to add something like V4L2_PIX_FMT_PAC207, etc. This is anyhow the case with the PWC family.

I think the better is to just forward the stream to userspace. Then we have to make a lib which can be called from all these video application around to decode the stream.

Quoted 6 lines

Somebody talked already about this on the list.

When the cam is able to send a stream in a good known format it is no problem to handle this with the right V4L2_PIX_FMT_..., but if not, we need a "official" way to get this "devil" stream to user space!

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.

Harri

Quoted 52 lines · H. Willstrand

Quoted 38 lines · Thomas Kaiser

Quoted 27 lines · H. Willstrand

Quoted 25 lines · Thomas Kaiser

Quoted 11 lines · H. Willstrand

Quoted 6 lines · Thomas Kaiser

Why is V4L2_PIX_FMT_RAW not included as a pixel format in V4l2?

I would like to just forward the stream from my webcam "as it is" to user space .

V4L2_PIX_FMT_RAW looks as it is the right thing I need.

V4L2 drivers should not perform any video transformations, the driver provides user space with hardware supported formats.

Ok, so, I need a entry for Pixart chips.
PAC207: a line based coding algo.
PAC7311: the interpretation of JPEG from Pixart
PAC7302: the _new_ interpretation of JPEG from Pixart

V4L2_PIX_FMT_RAW would make my live easier.

The option to forward the stream "as it is" would be really nice. When the manufacture of some video streaming devices (like webcams) do their own thing, you can forward the raw stream and the user application can take care of the decoding of the stream.

Quoted 5 lines

Quoted 2 lines

For me it looks not like such a bad idea!!!???

Yes, it might be a good idea to add something like V4L2_PIX_FMT_PAC207, etc. This is anyhow the case with the PWC family.

I think the better is to just forward the stream to userspace. Then we have to make a lib which can be called from all these video application around to decode the stream.

Quoted 6 lines

Somebody talked already about this on the list.

When the cam is able to send a stream in a good known format it is no problem to handle this with the right V4L2_PIX_FMT_..., but if not, we need a "official" way to get this "devil" stream to user space!

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.

Quoted 1 line

Harri

I don't really understand what you try to say here.
I want to have the stream forwarded "as it is" to user space. Then the v4l2 driver even have not to know what kind of stream this is!
We just forward the stream (again) "as it is" to user space.
Now, the user space application (viewer app, skype or what ever) has to decide if they can handle the stream.

PS: Why do you answer OFF-LIST? I think it is a nice topic to discussed with everyone on the list.

Quoted 53 lines · Thomas Kaiser

Quoted 52 lines · H. Willstrand

Quoted 38 lines · Thomas Kaiser

Quoted 27 lines · H. Willstrand

Quoted 25 lines · Thomas Kaiser

Quoted 11 lines · H. Willstrand

Quoted 6 lines · Thomas Kaiser

Why is V4L2_PIX_FMT_RAW not included as a pixel format in V4l2?

I would like to just forward the stream from my webcam "as it is" to user space .

V4L2_PIX_FMT_RAW looks as it is the right thing I need.

V4L2 drivers should not perform any video transformations, the driver provides user space with hardware supported formats.

Ok, so, I need a entry for Pixart chips.
PAC207: a line based coding algo.
PAC7311: the interpretation of JPEG from Pixart
PAC7302: the _new_ interpretation of JPEG from Pixart

V4L2_PIX_FMT_RAW would make my live easier.

The option to forward the stream "as it is" would be really nice. When the manufacture of some video streaming devices (like webcams) do their own thing, you can forward the raw stream and the user application can take care of the decoding of the stream.

Quoted 5 lines

Quoted 2 lines

For me it looks not like such a bad idea!!!???

Yes, it might be a good idea to add something like V4L2_PIX_FMT_PAC207, etc. This is anyhow the case with the PWC family.

I think the better is to just forward the stream to userspace. Then we have to make a lib which can be called from all these video application around to decode the stream.

Quoted 6 lines

Somebody talked already about this on the list.

When the cam is able to send a stream in a good known format it is no problem to handle this with the right V4L2_PIX_FMT_..., but if not, we need a "official" way to get this "devil" stream to user space!

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.

Quoted 9 lines

Quoted 1 line

Harri

I don't really understand what you try to say here.
I want to have the stream forwarded "as it is" to user space. Then the v4l2 driver even have not to know what kind of stream this is!
We just forward the stream (again) "as it is" to user space.
Now, the user space application (viewer app, skype or what ever) has to decide if they can handle the stream.

Ok, if a driver exposes a RAW format, how can a application know if it can handle the format? By looking at the driver name? What if the driver have several RAW formats? (they might have)

Next, standardization is a good thing, and hopefully chip set vendors tries to keep down the number of formats, so it's a good idea to try define distinct V4L2_PIX_FMT for each distinct format.

Cheers,
Harri

Quoted 2 lines

PS: Why do you answer OFF-LIST? I think it is a nice topic to discussed with everyone on the list.

I thought I did, sorry for that.

//Harri

Quoted 4 lines · H. Willstrand

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.

Quoted 6 lines · Thomas Kaiser

Quoted 4 lines · H. Willstrand

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

Quoted 18 lines · Daniel Glöckner

Quoted 6 lines · Thomas Kaiser

Quoted 4 lines · H. Willstrand

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.

Quoted 4 lines

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.

Quoted 24 lines · Thomas Kaiser

Quoted 22 lines · Daniel Glöckner

Quoted 6 lines · Thomas Kaiser

Quoted 4 lines · H. Willstrand

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.

Quoted 2 lines

Yeh, That's something I mean.

Okay, suppose we have pixel formats and raw formats. Comparing with digital cameras raw usually means non processed image in a proprietary format. What do we mean here?

Quoted 26 lines · H. Willstrand

Quoted 24 lines · Thomas Kaiser

Quoted 22 lines · Daniel Glöckner

Quoted 6 lines · Thomas Kaiser

Quoted 4 lines · H. Willstrand

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.

Quoted 6 lines

Quoted 2 lines

Yeh, That's something I mean.

Okay, suppose we have pixel formats and raw formats. Comparing with digital cameras raw usually means non processed image in a proprietary format. What do we mean here?

I talk about webcams. But It looks like you don't get the point. A ISOC stream can be received, then we forward this to user space! That's it.

This has nothing to do with pixel format, just deliver the stream from the cam to user space, That's all what I won't.
I think raw means raw, "not manipulated"! Oder in Deutsch Roh equals raw, which means "not touched".

You get the point?

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Quoted 2 lines · H. Willstrand

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define V4L2_PIX_FMT_x for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats that are used by more than one driver.

Quoted 4 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just needs a private control id to select one.

Quoted 8 lines · Daniel Glöckner

Quoted 2 lines · H. Willstrand

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define V4L2_PIX_FMT_x for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats that are used by more than one driver.

Correct, the number of unique pixel formats should be kept down. Again, comparing with digital cameras there are >200 proprietary formats and there is a "clean-up" on-going where the "market" is aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then driver specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 7 lines

Quoted 3 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a VIDIOC_S_FMT should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Harri

Quoted 7 lines · H. Willstrand

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Yes, raw means "as it is" no stripping, decoding or removing of SOF headers are done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?

Quoted 10 lines · Thomas Kaiser

Quoted 7 lines · H. Willstrand

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 3 lines

Yes, raw means "as it is" no stripping, decoding or removing of SOF headers are done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?

IMHO "raw" is the output of the ADC(s).

Uncompressed.

For webcams probably something like V4L2_PIX_FMT_SBGGR16.

Lossless transformations allowed.

Quoted 20 lines · H. Willstrand

Quoted 8 lines · Daniel Glöckner

Quoted 2 lines · H. Willstrand

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define V4L2_PIX_FMT_x for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats that are used by more than one driver.

Correct, the number of unique pixel formats should be kept down. Again, comparing with digital cameras there are >200 proprietary formats and there is a "clean-up" on-going where the "market" is aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then driver specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Quoted 7 lines

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Yes, raw means "as it is" no stripping, decoding or removing of SOF headers are done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?

Quoted 16 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 7 lines

Quoted 3 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a VIDIOC_S_FMT should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Quoted 1 line

Harri

--
http://www.kaiser-linux.li

Quoted 29 lines · Thomas Kaiser

Quoted 20 lines · H. Willstrand

Quoted 8 lines · Daniel Glöckner

Quoted 2 lines · H. Willstrand

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define V4L2_PIX_FMT_x for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats that are used by more than one driver.

Correct, the number of unique pixel formats should be kept down. Again, comparing with digital cameras there are >200 proprietary formats and there is a "clean-up" on-going where the "market" is aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then driver specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Quoted 7 lines

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 3 lines

Yes, raw means "as it is" no stripping, decoding or removing of SOF headers are done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?

I struggle with the probability to find several CCD's having similar formats. There aren't so many manifactors of CCD's but they truelly can generate divergeting formats. Worst case scenario means >200 V4L2_PIX_FMT_RAW_...

I think RAW is a OK name, the question is if the subcomponents of the RAW formats has similarities, if so they might be standardized. Looking into different Sony CCD's it's clearly possible, but after the CCD the data has to be buffered, packaged and transmitted which of course can be done in several ways...

Cheers,
Harri

Quoted 16 lines

Quoted 16 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 7 lines

Quoted 3 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a VIDIOC_S_FMT should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Harri

Quoted 64 lines · H. Willstrand

Quoted 29 lines · Thomas Kaiser

Quoted 20 lines · H. Willstrand

Quoted 8 lines · Daniel Glöckner

Quoted 2 lines · H. Willstrand

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define V4L2_PIX_FMT_x for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats that are used by more than one driver.

Correct, the number of unique pixel formats should be kept down. Again, comparing with digital cameras there are >200 proprietary formats and there is a "clean-up" on-going where the "market" is aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then driver specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Quoted 7 lines

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 3 lines

Yes, raw means "as it is" no stripping, decoding or removing of SOF headers are done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?

I struggle with the probability to find several CCD's having similar formats. There aren't so many manifactors of CCD's but they truelly can generate divergeting formats. Worst case scenario means >200 V4L2_PIX_FMT_RAW_...

I think RAW is a OK name, the question is if the subcomponents of the RAW formats has similarities, if so they might be standardized. Looking into different Sony CCD's it's clearly possible, but after the CCD the data has to be buffered, packaged and transmitted which of course can be done in several ways...

Cheers,
Harri

Quoted 15 lines

Quoted 15 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 7 lines

Quoted 3 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a VIDIOC_S_FMT should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Harri

Actually, in a webcam you have the image sensor and a usb bridge. Usually, the sensor capture a picture in Bayer pattern. This gets forwarded to the usb bridge. The usb bridge may or may not transfer the picture to an other format and/or compress it with a standard compression algo or a proprietary compression algo. The resulting data stream will be transmitted over the usb interface.

I just would like to get this resulting stream to user space without manipulation/conversion/decoding of the stream in the kernel module.

That means we don't know what the format is in this data which comes trough the usb interface. That's way I call it raw.

At the moment with V4L2, I have to forward a stream to user space which is in a format v4l2 knows. That means I have sometimes to do heavy data processing in the kernel module to decode/convert the data from the usb stream to a known v4l2 video format.

That's way I want a official way to forward the untouched usb stream to user space!

How the user space application has to react on this stream is an other story, I think. But there will be some way to tell the usespace application what to do with this "unknown" stream, I am sure.

Thomas

Quoted 65 lines · Thomas Kaiser

Quoted 64 lines · H. Willstrand

Quoted 29 lines · Thomas Kaiser

Quoted 20 lines · H. Willstrand

Quoted 8 lines · Daniel Glöckner

Quoted 2 lines · H. Willstrand

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define V4L2_PIX_FMT_x for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats that are used by more than one driver.

Correct, the number of unique pixel formats should be kept down. Again, comparing with digital cameras there are >200 proprietary formats and there is a "clean-up" on-going where the "market" is aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then driver specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Quoted 7 lines

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 3 lines

Yes, raw means "as it is" no stripping, decoding or removing of SOF headers are done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?

I struggle with the probability to find several CCD's having similar formats. There aren't so many manifactors of CCD's but they truelly can generate divergeting formats. Worst case scenario means >200 V4L2_PIX_FMT_RAW_...

I think RAW is a OK name, the question is if the subcomponents of the RAW formats has similarities, if so they might be standardized. Looking into different Sony CCD's it's clearly possible, but after the CCD the data has to be buffered, packaged and transmitted which of course can be done in several ways...

Cheers,
Harri

Quoted 15 lines

Quoted 15 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 7 lines

Quoted 3 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a VIDIOC_S_FMT should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Quoted 8 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Harri

Actually, in a webcam you have the image sensor and a usb bridge. Usually, the sensor capture a picture in Bayer pattern. This gets forwarded to the usb bridge. The usb bridge may or may not transfer the picture to an other format and/or compress it with a standard compression algo or a proprietary compression algo. The resulting data stream will be transmitted over the usb interface.

Yes, the USB bridge buffers, packages and transmits.

Quoted 11 lines

I just would like to get this resulting stream to user space without manipulation/conversion/decoding of the stream in the kernel module.

That means we don't know what the format is in this data which comes trough the usb interface. That's way I call it raw.

At the moment with V4L2, I have to forward a stream to user space which is in a format v4l2 knows. That means I have sometimes to do heavy data processing in the kernel module to decode/convert the data from the usb stream to a known v4l2 video format.

Drivers should not do any decoding / converting, it's not allowed in kernel mode.
But you are right, there are a number of V4L1 exceptions:
AR M64278 (arv.c) converts YUV422 to YUV422P
QuickCam (bw-qcam.c) converts RAW to a useful format :) CPiA (cpia.c) converts 420 to different RGB formats OmniVision (ov511.c) converts from YUV4:0:0
PWC (V4L2) does decoding

...

However, the Webcams provides only a limited set of formats and the "raw" are usually available. New drivers with proprietary "raw" formats should be added to videodev2.h

Quoted 7 lines

That's way I want a official way to forward the untouched usb stream to user space!

How the user space application has to react on this stream is an other story, I think. But there will be some way to tell the usespace application what to do with this "unknown" stream, I am sure.

Quoted 2 lines

Thomas

Cheers,
Harri

Quoted 90 lines · H. Willstrand

Quoted 65 lines · Thomas Kaiser

Quoted 64 lines · H. Willstrand

Quoted 29 lines · Thomas Kaiser

Quoted 20 lines · H. Willstrand

Quoted 8 lines · Daniel Glöckner

Quoted 2 lines · H. Willstrand

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define V4L2_PIX_FMT_x for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats that are used by more than one driver.

Correct, the number of unique pixel formats should be kept down. Again, comparing with digital cameras there are >200 proprietary formats and there is a "clean-up" on-going where the "market" is aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then driver specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Quoted 7 lines

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 3 lines

Yes, raw means "as it is" no stripping, decoding or removing of SOF headers are done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?

I struggle with the probability to find several CCD's having similar formats. There aren't so many manifactors of CCD's but they truelly can generate divergeting formats. Worst case scenario means >200 V4L2_PIX_FMT_RAW_...

I think RAW is a OK name, the question is if the subcomponents of the RAW formats has similarities, if so they might be standardized. Looking into different Sony CCD's it's clearly possible, but after the CCD the data has to be buffered, packaged and transmitted which of course can be done in several ways...

Cheers,
Harri

Quoted 15 lines

Quoted 15 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 7 lines

Quoted 3 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a VIDIOC_S_FMT should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Quoted 8 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Harri

Actually, in a webcam you have the image sensor and a usb bridge. Usually, the sensor capture a picture in Bayer pattern. This gets forwarded to the usb bridge. The usb bridge may or may not transfer the picture to an other format and/or compress it with a standard compression algo or a proprietary compression algo. The resulting data stream will be transmitted over the usb interface.

Yes, the USB bridge buffers, packages and transmits.

Quoted 11 lines

I just would like to get this resulting stream to user space without manipulation/conversion/decoding of the stream in the kernel module.

That means we don't know what the format is in this data which comes trough the usb interface. That's way I call it raw.

At the moment with V4L2, I have to forward a stream to user space which is in a format v4l2 knows. That means I have sometimes to do heavy data processing in the kernel module to decode/convert the data from the usb stream to a known v4l2 video format.

Quoted 8 lines

Drivers should not do any decoding / converting, it's not allowed in kernel mode.
But you are right, there are a number of V4L1 exceptions:
AR M64278 (arv.c) converts YUV422 to YUV422P
QuickCam (bw-qcam.c) converts RAW to a useful format :) CPiA (cpia.c) converts 420 to different RGB formats OmniVision (ov511.c) converts from YUV4:0:0
PWC (V4L2) does decoding

You forgot gspca [1](support of 260 webcams at the moment) and here we even do jpeg decoding in kernel space to get the proper format for v4l1!

Quoted 5 lines

...

However, the Webcams provides only a limited set of formats and the "raw" are usually available. New drivers with proprietary "raw" formats should be added to videodev2.h

That means you agree with me?

Quoted 110 lines · Thomas Kaiser

Quoted 90 lines · H. Willstrand

Quoted 65 lines · Thomas Kaiser

Quoted 64 lines · H. Willstrand

Quoted 29 lines · Thomas Kaiser

Quoted 20 lines · H. Willstrand

Quoted 8 lines · Daniel Glöckner

Quoted 2 lines · H. Willstrand

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define V4L2_PIX_FMT_x for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats that are used by more than one driver.

Correct, the number of unique pixel formats should be kept down. Again, comparing with digital cameras there are >200 proprietary formats and there is a "clean-up" on-going where the "market" is aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then driver specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Quoted 7 lines

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 3 lines

Yes, raw means "as it is" no stripping, decoding or removing of SOF headers are done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?

I struggle with the probability to find several CCD's having similar formats. There aren't so many manifactors of CCD's but they truelly can generate divergeting formats. Worst case scenario means >200 V4L2_PIX_FMT_RAW_...

I think RAW is a OK name, the question is if the subcomponents of the RAW formats has similarities, if so they might be standardized. Looking into different Sony CCD's it's clearly possible, but after the CCD the data has to be buffered, packaged and transmitted which of course can be done in several ways...

Cheers,
Harri

Quoted 15 lines

Quoted 15 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 7 lines

Quoted 3 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a VIDIOC_S_FMT should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Quoted 8 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Harri

Actually, in a webcam you have the image sensor and a usb bridge. Usually, the sensor capture a picture in Bayer pattern. This gets forwarded to the usb bridge. The usb bridge may or may not transfer the picture to an other format and/or compress it with a standard compression algo or a proprietary compression algo. The resulting data stream will be transmitted over the usb interface.

Yes, the USB bridge buffers, packages and transmits.

Quoted 11 lines

I just would like to get this resulting stream to user space without manipulation/conversion/decoding of the stream in the kernel module.

That means we don't know what the format is in this data which comes trough the usb interface. That's way I call it raw.

At the moment with V4L2, I have to forward a stream to user space which is in a format v4l2 knows. That means I have sometimes to do heavy data processing in the kernel module to decode/convert the data from the usb stream to a known v4l2 video format.

Quoted 8 lines

Drivers should not do any decoding / converting, it's not allowed in kernel mode.
But you are right, there are a number of V4L1 exceptions:
AR M64278 (arv.c) converts YUV422 to YUV422P
QuickCam (bw-qcam.c) converts RAW to a useful format :) CPiA (cpia.c) converts 420 to different RGB formats OmniVision (ov511.c) converts from YUV4:0:0
PWC (V4L2) does decoding

You forgot gspca [1](support of 260 webcams at the moment) and here we even do jpeg decoding in kernel space to get the proper format for v4l1!

Quoted 5 lines

...

However, the Webcams provides only a limited set of formats and the "raw" are usually available. New drivers with proprietary "raw" formats should be added to videodev2.h

Quoted 2 lines

That means you agree with me?

Did so from start :)
With the small exception, I still beleive that all RAW formats should be distinct, not one generic V4L2_PIX_FMT_RAW.

Quoted 112 lines · H. Willstrand

Quoted 110 lines · Thomas Kaiser

Quoted 90 lines · H. Willstrand

Quoted 65 lines · Thomas Kaiser

Quoted 64 lines · H. Willstrand

Quoted 29 lines · Thomas Kaiser

Quoted 20 lines · H. Willstrand

Quoted 8 lines · Daniel Glöckner

Quoted 2 lines · H. Willstrand

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define V4L2_PIX_FMT_x for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats that are used by more than one driver.

Correct, the number of unique pixel formats should be kept down. Again, comparing with digital cameras there are >200 proprietary formats and there is a "clean-up" on-going where the "market" is aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then driver specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Quoted 7 lines

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 3 lines

Yes, raw means "as it is" no stripping, decoding or removing of SOF headers are done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?

I struggle with the probability to find several CCD's having similar formats. There aren't so many manifactors of CCD's but they truelly can generate divergeting formats. Worst case scenario means >200 V4L2_PIX_FMT_RAW_...

I think RAW is a OK name, the question is if the subcomponents of the RAW formats has similarities, if so they might be standardized. Looking into different Sony CCD's it's clearly possible, but after the CCD the data has to be buffered, packaged and transmitted which of course can be done in several ways...

Cheers,
Harri

Quoted 15 lines

Quoted 15 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 7 lines

Quoted 3 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a VIDIOC_S_FMT should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Quoted 8 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Harri

Actually, in a webcam you have the image sensor and a usb bridge. Usually, the sensor capture a picture in Bayer pattern. This gets forwarded to the usb bridge. The usb bridge may or may not transfer the picture to an other format and/or compress it with a standard compression algo or a proprietary compression algo. The resulting data stream will be transmitted over the usb interface.

Yes, the USB bridge buffers, packages and transmits.

Quoted 11 lines

I just would like to get this resulting stream to user space without manipulation/conversion/decoding of the stream in the kernel module.

That means we don't know what the format is in this data which comes trough the usb interface. That's way I call it raw.

At the moment with V4L2, I have to forward a stream to user space which is in a format v4l2 knows. That means I have sometimes to do heavy data processing in the kernel module to decode/convert the data from the usb stream to a known v4l2 video format.

Quoted 8 lines

Drivers should not do any decoding / converting, it's not allowed in kernel mode.
But you are right, there are a number of V4L1 exceptions:
AR M64278 (arv.c) converts YUV422 to YUV422P
QuickCam (bw-qcam.c) converts RAW to a useful format :) CPiA (cpia.c) converts 420 to different RGB formats OmniVision (ov511.c) converts from YUV4:0:0
PWC (V4L2) does decoding

You forgot gspca [1](support of 260 webcams at the moment) and here we even do jpeg decoding in kernel space to get the proper format for v4l1!

Quoted 5 lines

...

However, the Webcams provides only a limited set of formats and the "raw" are usually available. New drivers with proprietary "raw" formats should be added to videodev2.h

Quoted 6 lines

Quoted 2 lines

That means you agree with me?

Did so from start :)
With the small exception, I still beleive that all RAW formats should be distinct, not one generic V4L2_PIX_FMT_RAW.

Yes and No, It all depends on how the user space app can handle the raw "unknown" stream. But as I wrote earlier, this is an other story ;-)

So, now, I have to ask Mauro to include this?
Or what is the proper way to get this official?

Quoted 9 lines · H. Willstrand

On Thu, Feb 21, 2008 at 7:55 PM, Thomas Kaiser

Quoted 6 lines · <[email protected]> wrote:

Quoted 5 lines · H. Willstrand

On Thu, Feb 21, 2008 at 1:00 PM, Thomas Kaiser

Quoted 2 lines · <[email protected]> wrote:

Quoted 1 line · H. Willstrand

On Thu, Feb 21, 2008 at 2:20 AM, Daniel Glöckner

Quoted 81 lines

Quoted 59 lines

Quoted 59 lines

Quoted 27 lines

Quoted 19 lines

Quoted 8 lines · H. Willstrand

Quoted 2 lines

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define V4L2_PIX_FMT_x
for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats that are used by more than one driver.

Correct, the number of unique pixel formats should be kept down. Again, comparing with digital cameras there are >200 proprietary formats and there is a "clean-up" on-going where the "market" is aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then driver specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Quoted 7 lines

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 3 lines

Yes, raw means "as it is" no stripping, decoding or removing of
SOF headers are done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?

I struggle with the probability to find several CCD's having similar formats. There aren't so many manifactors of CCD's but they truelly can generate divergeting formats. Worst case scenario means >200 V4L2_PIX_FMT_RAW_...

I think RAW is a OK name, the question is if the subcomponents of the RAW formats has similarities, if so they might be standardized. Looking into different Sony CCD's it's clearly possible, but after the CCD the data has to be buffered, packaged and transmitted which of course can be done in several ways...

Cheers,
Harri

Quoted 14 lines

Quoted 14 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 5 lines

Quoted 2 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just
needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a VIDIOC_S_FMT should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Quoted 8 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Harri

Actually, in a webcam you have the image sensor and a usb bridge.
Usually, the sensor capture a picture in Bayer pattern. This gets forwarded to the usb bridge. The usb bridge may or may not transfer the picture to an other format and/or compress it with a standard compression algo or a proprietary compression algo. The resulting data stream will be transmitted over the usb interface.

Yes, the USB bridge buffers, packages and transmits.

Quoted 10 lines

I just would like to get this resulting stream to user space without manipulation/conversion/decoding of the stream in the kernel module.

That means we don't know what the format is in this data which comes
trough the usb interface. That's way I call it raw.

At the moment with V4L2, I have to forward a stream to user space which
is in a format v4l2 knows. That means I have sometimes to do heavy data processing in the kernel module to decode/convert the data from the usb stream to a known v4l2 video format.

Quoted 8 lines

Drivers should not do any decoding / converting, it's not allowed in kernel mode.
But you are right, there are a number of V4L1 exceptions:
AR M64278 (arv.c) converts YUV422 to YUV422P
QuickCam (bw-qcam.c) converts RAW to a useful format :) CPiA (cpia.c) converts 420 to different RGB formats OmniVision (ov511.c) converts from YUV4:0:0
PWC (V4L2) does decoding

You forgot gspca [1](support of 260 webcams at the moment) and here we even do jpeg decoding in kernel space to get the proper format for v4l1!

Quoted 5 lines

...

However, the Webcams provides only a limited set of formats and the "raw" are usually available. New drivers with proprietary "raw" formats should be added to videodev2.h

That means you agree with me?

Quoted 7 lines

Quoted 7 lines

That's way I want a official way to forward the untouched usb stream to
user space!

How the user space application has to react on this stream is an other
story, I think. But there will be some way to tell the usespace application what to do with this "unknown" stream, I am sure.

Quoted 4 lines

Quoted 1 line

Thomas

Cheers,
Harri

Thomas

[1] http://mxhaard.free.fr/download.html

Quoted 10 lines · Thomas Kaiser

Quoted 9 lines · H. Willstrand

On Thu, Feb 21, 2008 at 7:55 PM, Thomas Kaiser

Quoted 6 lines · <[email protected]> wrote:

Quoted 5 lines · H. Willstrand

On Thu, Feb 21, 2008 at 1:00 PM, Thomas Kaiser

Quoted 2 lines · <[email protected]> wrote:

Quoted 1 line · H. Willstrand

On Thu, Feb 21, 2008 at 2:20 AM, Daniel Glöckner

Quoted 87 lines · <[email protected]> wrote:

Quoted 87 lines

Quoted 59 lines

Quoted 59 lines

Quoted 27 lines

Quoted 19 lines

Quoted 8 lines · H. Willstrand

Quoted 2 lines

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define V4L2_PIX_FMT_x
for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats that are used by more than one driver.

Correct, the number of unique pixel formats should be kept down. Again, comparing with digital cameras there are >200 proprietary formats and there is a "clean-up" on-going where the "market" is aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then driver specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Quoted 7 lines

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 3 lines

Yes, raw means "as it is" no stripping, decoding or removing of
SOF headers are done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?

I struggle with the probability to find several CCD's having similar formats. There aren't so many manifactors of CCD's but they truelly can generate divergeting formats. Worst case scenario means >200 V4L2_PIX_FMT_RAW_...

I think RAW is a OK name, the question is if the subcomponents of the RAW formats has similarities, if so they might be standardized. Looking into different Sony CCD's it's clearly possible, but after the CCD the data has to be buffered, packaged and transmitted which of course can be done in several ways...

Cheers,
Harri

Quoted 14 lines

Quoted 14 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 5 lines

Quoted 2 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just
needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a VIDIOC_S_FMT should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Quoted 8 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Harri

Actually, in a webcam you have the image sensor and a usb bridge.
Usually, the sensor capture a picture in Bayer pattern. This gets forwarded to the usb bridge. The usb bridge may or may not transfer the picture to an other format and/or compress it with a standard compression algo or a proprietary compression algo. The resulting data stream will be transmitted over the usb interface.

Yes, the USB bridge buffers, packages and transmits.

Quoted 10 lines

I just would like to get this resulting stream to user space without manipulation/conversion/decoding of the stream in the kernel module.

That means we don't know what the format is in this data which comes
trough the usb interface. That's way I call it raw.

At the moment with V4L2, I have to forward a stream to user space which
is in a format v4l2 knows. That means I have sometimes to do heavy data processing in the kernel module to decode/convert the data from the usb stream to a known v4l2 video format.

Drivers should not do any decoding / converting, it's not allowed in kernel mode.
But you are right, there are a number of V4L1 exceptions:
AR M64278 (arv.c) converts YUV422 to YUV422P
QuickCam (bw-qcam.c) converts RAW to a useful format :) CPiA (cpia.c) converts 420 to different RGB formats OmniVision (ov511.c) converts from YUV4:0:0
PWC (V4L2) does decoding

Quoted 2 lines

You forgot gspca [1](support of 260 webcams at the moment) and here we even do jpeg decoding in kernel space to get the proper format for v4l1!

There are historical reasons. Those drivers should be fixed to remove decoding from kernelspace. Obviously a new userspace component will be needed to handle decoding and conversion, otherwise applications will break. No consensus exists today regarding what form that component should take.

Quoted 18 lines

Quoted 6 lines

...

However, the Webcams provides only a limited set of formats and the "raw" are usually available. New drivers with proprietary "raw" formats should be added to videodev2.h

That means you agree with me?

Quoted 10 lines

Quoted 8 lines

That's way I want a official way to forward the untouched usb stream to
user space!

How the user space application has to react on this stream is an other
story, I think. But there will be some way to tell the usespace application what to do with this "unknown" stream, I am sure.

Thomas

Cheers,
Harri

Quoted 3 lines

Thomas

[1] http://mxhaard.free.fr/download.html

Best regards,

Laurent Pinchart

Quoted 122 lines · Laurent Pinchart

Quoted 10 lines · Thomas Kaiser

Quoted 9 lines · H. Willstrand

On Thu, Feb 21, 2008 at 7:55 PM, Thomas Kaiser

Quoted 6 lines · <[email protected]> wrote:

Quoted 5 lines · H. Willstrand

On Thu, Feb 21, 2008 at 1:00 PM, Thomas Kaiser

Quoted 2 lines · <[email protected]> wrote:

Quoted 1 line · H. Willstrand

On Thu, Feb 21, 2008 at 2:20 AM, Daniel Glöckner

Quoted 106 lines · <[email protected]> wrote:

Quoted 98 lines

Quoted 75 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Thu, Feb 21, 2008 at 01:02:39AM +0100, H. Willstrand

Quoted 1 line · wrote:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

What's the problem with having a name of the formalized

data

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define

V4L2_PIX_FMT_x

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats

that

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

are used by more than one driver.

Correct, the number of unique pixel formats should be kept

down.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Again, comparing with digital cameras there are >200

proprietary

Quoted 1 line

Quoted 1 line

Quoted 1 line

formats and there is a "clean-up" on-going where the

"market" is

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then

driver

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 2 lines

Quoted 2 lines

Yes, raw means "as it is" no stripping, decoding or removing of
SOF headers are done in the driver. May be V4L2_PIX_FMT_AII

(AII ->

Quoted 3 lines

Quoted 1 line

As It Is) is the better name?

I struggle with the probability to find several CCD's having

similar

Quoted 1 line

formats. There aren't so many manifactors of CCD's but they

truelly

Quoted 4 lines

can generate divergeting formats. Worst case scenario means >200 V4L2_PIX_FMT_RAW_...

I think RAW is a OK name, the question is if the subcomponents

of the

Quoted 3 lines

RAW formats has similarities, if so they might be standardized. Looking into different Sony CCD's it's clearly possible, but after the CCD the data has to be buffered, packaged and transmitted

which

Quoted 15 lines

of course can be done in several ways...

Cheers,
Harri

Quoted 10 lines

Quoted 10 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 5 lines

Quoted 2 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just
needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a

VIDIOC_S_FMT

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Harri

Quoted 8 lines

Actually, in a webcam you have the image sensor and a usb bridge.
Usually, the sensor capture a picture in Bayer pattern. This gets forwarded to the usb bridge. The usb bridge may or may not transfer the
picture to an other format and/or compress it with a standard compression algo or a proprietary compression algo. The resulting data
stream will be transmitted over the usb interface.

Yes, the USB bridge buffers, packages and transmits.

Quoted 6 lines

I just would like to get this resulting stream to user space without manipulation/conversion/decoding of the stream in the kernel module.

That means we don't know what the format is in this data which comes
trough the usb interface. That's way I call it raw.

Quoted 7 lines

At the moment with V4L2, I have to forward a stream to user space
which
is in a format v4l2 knows. That means I have sometimes to do heavy data
processing in the kernel module to decode/convert the data from the usb
stream to a known v4l2 video format.

Quoted 8 lines

Drivers should not do any decoding / converting, it's not allowed in kernel mode.
But you are right, there are a number of V4L1 exceptions:
AR M64278 (arv.c) converts YUV422 to YUV422P
QuickCam (bw-qcam.c) converts RAW to a useful format :) CPiA (cpia.c) converts 420 to different RGB formats OmniVision (ov511.c) converts from YUV4:0:0
PWC (V4L2) does decoding

Quoted 3 lines

You forgot gspca [1](support of 260 webcams at the moment) and here we even
do jpeg decoding in kernel space to get the proper format for v4l1!

Quoted 5 lines

There are historical reasons. Those drivers should be fixed to remove decoding from kernelspace. Obviously a new userspace component will be needed to handle decoding and conversion, otherwise applications will break. No consensus exists today regarding what form that component should take.

Yes, but all this transformation which is done in kernel space can be done in user space. But it looks like that nobody is interested to move this to user space (expect you) ;-)
And I think it should not be that hard to introduce a user space component to handle this. When the user space app programmers are willing to do so!

Quoted 24 lines

Quoted 23 lines

Quoted 6 lines

...

However, the Webcams provides only a limited set of formats and the "raw" are usually available. New drivers with proprietary "raw" formats should be added to videodev2.h

That means you agree with me?

Quoted 4 lines

Quoted 4 lines

That's way I want a official way to forward the untouched usb
stream to
user space!

Quoted 8 lines

Quoted 6 lines

How the user space application has to react on this stream is an
other
story, I think. But there will be some way to tell the usespace application what to do with this "unknown" stream, I am sure.

Thomas

Cheers,
Harri

Thomas

[1] http://mxhaard.free.fr/download.html

Quoted 3 lines

Best regards,

Laurent Pinchart

Best Regards,

Thomas

Hi Thomas ,

Quoted 127 lines · Thomas Kaiser

Quoted 118 lines · Laurent Pinchart

Quoted 10 lines · Thomas Kaiser

Quoted 9 lines · H. Willstrand

On Thu, Feb 21, 2008 at 7:55 PM, Thomas Kaiser

Quoted 6 lines · <[email protected]> wrote:

Quoted 5 lines · H. Willstrand

On Thu, Feb 21, 2008 at 1:00 PM, Thomas Kaiser

Quoted 2 lines · <[email protected]> wrote:

Quoted 1 line · H. Willstrand

On Thu, Feb 21, 2008 at 2:20 AM, Daniel Glöckner

Quoted 106 lines · <[email protected]> wrote:

Quoted 106 lines

Quoted 75 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Thu, Feb 21, 2008 at 01:02:39AM +0100, H. Willstrand

Quoted 1 line · wrote:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

What's the problem with having a name of the formalized

data

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define

V4L2_PIX_FMT_x

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats

that

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

are used by more than one driver.

Correct, the number of unique pixel formats should be kept

down.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Again, comparing with digital cameras there are >200

proprietary

Quoted 1 line

Quoted 1 line

Quoted 1 line

formats and there is a "clean-up" on-going where the

"market" is

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then

driver

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 2 lines

Quoted 2 lines

Yes, raw means "as it is" no stripping, decoding or removing of
SOF headers are done in the driver. May be V4L2_PIX_FMT_AII

(AII ->

Quoted 3 lines

Quoted 1 line

As It Is) is the better name?

I struggle with the probability to find several CCD's having

similar

Quoted 1 line

formats. There aren't so many manifactors of CCD's but they

truelly

Quoted 4 lines

can generate divergeting formats. Worst case scenario means >200 V4L2_PIX_FMT_RAW_...

I think RAW is a OK name, the question is if the subcomponents

of the

Quoted 3 lines

RAW formats has similarities, if so they might be standardized. Looking into different Sony CCD's it's clearly possible, but after the CCD the data has to be buffered, packaged and transmitted

which

Quoted 15 lines

of course can be done in several ways...

Cheers,
Harri

Quoted 10 lines

Quoted 10 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 5 lines

Quoted 2 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just
needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a

VIDIOC_S_FMT

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Harri

Quoted 8 lines

Actually, in a webcam you have the image sensor and a usb bridge.
Usually, the sensor capture a picture in Bayer pattern. This gets forwarded to the usb bridge. The usb bridge may or may not transfer the
picture to an other format and/or compress it with a standard compression algo or a proprietary compression algo. The resulting data
stream will be transmitted over the usb interface.

Yes, the USB bridge buffers, packages and transmits.

Quoted 6 lines

I just would like to get this resulting stream to user space without manipulation/conversion/decoding of the stream in the kernel module.

That means we don't know what the format is in this data which comes
trough the usb interface. That's way I call it raw.

Quoted 7 lines

At the moment with V4L2, I have to forward a stream to user space
which
is in a format v4l2 knows. That means I have sometimes to do heavy data
processing in the kernel module to decode/convert the data from the usb
stream to a known v4l2 video format.

Drivers should not do any decoding / converting, it's not allowed in kernel mode.
But you are right, there are a number of V4L1 exceptions:
AR M64278 (arv.c) converts YUV422 to YUV422P
QuickCam (bw-qcam.c) converts RAW to a useful format :) CPiA (cpia.c) converts 420 to different RGB formats OmniVision (ov511.c) converts from YUV4:0:0
PWC (V4L2) does decoding

Quoted 8 lines

Quoted 3 lines

You forgot gspca [1](support of 260 webcams at the moment) and here we even
do jpeg decoding in kernel space to get the proper format for v4l1!

There are historical reasons. Those drivers should be fixed to remove decoding from kernelspace. Obviously a new userspace component will be needed to handle decoding and conversion, otherwise applications will break. No consensus exists today regarding what form that component should take.

Quoted 7 lines

Yes, but all this transformation which is done in kernel space can be done in user space. But it looks like that nobody is interested to move this to user space (expect you) ;-)
And I think it should not be that hard to introduce a user space component to handle this. When the user space app programmers are willing to do so!

Well, of course you can participate to the v4l2 library mailing-list. We started a userspace daemon that would do the frame decompression in userspace and give back uncompressed frames to the application via a virtual device driver.
You will find more information on here:
http://www.linuxtv.org/v4lwiki/index.php/V4L2UserspaceLibrary
http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l2-library
I maintain the current code here:
http://linuxtv.org/hg/~tmerle/v4l2_extension

For now, the virtual driver is here, the userspace daemon is here, the virtual driver <-> daemon command passing is bound to be here thanks to Jiri Slaby.
Now, we need to implement the frame decompression. I should do that with the usbvision driver that includes a decompression algorithm in kernelspace but we can extend it to any v4l2 device driver. Feel free to join, comment and ask for precisions!

Quoted 21 lines

Quoted 21 lines

Quoted 21 lines

Quoted 5 lines

...

However, the Webcams provides only a limited set of formats and the "raw" are usually available. New drivers with proprietary "raw" formats should be added to videodev2.h

That means you agree with me?

Quoted 4 lines

Quoted 4 lines

That's way I want a official way to forward the untouched usb
stream to
user space!

Quoted 8 lines

Quoted 6 lines

How the user space application has to react on this stream is an
other
story, I think. But there will be some way to tell the usespace application what to do with this "unknown" stream, I am sure.

Thomas

Cheers,
Harri

Thomas

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

[1] http://mxhaard.free.fr/download.html

Best regards,

Laurent Pinchart

Best Regards,

Thomas

Cheers,
Thierry

Hi Thomas ,

Quoted 129 lines · Thomas Kaiser

Quoted 122 lines · Laurent Pinchart

Quoted 10 lines · Thomas Kaiser

Quoted 9 lines · H. Willstrand

On Thu, Feb 21, 2008 at 7:55 PM, Thomas Kaiser

Quoted 6 lines · <[email protected]> wrote:

Quoted 5 lines · H. Willstrand

On Thu, Feb 21, 2008 at 1:00 PM, Thomas Kaiser

Quoted 2 lines · <[email protected]> wrote:

Quoted 1 line · H. Willstrand

On Thu, Feb 21, 2008 at 2:20 AM, Daniel Glöckner

Quoted 106 lines · <[email protected]> wrote:

Quoted 98 lines

Quoted 75 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Thu, Feb 21, 2008 at 01:02:39AM +0100, H. Willstrand

Quoted 1 line · wrote:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

What's the problem with having a name of the formalized

data

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define

V4L2_PIX_FMT_x

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

for an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats

that

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

are used by more than one driver.

Correct, the number of unique pixel formats should be kept

down.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Again, comparing with digital cameras there are >200

proprietary

Quoted 1 line

Quoted 1 line

Quoted 1 line

formats and there is a "clean-up" on-going where the

"market" is

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then

driver

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 2 lines

Quoted 2 lines

Yes, raw means "as it is" no stripping, decoding or removing of
SOF headers are done in the driver. May be V4L2_PIX_FMT_AII

(AII ->

Quoted 3 lines

Quoted 1 line

As It Is) is the better name?

I struggle with the probability to find several CCD's having

similar

Quoted 1 line

formats. There aren't so many manifactors of CCD's but they

truelly

Quoted 4 lines

can generate divergeting formats. Worst case scenario means >200 V4L2_PIX_FMT_RAW_...

I think RAW is a OK name, the question is if the subcomponents

of the

Quoted 3 lines

RAW formats has similarities, if so they might be standardized. Looking into different Sony CCD's it's clearly possible, but after the CCD the data has to be buffered, packaged and transmitted

which

Quoted 15 lines

of course can be done in several ways...

Cheers,
Harri

Quoted 10 lines

Quoted 10 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 5 lines

Quoted 2 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just
needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a

VIDIOC_S_FMT

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Harri

Quoted 8 lines

Actually, in a webcam you have the image sensor and a usb bridge.
Usually, the sensor capture a picture in Bayer pattern. This gets forwarded to the usb bridge. The usb bridge may or may not transfer the
picture to an other format and/or compress it with a standard compression algo or a proprietary compression algo. The resulting data
stream will be transmitted over the usb interface.

Yes, the USB bridge buffers, packages and transmits.

Quoted 6 lines

I just would like to get this resulting stream to user space without manipulation/conversion/decoding of the stream in the kernel module.

That means we don't know what the format is in this data which comes
trough the usb interface. That's way I call it raw.

Quoted 7 lines

At the moment with V4L2, I have to forward a stream to user space
which
is in a format v4l2 knows. That means I have sometimes to do heavy data
processing in the kernel module to decode/convert the data from the usb
stream to a known v4l2 video format.

Quoted 8 lines

Drivers should not do any decoding / converting, it's not allowed in kernel mode.
But you are right, there are a number of V4L1 exceptions:
AR M64278 (arv.c) converts YUV422 to YUV422P
QuickCam (bw-qcam.c) converts RAW to a useful format :) CPiA (cpia.c) converts 420 to different RGB formats OmniVision (ov511.c) converts from YUV4:0:0
PWC (V4L2) does decoding

Quoted 3 lines

You forgot gspca [1](support of 260 webcams at the moment) and here we even
do jpeg decoding in kernel space to get the proper format for v4l1!

Quoted 5 lines

There are historical reasons. Those drivers should be fixed to remove decoding from kernelspace. Obviously a new userspace component will be needed to handle decoding and conversion, otherwise applications will break. No consensus exists today regarding what form that component should take.

Quoted 7 lines

Yes, but all this transformation which is done in kernel space can be done in user space. But it looks like that nobody is interested to move this to user space (expect you) ;-)
And I think it should not be that hard to introduce a user space component to handle this. When the user space app programmers are willing to do so!

Well, of course you can participate to the v4l2 library mailing-list. We started a userspace daemon that would do the frame decompression in userspace and give back uncompressed frames to the application via a virtual device driver.
You will find more information on here:
http://www.linuxtv.org/v4lwiki/index.php/V4L2UserspaceLibrary
http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l2-library
I maintain the current code here:
http://linuxtv.org/hg/~tmerle/v4l2_extension

For now, the virtual driver is here, the userspace daemon is here, the virtual driver <-> daemon command passing is bound to be here thanks to Jiri Slaby.
Now, we need to implement the frame decompression. I should do that with the usbvision driver that includes a decompression algorithm in kernelspace but we can extend it to any v4l2 device driver. Feel free to join, comment and ask for precisions!

Quoted 25 lines

Quoted 25 lines

Quoted 24 lines

Quoted 7 lines

...

However, the Webcams provides only a limited set of formats and the "raw" are usually available. New drivers with proprietary "raw" formats should be added to videodev2.h

That means you agree with me?

Quoted 4 lines

Quoted 4 lines

That's way I want a official way to forward the untouched usb
stream to
user space!

Quoted 8 lines

Quoted 6 lines

How the user space application has to react on this stream is an
other
story, I think. But there will be some way to tell the usespace application what to do with this "unknown" stream, I am sure.

Thomas

Cheers,
Harri

Thomas

[1] http://mxhaard.free.fr/download.html

Quoted 8 lines

Quoted 3 lines

Best regards,

Laurent Pinchart

Best Regards,

Thomas

Cheers,
Thierry

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Hi Thierry,

Ok, so the idea is to make converting and decompression transparent for the application.

Are there any plans to run the v4l2_helper as an shared object in the application process with a direct interface? (to avoid the kernel-to-user-space, user-to-kernel-space, kernel-to-user-space)

Quoted 1 line · H. Willstrand

Hi Thierry,

[SNIP]

Quoted 3 lines

Ok, so the idea is to make converting and decompression transparent for the application.

Quoted 3 lines

Are there any plans to run the v4l2_helper as an shared object in the application process with a direct interface? (to avoid the kernel-to-user-space, user-to-kernel-space, kernel-to-user-space)

Yes, this is the aim of the project; the final step I hope will show a new library that will be used by applications, discussing directly with the base drivers.

Please join to the v4l2-library mailing-list to discuss about the implementation of the helper daemon in that way. Following discussions about this specific subject will be easier!

Quoted 5 lines · H. Willstrand

On Thu, Feb 21, 2008 at 1:00 PM, Thomas Kaiser

Quoted 2 lines · <[email protected]> wrote:

Quoted 1 line · H. Willstrand

On Thu, Feb 21, 2008 at 2:20 AM, Daniel Glöckner <[email protected]>

Quoted 36 lines

Quoted 27 lines

Quoted 19 lines

Quoted 8 lines · H. Willstrand

Quoted 2 lines

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define V4L2_PIX_FMT_x for
an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats that are used by more than one driver.

Correct, the number of unique pixel formats should be kept down. Again, comparing with digital cameras there are >200 proprietary formats and there is a "clean-up" on-going where the "market" is aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then driver specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Quoted 7 lines

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 3 lines

Yes, raw means "as it is" no stripping, decoding or removing of SOF
headers are done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?

I struggle with the probability to find several CCD's having similar formats. There aren't so many manifactors of CCD's but they truelly can generate divergeting formats. Worst case scenario means >200 V4L2_PIX_FMT_RAW_...

Quoted 24 lines

I think RAW is a OK name, the question is if the subcomponents of the RAW formats has similarities, if so they might be standardized. Looking into different Sony CCD's it's clearly possible, but after the CCD the data has to be buffered, packaged and transmitted which of course can be done in several ways...

Cheers,
Harri

Quoted 15 lines

Quoted 15 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 5 lines

Quoted 2 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a VIDIOC_S_FMT should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Harri

Actually, in a webcam you have the image sensor and a usb bridge. Usually, the sensor capture a picture in Bayer pattern. This gets forwarded to the usb bridge. The usb bridge may or may not transfer the picture to an other format and/or compress it with a standard compression algo or a proprietary compression algo. The resulting data stream will be transmitted over the usb interface.

I just would like to get this resulting stream to user space without manipulation/conversion/decoding of the stream in the kernel module.

That means we don't know what the format is in this data which comes trough the usb interface. That's way I call it raw.

At the moment with V4L2, I have to forward a stream to user space which is in a format v4l2 knows. That means I have sometimes to do heavy data processing in the kernel module to decode/convert the data from the usb stream to a known v4l2 video format.

That's way I want a official way to forward the untouched usb stream to user space!

How the user space application has to react on this stream is an other story, I think. But there will be some way to tell the usespace application what to do with this "unknown" stream, I am sure.

Hi Thomas and Harri,

Quoted 6 lines · Thomas Kaiser

Quoted 5 lines · H. Willstrand

On Thu, Feb 21, 2008 at 1:00 PM, Thomas Kaiser

Quoted 2 lines · <[email protected]> wrote:

Quoted 1 line · H. Willstrand

On Thu, Feb 21, 2008 at 2:20 AM, Daniel Glöckner <[email protected]>

Quoted 66 lines · wrote:

Quoted 35 lines

Quoted 27 lines

Quoted 19 lines

Quoted 8 lines · H. Willstrand

Quoted 2 lines

What's the problem with having a name of the formalized data in the video stream? ie raw do not mean undefined.

I thought you wanted to avoid having to define V4L2_PIX_FMT_x for
an exploding number of proprietary formats that are quite similar but still incompatible. It makes sense for formats that are used by more than one driver.

Correct, the number of unique pixel formats should be kept down. Again, comparing with digital cameras there are >200 proprietary formats and there is a "clean-up" on-going where the "market" is aiming for a OpenRAW.

However, by declaring a generic RAW format (which is then driver specific) doesn't help the user mode app developers. Calling a multitude of libraries to see if you get lucky might not be a good idea.

Quoted 7 lines

Still, I'm suspectious about the definition "raw" used here. RAW should mean unprocessed image data:
* no white balance adjustment
* no color saturation adjustments
* no contrast adjustments
* no sharpness improvements
* no compression with loss

Quoted 3 lines

Yes, raw means "as it is" no stripping, decoding or removing of SOF
headers are done in the driver. May be V4L2_PIX_FMT_AII (AII -> As It Is) is the better name?

I struggle with the probability to find several CCD's having similar formats. There aren't so many manifactors of CCD's but they truelly can generate divergeting formats. Worst case scenario means >200 V4L2_PIX_FMT_RAW_...

Quoted 24 lines

I think RAW is a OK name, the question is if the subcomponents of the RAW formats has similarities, if so they might be standardized. Looking into different Sony CCD's it's clearly possible, but after the CCD the data has to be buffered, packaged and transmitted which of course can be done in several ways...

Cheers,
Harri

Quoted 15 lines

Quoted 15 lines

So, by looking for similarities in the "raw" formats where available there should be a potential to consolidate them.

Quoted 5 lines

Quoted 2 lines

I don't see how separate RAW ioctl's will add value to the V4l2 API, it fits into the current API.

Yes, it does. Each driver having multiple raw formats just needs a private control id to select one.

I was more thinking about the VIDIOC_S_RAW stuff, a VIDIOC_S_FMT should do the job.
I.e. I think there should be strong reasons to break V4L2 API behavior.

Harri

Actually, in a webcam you have the image sensor and a usb bridge. Usually, the sensor capture a picture in Bayer pattern. This gets forwarded to the usb bridge. The usb bridge may or may not transfer the picture to an other format and/or compress it with a standard compression algo or a proprietary compression algo. The resulting data stream will be transmitted over the usb interface.

Quoted 2 lines

I just would like to get this resulting stream to user space without manipulation/conversion/decoding of the stream in the kernel module.

For most USB devices the resulting stream will be completely unusable. USB provides packet boundary information that would be lost. Except when the data transmitted over USB is stream-based (MPEG 2/4 for instance), the resulting stream will have headers intermixed with data with no way to tell them apart.

Quoted 2 lines

That means we don't know what the format is in this data which comes trough the usb interface. That's way I call it raw.

That's not true. If you really don't know what format the data are in, there is little point in getting the data.

Video frames can be in a standard format (MJPEG, RGB, ...) or in a proprietary format (mostly device-specific compression formats). That format is identified at the V4L2 level by a four character code (fourcc). A quick look at videodev2.h shows that several vendor-specific formats are defined (SN9C10x compression, pwc compression, ...). New formats should be added as new devices hit the market.

Quoted 4 lines

At the moment with V4L2, I have to forward a stream to user space which is in a format v4l2 knows. That means I have sometimes to do heavy data processing in the kernel module to decode/convert the data from the usb stream to a known v4l2 video format.

Nothing in V4L2 prevents you from using a private fourcc, although it would be easier to submit new fourcc's for inclusion in V4L2. As long as the userspace application supports the format and recognises its fourcc your kernel driver will only have to handle the USB headers (which are part of the protocol, not the format) and won't have to touch the video frame data at all.

Quoted 3 lines

That's way I want a official way to forward the untouched usb stream to user space!

Just define a new fourcc and use it to identify your data format.

Quoted 4 lines

How the user space application has to react on this stream is an other story, I think. But there will be some way to tell the usespace application what to do with this "unknown" stream, I am sure.

With a defined fourcc the stream won't be "unknown".

Best regards,

Laurent Pinchart