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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
