Re: [PATCH 2.6.39] soc_camera: OMAP1: fix missing bytesperline and sizeimage initialization

[Sylwester Nawrocki <s.nawrocki@samsung.com>]

Hi,

On 04/12/2011 08:28 AM, Guennadi Liakhovetski wrote:
> Hi
> 
> On Tue, 12 Apr 2011, Kassey Lee wrote:
> 
>> hi, Guennadi:
>>     a lot of sensors support JPEG output.
>>     1) bytesperline is defined by sensor timing.

Im not sure whether this is the case. Doesn't bytesperline refer only 
to the data layout in memory buffer written by the DMA? 
i.e. does padding really makes sens for JPEG files?

>>     2) and sizeimage is unknow for jpeg.
>>
>>   how about for JPEG
>>    1) host driver gets bytesperline from sensor driver.
>>    2) sizeimage refilled by host driver after dma transfer done( a
>> frame is received)

You might want to use v4l2_buffer::bytesused to inform user space about
the actual size of the captured frame, which would be set before a buffer
is dequeued from the driver. The size of JPEG file will depend on the content,
so IMHO you could not use v4l2_pix_fmt::sizeimage in such way.


>>   thanks.
> 
> How is this done currently on other V4L2 drivers? To transfer a frame you
> usually first do at least one of S_FMT and G_FMT, at which time you 
> already have to report sizeimage to the user - before any transfer has 
> taken place. Currently with soc-camera it is already possible to override 
> sizeimage and bytesperline from the host driver. Just set them to whatever 
> you need in your try_fmt and they will be kept. Not sure how you want to 
> do that, if you need to first read in a frame - do you want to perform 
> some dummy frame transfer? You might not even have any buffers queued yet, 
> so, it has to be a read without writing to RAM. Don't such compressed 
> formats just put a value in sizeimage, that is a calculated maximum size?

I the S5P FIMC driver I used to set sizeimage to some arbitrary value,
(it's not yet in mainline kernel), e.g.
sizeimage = width * height * C,  where C = 1
bytesperline = width.

However it would be useful to make the C coefficient dependent on JPEG
compression quality, not to make the image buffer unnecessary large.
I thought about creating a separate control class for JPEG but the quality
control was so far everything I would need to put in this class. It's on my
to do list to figure out what controls set would cover the standard.


Regards,
-- 
Sylwester Nawrocki
Samsung Poland R&D Center