v4l2videodec with imx6 coda

[Nicolas Dufresne]

Le Samedi 26 Juillet 2014 10:49 EDT, Philipp Zabel <pza at pengutronix.de> a écrit: 
 
> Hi,
> 
> On Wed, Jul 23, 2014 at 10:01:34AM -0400, Nicolas Dufresne wrote:
> > Le mercredi 23 juillet 2014 à 00:16 -0700, Jens Kleintje a écrit :
> > > Hi,
> > > 
> > > I am trying to use the v4l2vídeodec plugin gstreamer version 1.4 with the
> > > imx6 coda driver on a imx6q sabre smart device board.
> > > 
> > > The patches for the driver are available under:
> > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg77198.html
> > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg76875.html.
> > > 
> > > Did anyone tried this?
> > 
> > I haven't got recent feedback about that from the team at Pengutronix
> > (now in CC). I know they already have a set of elements that covers
> > their needs, so it might not have been prioritized yet. Though, I think
> > with recent proposed changes to linux-media tree, to split the encoder
> > and decoder to use seperate /dev/videoX node (which endup cleaning up
> > things), there shouldn't be to much debugging to get it working, if it
> > does not work already. I would really appreciate feedback if by chance
> > you have the time to look at it. If you need anything, you can find me
> > on IRC too, freenode #gstreamer, my nick is stormer.
> 
> I have tried the stock GStreamer 1.4 v4l2videodec element and it decodes a
> stream out of the box with the kernel patches that I recently sent applied
> on top of the media tree:
> 
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg77198.html
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg77439.html
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg77541.html
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg77584.html

That's a good knews, thanks for testing this.

> 
> 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

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. 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. But isn't very well documented. Your method is not documented for men-2-men
devices either though, but is slightly simpler. 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 ?
 
regards,
Nicolas