Re: V4L2_PIX_FMT_RAW

[Thomas Kaiser <linux-dvb@kaiser-linux.li>]

Thierry Merle wrote:
> Hi Thomas ,
> Thomas Kaiser a écrit :
>> Laurent Pinchart wrote:
>>> On Thursday 21 February 2008, Thomas Kaiser wrote:
>>>> H. Willstrand wrote:
>>>>> On Thu, Feb 21, 2008 at 7:55 PM, Thomas Kaiser
>>>>>
>>>>> <linux-dvb@kaiser-linux.li> wrote:
>>>>>> H. Willstrand wrote:
>>>>>>  > On Thu, Feb 21, 2008 at 1:00 PM, Thomas Kaiser
>>>>>>  >
>>>>>>  > <linux-dvb@kaiser-linux.li> wrote:
>>>>>>  >> H. Willstrand wrote:
>>>>>>  >>  > On Thu, Feb 21, 2008 at 2:20 AM, Daniel Glöckner 
>>> <daniel-gl@gmx.net> wrote:
>>>>>>  >>  >> On Thu, Feb 21, 2008 at 01:02:39AM +0100, H. Willstrand
>>>>>> wrote:
>>>>>>  >>  >>  > 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
>>>>>>  >>
>>>>>>  >>  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
>>>>>>  >
>>>>>>  >>  > So, by looking for similarities in the "raw" formats where
>>>>>>  >>  > available there should be a potential to consolidate them.
>>>>>>  >>  >
>>>>>>  >>  >>  > 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.
>>>>> Yes, the USB bridge buffers, packages and transmits.
>>>>>
>>>>>>  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
>>>> 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.
>> 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

Didn't know that :-(. Looks like I have to do homework again ;-)

Thomas

PS: See you soon on the v4l2 library mailing-list :-)

> 
> 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!
> 
>>>>> ...
>>>>>
>>>>> 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?
>>>>
>>>>>>  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
>>>> Thomas
>>>>
>>>> [1] http://mxhaard.free.fr/download.html
>>> Best regards,
>>>
>>> Laurent Pinchart
>> Best Regards,
>>
>> Thomas
>>
> Cheers,
> Thierry


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

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