Am Samstag, den 14.05.2016, 15:07 +0300 schrieb Stanimir Varbanov: [...] > > While I got you. I would be very interested to know who QCOM driver > > interpreted the width and height expose on capture side of the decoder. > > I'm adding Philippe Zabel in CC here (he's maintaining the > > CODA/Freescale decoder). In Samsung MFC driver, the width and height > > expose by the driver is the display size. Though, recently, Philippe is > > reporting that his driver is exposing the coded size. Fixing one in > > GStreamer will break the other, so I was wondering what other drivers > > are doing. > > In qcom driver s_fmt on capture queue will return bigger or the same as > coded resolution depending on the width/height. This is related to hw > alignment restrictions i.e 1280x720 on output queue will become 1280x736 > on capture queue. The the userspace can/must call g_crop to receive the > active resolution for displaying. Since in that case the input video is nominally 1280x720, and we are not cropping away anything from that, this shouldn't use G_CROP (which maps to G_SELECTION with V4L2_SEL_TGT_CROP_ACTIVE), but G_SELECTION with V4L2_SEL_TGT_COMPOSE_DEFAULT on the capture queue. For mem2mem devices, cropping should happen at the output queue, and composing at the capture queue. For devices that don't scale, such as decoders, the output crop rectangle should have the same size as the capture compose rectangle. Is there any reason not to update the MFC driver to use G_SELECTION? The g_crop implementation could be kept for backwards compatibility. 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
