On 07/26/2014 06:37 PM, Philipp Zabel wrote: > On Sat, Jul 26, 2014 at 5:12 PM, Hans Verkuil <hverkuil@xxxxxxxxx> 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. I never ever liked it that pixelaspect was part of cropcap since it is really unrelated to cropping. Now that the compound control support is in it might be time to create a pair of read-only controls that report the pixelaspect ratio, one for video capture, one for video output. That would be a much cleaner solution. Regards, Hans > > regards > Philipp > -- > 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 > -- 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
