Re: [PATCH 0/2] V4L: Extended crop/compose API

[Tomasz Stanislawski <t.stanislaws@samsung.com>]

Laurent Pinchart wrote:
> On Wednesday 18 May 2011 15:03:13 Sylwester Nawrocki wrote:
>> On 05/18/2011 02:31 PM, Hans Verkuil wrote:
>>> On Wednesday, May 18, 2011 14:06:21 Sylwester Nawrocki wrote:
>>>> On 05/16/2011 09:21 AM, Laurent Pinchart wrote:
>>>>> On Saturday 14 May 2011 12:50:32 Hans Verkuil wrote:
>>>>>> On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote:
>>>>>>> Thinking some more about it, does it make sense to set both crop and
>>>>>>> compose on a single video device node (not talking about mem-to-mem,
>>>>>>> where you use the type to multiplex input/output devices on the same
>>>>>>> node) ? If so, what would the use cases be ?
>>>> I can't think of any, one either use crop or compose.
>>> I can: you crop in the video receiver and compose it into a larger
>>> buffer.
>>>
>>> Actually quite a desirable feature.
>> Yes, right. Don't know why I imagined something different.
>> And we need it in Samsung capture capture interfaces as well. The H/W
>> is capable of cropping and composing with camera interface as a data source
>> similarly as it is done with memory buffers.
> 
> The same result could be achieved by adding an offset to the buffer address 
> and setting the bytesperline field accordingly, but that would only work with 
> userptr buffers. As we're working on an API to share buffers between 
> subsystems, I agree that composing into a larger buffer is desirable and 
> shouldn't be implemented using offset/stride.
> 
Hi,
Simulation of cropping on a data source using offset/bytesperline is not 
possible for compressed formats like JPEG. I could not find any good 
definition of bytesperline for macroblock and planar formats.
These problems were the reason of proposing extcrop (aka selection) API.

Bye
TS