Kodi Community Forum

(2015-02-14, 23:52)FreeFighter Wrote: [ -> ]Hi guys,

Dont want to interrupt your work in progress. Is there a stable Kodi build to install on imx6 yet? I'm still on Frodo.

You interrupted ...

(2015-02-14, 23:52)FreeFighter Wrote: [ -> ]Dont want to interrupt your work in progress. Is there a stable Kodi build to install on imx6 yet? I'm still on Frodo.

Yes, Helix has support for iMX6. Most of the work in this thread is about support for HD interlaced content (HDTV)...

@bubi
Hi I have run a bunch of tests with your carmen sample
As smallint mentioned (yes now I have read the full thread ), the VPU contribution is the first key.
If you want to be able to play this video you definitively have to use a kernel which clocks VPU @352Mhz, that's a must have.
Even with this change the time to deinterlace and render this sample, even without waiting for vsync is on the line : 32ms per frame (playing the file locally from memory not from network)
With my current implementation and vpu@352M, if you disable deinterlacing then you can have a mean 29ms per frame with results in smooth playback (without deinterlacing of course)

Given my tests, reaching smooth playback with deinterlacing and correct margins is doable but requires yet another improvement : being able to send only the video plane to IPU for rendering (at the moment the GUI plane is always sent even when fully transparent)
In this configuration I manage to reach :
27ms per frame without deinterlacing
29ms per frame with deintermacing
So, in theory this will allow for perfect playback (these tests are done with a dedicated test application written by smallint which uses kodi imx codec class)

This optimization is something I have been speaking about for a long time.
Being able to enable/disable the overlay plane which contains the GUI is doable (we will have to switch the fb used depending on video mode but still doable quite easily), the hard part is knowing when we only display the video itself and the GUI is fully transparent. Smallint already had a look at it and reported it is not that easy...
We have to dig a little more I guess as it would really allow to reach the best that this architecture can offer and would likely also open new capabilities to the solo variant...

Note that to me this last optimization step should not block the current PR...

Stéphan

Quote:the hard part is knowing when we only display the video itself and the GUI is fully transparent. Smallint already had a look at it and reported it is not that easy

That is probably something for FernetMenta to look into. What we need is to know when nothing, absolutely nothing is rendered and currently visible from the GUI. Actually it sounds quite easy but it isn't. I am sure one can find a way to accomplish but we should focus on stabilizing the current work and then head on, step by step. I agree, that this is a very useful improvement. As usual it helps to have numbers to support such changes, thanks wolfgar.

Quote:In fact, there is at least one drawback : the fb has to be RGB but as the g2d uses the memory bus in a far more efficient way than IC, my tests tend to show, it is still a good deal...
Anyway, again, fully open to speak about this ..

For progressive rendering, yeah, very fast. But unfortunately it breaks de-interlacing with double rate in HD. We could think of dynamically reconfigure fb1, but all that looks so hacky. Why can't there be a simple API that just works? Why do we have to deal with numerous APIs for different settings and find the best combination to get the maximum performance out of it? That is actually annoying! And the fastest rendering path is again with a binary blob (gpu-viv-g2d), gotcha!

(2015-02-16, 20:19)smallint Wrote: [ -> ]

Quote:In fact, there is at least one drawback : the fb has to be RGB but as the g2d uses the memory bus in a far more efficient way than IC, my tests tend to show, it is still a good deal...
Anyway, again, fully open to speak about this ..

For progressive rendering, yeah, very fast. But unfortunately it breaks de-interlacing with double rate in HD. We could think of dynamically reconfigure fb1, but all that looks so hacky. Why can't there be a simple API that just works? Why do we have to deal with numerous APIs for different settings and find the best combination to get the maximum performance out of it? That is actually annoying! And the fastest rendering path is again with a binary blob (gpu-viv-g2d), gotcha!

Damn, you are right about doublerate
I fully share your remarks, why not a single good working path ! Frankly this 16 pixels IC limitation is stupid as is the maximal output format which is not able to hold a fullhd frame (otherwise we would be able to directly stream from IC output to DP input !)
Then, lets go for dynamic fb configuration : I push it with taking care of your review in a few minutes...

Quote:Then, lets go for dynamic fb configuration : I push it with taking care of your review in a few minutes...

In a few minutes? You need to manage a flag of the current configuration, Clear(...) needs to be aware of that as well as other format dependent functions. I am curious to see that happen in a few minutes, hehe.

Here is a build with the 352Mhz patch and the rendercapture code include and diverse fixups: https://dl.dropboxusercontent.com/u/5572...0bad1e.tar

Everything is build from: https://github.com/fritsch/OpenELEC.tv/c...imx-master

Edit: Handle with care - I don't want to take any guarantees with the 352 Mhz fix.

Edit2: For the deinterlace people. Here is a build without the g2d changes, but including the 352 Mhz fix: https://dl.dropboxusercontent.com/u/5572...87c335.tar

First tests:
1080p50 works quite good
Deinterlacing is slower as before, the 25 fps variant still works okayish

(2015-02-16, 22:59)smallint Wrote: [ -> ]

Quote:Then, lets go for dynamic fb configuration : I push it with taking care of your review in a few minutes...

In a few minutes? You need to manage a flag of the current configuration, Clear(...) needs to be aware of that as well as other format dependent functions. I am curious to see that happen in a few minutes, hehe.

Ok maybe the whole night then
I only wanted to say I prepare the proof of concept ...
It should not be that hard as changes I had to push to switch from UYVY to RGB were not that big (OK I forgot about the clear method but still the magenta background was so nice lol)

Tried the latest image.

I have an I2, so I don't think VPU352 will do anything for my device. Seeing ~20 frames per second and a lot of skipped frames with deinterlacing enabled. Tried devmem 0x020e0018 w 0xffff007F but that didn't appear to do much.

Hi,

I have updated my branch (https://github.com/wolfgar/xbmc/commits/...dercapture) with dynamic fb configuration
Now deinterlacing works exactly the same as it was used to before I push any changes
rendercapture is implemented and rendering progressive content is more efficient

There is the drawkback of additional dependency on g2d library but really it seems a good option for rendercapture
Also, it is the same license agreement as the one we have to accept to use EGL and opengles. So even if I fully share the comments and concerns I don't feel it is really worse from a maintainer and packaging point of view...

Wolfgar

(2015-02-17, 00:55)zaphod24 Wrote: [ -> ]Tried the latest image.

I have an I2, so I don't think VPU352 will do anything for my device. Seeing ~20 frames per second and a lot of skipped frames with deinterlacing enabled. Tried devmem 0x020e0018 w 0xffff007F but that didn't appear to do much.

the devmem settings will only allow to avoid black transient screen if you experience any, it will not help with your jerky deinterlacing...
Now I will run a few tests with solo to tell you what is achievable with this kind of board.
To me, the improvement we alluded a few messages ago could be the way to bring you proper deinterlacing but I am not sure and have to test before giving too much hope...

Regards

(2015-02-17, 00:55)zaphod24 Wrote: [ -> ]Tried the latest image.

I have an I2, so I don't think VPU352 will do anything for my device. Seeing ~20 frames per second and a lot of skipped frames with deinterlacing enabled. Tried devmem 0x020e0018 w 0xffff007F but that didn't appear to do much.

The codec screen is absolutely _no_ benchmark. Only open it every 10 seconds and just shortly look onto the fps - the codec screen will exactly do what this new architecture tries to avoid - blend the gui ...

Example:
720p50: rock solid 50 fps when only opening the codec display very short. Arround 35 fps when keeping it open.
1080i50 HD+: Rock solid at 25 fps with IMX_FAST_MOTION. Arround 22 fps when keeping the codec osd open.
1080i50 mbaff: Rock solid 50 fps with IMX_DOUBLE. Arround 22 fps when keeping the codec osd open.


@wolfgar @smallint we need something similar like: https://github.com/popcornmix/xbmc/commi...d1d5b1c42f

(2015-02-17, 03:23)wolfgar Wrote: [ -> ]Hi,

I have updated my branch (https://github.com/wolfgar/xbmc/commits/...dercapture) with dynamic fb configuration
Now deinterlacing works exactly the same as it was used to before I push any changes
rendercapture is implemented and rendering progressive content is more efficient

There is the drawkback of additional dependency on g2d library but really it seems a good option for rendercapture
Also, it is the same license agreement as the one we have to accept to use EGL and opengles. So even if I fully share the comments and concerns I don't feel it is really worse from a maintainer and packaging point of view...

Wolfgar

Thank you very much. We already packaged this g2d for OpenELEC. I will do another build with your updated code.