From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Figa Subject: Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API Date: Wed, 30 Jan 2019 12:38:16 +0900 Message-ID: References: <20190117162008.25217-1-stanimir.varbanov@linaro.org> <20190117162008.25217-11-stanimir.varbanov@linaro.org> <28069a44-b188-6b89-2687-542fa762c00e@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Nicolas Dufresne Cc: Stanimir Varbanov , Linux Media Mailing List , Mauro Carvalho Chehab , Hans Verkuil , Linux Kernel Mailing List , linux-arm-msm , Vikash Garodia , Alexandre Courbot , Malathi Gottam List-Id: linux-arm-msm@vger.kernel.org On Wed, Jan 30, 2019 at 12:18 PM Nicolas Dufresne wr= ote: > > Le lundi 28 janvier 2019 =C3=A0 16:38 +0900, Tomasz Figa a =C3=A9crit : > > > > Nope, that's not what is expected to happen here. Especially since > > > > you're potentially in non-blocking IO mode. Regardless of that, the > > > > > > OK, how to handle that when userspace (for example gstreamer) hasn't > > > support for v4l2 events? The s5p-mfc decoder is doing the same sleep = in > > > g_fmt. > > > > I don't think that sleep in s5p-mfc was needed for gstreamer and > > AFAICT other drivers don't have it. Doesn't gstreamer just set the > > coded format on OUTPUT queue on its own? That should propagate the > > format to the CAPTURE queue, without the need to parse the stream. > > Yes, unfortunately, GStreamer still rely on G_FMT waiting a minimal > amount of time of the headers to be processed. This was how things was > created back in 2011, I could not program GStreamer for the future. If > we stop doing this, we do break GStreamer as a valid userspace > application. Does it? Didn't you say earlier that you end up setting the OUTPUT format with the stream resolution as parsed on your own? If so, that would actually expose a matching framebuffer format on the CAPTURE queue, so there is no need to wait for the real parsing to happen. > > This is not what I want long term, but I haven't got time to add event > support, and there is a certain amount of time (years) when this is > implemented before all the old code goes away. > > Nicolas >