On 05/14/2016 01:59 PM, Nicolas Dufresne wrote: > Le vendredi 13 mai 2016 à 11:45 +0300, Stanimir Varbanov a écrit : >> yes, of course :) >> >> Just FYI, I applied the WIP patches on my side and I'm very happy to >> report that they just works. So If you need some testing on qcom >> video >> accelerator just ping me. >> >> One thing which bothers me is how the extra-controls property >> working, >> i.e. I failed to change the h264 profile for example with below >> construct: >> >> extra-controls="controls,h264_profile=4;" > > 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. -- regards, Stan -- 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
