On Wed, Oct 9, 2013 at 11:49 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
> The main problem is that you use the wrong API: you need to use G/S_SELECTION instead
> of G/S_CROP. S_CROP on an output video node doesn't crop, it composes. And if your
> reaction is 'Huh?', then you're not alone. Which is why the selection API was added.
>
> The selection API can crop and compose for both capture and output nodes, and it
> does what you expect.
Happy to fix up the patch. I'll just need some clarification on the
terminology here. So, as I understand it:
(I'll use "source"/"sink" to refer to the device's inputs/outputs,
since "output" collides with the V4L2 concept of an OUTPUT device or
OUTPUT queue).
In all cases, the crop boundary refers to the area in the source
image; for a CAPTURE device, this is the (presumably analog) sensor,
and for an OUTPUT device, this is the memory buffer. My particular
case is a memory-to-memory device, with both CAPTURE and OUTPUT
queues. In this case, {G,S}_CROP on either the CAPTURE or OUTPUT
queues should effect exactly the same operation: cropping on the
source image, i.e. whatever image buffer I'm providing to the OUTPUT
queue.
The addition of {G,S}_SELECTION is to allow this same operation,
except on the sink side this time. So, {G,S}_SELECTION setting the
compose bounds on either the CAPTURE or OUTPUT queues should also
effect exactly the same operation; cropping on the sink image, i.e.
whatever memory buffer I'm providing to the CAPTURE queue.
Not sure what you mean by "S_CROP on an output video node doesn't
crop, it composes", though.
Thanks,
-John Sheu
--
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
