Le jeudi 14 février 2019 à 11:43 +0900, Tomasz Figa a écrit : > > > > No, I exactly meant the OUTPUT queue. The behavior of s5p-mfc in case > > > > of the format not being detected yet is to waits for any pending > > > > bitstream buffers to be processed by the decoder before returning an > > > > error. > > > > > > > > See https://elixir.bootlin.com/linux/v5.0-rc5/source/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#L329 > > > > > > It blocks?! That shouldn't happen. Totally against the spec. > > > > > > > Yeah and that's what this patch tries to implement in venus as well > > and is seemingly required for compatibility with gstreamer... > > > > Hans, Nicolas, any thoughts? Thinking about this, if CODA managed to make it work without this, and without the source change event, we should probably study more this code and propose to do this instead of blocking (which is the ugly but easy solution). I'm sure it was a bit of juggle to pass the information correctly from input to output, but that would bring "compatibility" with un-ported userspace. If we had a codec specific framework (making a wish here), we could handle that for the codec, a bit like the code that emulates CROP on top of G/S_SELECTION. Meanwhile, I'm trying to get some time allocated to implement the event in GStreamer, as this would be sufficient argument to say that newly introduce drivers don't need to care, you just need newer userspace. For Venus it's a bit difficult, since they have customers using GStreamer already, and it's quite common to run newer kernel with much older userspace (and expect the userspace to keep working). Nicolas
