v4l2videodec with imx6 coda

[Philipp Zabel]

Hi Nicolas,

Am Sonntag, den 27.07.2014, 17:47 +0100 schrieb Nicolas Dufresne:
>  Le Samedi 26 Juillet 2014 10:49 EDT, Philipp Zabel <pza at pengutronix.de> a écrit: 
> > I see two issues, currently:
> > a) v4l2videodec should do a TRY_FMT/S_FMT on the V4L2 capture side.
> >    Currently only the I420 output format works because that happens
> >    to be the default. Also, the future CODA JPEG decoder will allow
> >    downscaling (by factors of 2, 4, and 8) during decompression.
> 
> I've created bugs to track these feature requests.
> 
> For the negotiation of output color format:
> https://bugzilla.gnome.org/show_bug.cgi?id=733827
> 
> For the negotiation of output size:
> https://bugzilla.gnome.org/show_bug.cgi?id=733828

Thank you.

> Patch are welcome. Also, be aware that I'm looking forward to see the probing of output capabilities
> to be documented, sanitized and well implemented in drivers. Currently your TRY_FMT proposition
> would imply too many combination to try on the width/height side.

Would it work if we were to implement ENUM_FMT on the output side to
limit the reported frame sizes to those that can be produced from the
currently set format on the input side?

>  The format part is relatively trivial, all one need is few lines of code and a driver to test it. Patches are welcome.
> 
> > b) At stream end I get a hardware timeout because the v4l2videodec doesn't
> >    send a V4L2_DEC_CMD_STOP decoder command to tell the CODA it may flush
> >    its bitstream buffer.
> 
> This is unfortunate, but it would seem decoders drivers don't agree on the draining method.
> The s5p-mfc decoder, expect that an empty buffer is pushed to drain at least 1 buffer out of the
> decoder. Then the decoder will indicate that all buffers has been drain by sending en empty buffer
> on the capture side. This is more powerful, as it allow implementing partial draining for timeout base
> real time decoding.

The s5p-mfc decoder does support VIDIOC_DECODER_CMD / V4L2_DEC_CMD_STOP
to enter its stream-end state. After dequeueing the last decoded frame,
the driver will generate a V4L2_EVENT_EOS event.

I chose to also use this method after the discussion in this thread:
https://patchwork.linuxtv.org/patch/18486/

>  But isn't very well documented. Your method is not documented for men-2-men
> devices either though, but is slightly simpler.

Do you think the VIDIOC_DECODER_CMD documentation should explicitly
mention capture and mem2mem devices?

>  It implies that all drivers have some thread running I think.
> Could you raise this issue to the linux-media mailing list, or at least agree with Kamil on a shared method ?

Yes, I'll bring it up again on linux-media.

regards
Philipp