From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Dufresne Subject: Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API Date: Tue, 29 Jan 2019 22:18:52 -0500 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: 8bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Tomasz Figa , Stanimir Varbanov Cc: 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 Le lundi 28 janvier 2019 à 16:38 +0900, Tomasz Figa a écrit : > > > 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. 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