On Sat, Jul 26, 2014 at 5:12 PM, Hans Verkuil <hverk...@xs4all.nl> wrote: > On 07/26/2014 04:34 PM, Philipp Zabel wrote: >> Crop targets are valid on the capture side and compose targets are valid >> on the output side, not the other way around. > > Are you sure about this? Usually for m2m devices the capture side supports > compose (i.e. the result of the m2m operation can be composed into the capture > buffer) and the output side supports crop (i.e. the m2m operates on the > cropped > part of the output buffer instead of on the full buffer), like the coda driver > does today.
You are right, I haven't thought this through. Please ignore this patch. > As a result of that the old G/S_CROP API cannot be used with most m2m devices > since it does the opposite operation, which does not apply to m2m devices. I have tried the GStreamer v4l2videodec element with the coda driver and noticed that GStreamer calls VIDIOC_CROPCAP to obtain the pixel aspect ratio. This always fails with -EINVAL because of this issue. Currently GStreamer throws a warning if the return value is an error other than -ENOTTY. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
