GNOME Bugzilla – Bug 766381
v4l2object: use G_SELECTION instead of G_CROP in gst_v4l2_object_acquire_format
Last modified: 2016-06-06 21:35:31 UTC
Created attachment 327799 [details] [review] v4l2object: use G_SELECTION instead of G_CROP in gst_v4l2_object_acquire_format The gst_v4l2_object_acquire_format() function is used by v4l2videodec to obtain the currently set capture format. Since G_FMT returns the coded size, the visible size needs to be obtained from the compose rectangle in order to negotiate it with downstream elements. The G_CROP call hasn't worked on mem2mem capture queues for a long time. Instead use the G_SELECTION call to obtain the compose rectangle and only fall back to G_CROP for ancient kernels.
Review of attachment 327799 [details] [review]: Just a question, otherwise looks good. ::: sys/v4l2/gstv4l2object.c @@ +3667,3 @@ + memset (&sel, 0, sizeof (struct v4l2_selection)); + sel.type = v4l2object->type; + sel.target = V4L2_SEL_TGT_COMPOSE_DEFAULT; It's not clear in the spec, I was expecting CROP here instead of compose. Could you explain ?
Cropping pertains to the input image. Since mem2mem devices get their input images fed into the OUTPUT v4l2 queue, cropping the input frames has to be set there. In the decoder case we don't want to crop the input, though. We just happen to produce output frames that are larger than the input image dimensions by some padding. That is described by the compose rectangle of the CAPTURE v4l2 queue. See the right side of figure 1.2 in the selection API chapter [1]. The compose rectangle that describes the "whole picture" according to the spec is the V4L2_SEL_TGT_COMPOSE_DEFAULT [2]. [1] https://linuxtv.org/downloads/v4l-dvb-apis/selection-api.html [2] https://linuxtv.org/downloads/v4l-dvb-apis/apb.html#v4l2-selection-targets Cropping in the v4l2 sense would be if you ordered the decoder to only decode part of the image.
Pushed as 74f020f.