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
