Kodi Community Forum

Hi

I open this thread so that we can exchange regarding the ongoing development of deinterlaing on imx6 and continue the discussion from the github issue : https://github.com/xbmc/xbmc/pull/5805
Note it is for dev only, do not come in to ask about compilation issues or that kind of stuff...

Stephan

I had an account already! OK, I am in.

Yeah, I am also in. Thanks for making that thread.

What about the following roadmap:
Wolfgar is reviewing the patches as they are now, taking care if he likes the naming scheme of the classes, structs and if he is okay, he decides on what to squash down together? So that this can go in directly after helix is out.

Concerning the "double rate" feature" I would add that as separate Deinterlacing Method ? Like we have Deinterlace (Half) and Deinterlace (Full) now with the yadif filter?
The lowmotion I would keep as is - disabled.

I think the performance things are most likely kernel things for now, right? Who could we ask to have a thourough look there?

Do you two have any idea, btw. of the screen not getting updated anymore when we switch refreshrates? This bugger we currently have in all our mainline versions. That would be nice to get fixed for helix. I think it's some race between render and Decoder::Release, so that some surfaces are not deleted and stay there forever?

I found already a problem in buffer organization and would like to sort that out before a detailed review. That could also fix the LOW_MOTION artifacts we observed.

Regarding the black screen: decoder buffers are just DMA allocated memory chunks. If there would be a race or buffer leak you would very quickly run out of buffers and see that in the logs. Is that the case for you?

I have that black screen issue only from time to time and did not care that much. I think that is related to the video mode switching itself but did not investigate further.

Hi,

I am fine with your roadmap Peter.

Just a few remarks regarding the current state:
* It seems that a consensus has recently being reached : Using the VDIC enables for such a good quality that it is worthy to rely on it rather than exploring the backup with bobbing ,right ?
* The performance is good enough for any SD stream
* The performance is enough or not depending on the HD streams.
We have identified several improvements :
- The improvement with custom splitting which is in fact the same as the one brought by the quick and dirty patch I shared in https://github.com/xbmc/xbmc/pull/5805#i...t-65339619 post. It structurally ensures that the IPU IC block will use 16 pixel per burst and not 8 pixel per burst.
- Increasing the VPU priority on AXI bus also definitively helps
- The VPU@352Mhz helps (what are the effective drawbacks has to be analyzed further. To me it is at least safe in the sense that there is no risk to damage hw)

The benchmarks with mmdc_prof show that the bus bandwidth remains a key to the current issue.
So looking for low level configuration (ie in kernel) that can help can be useful for sure.
Unfortunately, the 16 pixel limitation is definitive : It is not a generic limitation of IDMAC but it is an IC channels limitation.
They can structurally only serve 8/16 pixel per burst : The keyword to search in imx6 RM to get it is : BURST_16
Maybe digging the IDMAC_LOCK feature or other qos related settings can be useful
We have just ping Jon who could have very valuable hints regarding this status

I also have a long term mitigation plan that should enable to have perfect behavior for any HD stream. My first attempt to explain it was not successful because there was a misunderstanding : I had not explained properly it was a long term exploration and not an immediate fix. Also, some objections which were not really related to this path were submitted adding noise to the exchanges. So I am currently writing a proof of concept based on smallint's testapp so that we can confirm (or not) the idea is worthy to explore and we can have constructive exchanges based on this basics...

At last, regarding the black screen, I don't know neither for sure. I suspect IPU is fragile when its output is reconfigured or a race in kernel. Do you have a way to reproduce quickly the issue (because it is my main issue to investigate : It happens very rarely in my env)

Regards
Stéphan

Thanks very much for that detailled analysis.

I am fine with whatever way you two will be going - cause (if smallint would check his mail), you are the maintainers of this code path. If the new way affects other architectures, we need to discuss that, of course. I think the bobbing is still an "additional possibility" to get short term results, but it's nowhere near as good as a fully working deinterlace path, that just works for the content we want.

I also think the future work is mostly kernel specific code, that will optimized throughput, to win some ms in those operations. Edit: to get the current code path going. I don't have insight yet on what you are planning - so it might be a software optimization, too with a new upcoming architecture.

The issue:
It's not a blackscreen. It's just that you continue to see the menu screen, hear the sound of the video, but screen does not updated anymore. Reproducing: Set your refreshrate to 50hz and start a 24p movie with adjust refreshrate to match video enabled. Do that 3 times, starting, watching for 10 seconds, stopping. Then it should happen directly.

Thanks much for coming up with that plan!

I pushed some changes and fixed a double rate issue. Currently it is enabled for SD only. One thing I noticed is a slightly bumpy picture (looks like if it offsets one scanline for the intermediate frame).

While testing with the burosch sample I found that some pts' are just missing (already from videoplayer) which gives a jerky result. ffprobe shows:


So I presume it is just a bad file and we cannot do anything about it, can we?

Burosch is a benchmark sample since several years. FernetMenta and popcornmix added code to xbmc to also get such files running more or less smoothly. I think this is something we need to cope with, especially in a live tv environment.

Concerning the jumping, do you see that at the first an last line? Then this could be a bobbing artifact, as the mixer "might" produce one frame per field, but I am not sure.

First, thanks to everyone involved with deinterlacing on the Cubox-i/imx6 platform!

I have a Cubox-i2 and I'm running Openelec 5.0 RC2 which pulled in PR5805 as well as changed the bpp from 32 to 16 in uEnv.txt. I use MythTV as the source for my liveTV. While watching 1080i60 content (boring old CNN on Charter cable) and enabling deinterlacing the playback was very jerky. The performance overlay showed a lot of skipped frames (like every other frame it seemed like). Eventually Kodi crashed with his error in the log:

ERROR: ReleaseFramebuffer: vpu clear frame display failure: ret=2

Looking at the features of the Cubox-i2 compared to the i4pro, I note that the i2 has a GC880 and the i4 (and several others) have a GC2000. The i2 is only supposed to be able to playback 1080p and 30fps vs 60fps for the i4. Is the deinterlacing work only for the GC2000 based devices, or should it eventually work on the GC880 as well? Based on the discussions, it looks like some methods are already pushing the limits of the hardware, memory bus, etc.

Hi zaphod,

If my current understanding of the issue is correct and if bandwidth is an issue then cubox-i2 will certainly have limitations as the memory bandwidth is significantly lesser than cubox-i4 (data bus is 32bits instead of 64bits and frequency is lower)
But for now, as you can read, we are still investigating and improving things so I cannot say that it is definitively impossible for cubox-i2 even if it will be obviously even more challenging

Regards
Stéphan

Thanks for the quick response and all the hard work! I'm trying to decide if I buy the CuboxTV when it is available at the end of the year. It is the same as the i4 but doesn't have the wireless or bluetooth that I don't need and is $99 instead of $139.

From a document I found, the gpu* performance itself is only 50%: http://cache.freescale.com/files/trainin..._T1025.pdf (page 51).

I think compared with current state of the GC2000, 1080i50 might never work on the GC880.

* was not so clear with "gpu" in that context.

Looking at that PDF, other than the differences between the GC2000 and GC880 (memory size, clock speed and 32bit vs 64bit) the quad-core chip also has a GC355. Not being familiar at all with the decode or deinterlace code, I don't know if that piece of hardware is even used?

We can compare real world performance, when you use the samples posted over at the github thread and share your findings with us.