[wolfgar]

I *think* it is 3.10.9-1.0.0 alpha. It come from http://jas-hacks.blogspot.co.uk/2013/12/...9-100.html via http://imx.solid-run.com/forums/viewtopic.php?f=8&t=326

Thanks will check against my own version...

Okido.
Not sure what you mean by "communicate broader without opening a PR". Do you want more tester? devs? users?
I suggest we use the master of this fork as the base for the future XBMC PR, and that we ourselves PR vs. this master to allow cross-reviews.

OK let's do it that way !
As you are already aware I have created the organization here : https://github.com/xbmc-imx6/

Let the world be aware of it ;-)
Now all imx6 porting effort will be shared at this place...

For the version It should be EGL I guess : I will not stupidly advertize V4L against the global xbmc approach for rendering...
For now I have 2 concerns :
- vsync still not perfect for me but if you say it is ok for you then I have to find what's wrong with my env
- deinterlacing : We have to renounce to using IPU deinterlacing engine otherwise we are back to a imx specific mechanism I fear...
(There are also the freezes you mentioned)

Well, for me, vsync is not quite ok. It deadlocks (internally) at some point.
I haven't tried with smallint's suggestion of 3 buffers, yet, though.

I'd add
- resolution / refresh rate support
- I'm apparently loosing framebuffers when seeking, so I end up with "No framebuffers available" from the VPU
- simplify PTS handling (desynchronization). I saw you started on that. Most other XBMC codecs are using a simple queue which is pushed when we push a frame to the vpu and popped when doing the ::GetPicture

I totally agree.
Regarding pts, the latest commits in my branch aim at this simplification by getting rid of the gstreamer lib.
I have to tell I fear a simple fifo would not be good enough because, depending on encoding, pictures are not always output in the same order as encoded block are submitted in the decode function.
My latest attempt to use the vpu buffer as a key to retrieve the correct pts of output picture seems easy to port on current smallint version as a good compromise simplicity/correctness...

I will push smallint latest changes (he has merged your own recent changes) as a first candidate on master branch in a few minutes ...

I thank you very much for your help
Best regards

Stephan