1080i deinterlace issue

[Gobam]

Interlaced HD videos (1080i) are not properly processed using the existing deinterlace options in XBMC GUI. All the existing options are causing high frame drops/skips. Same videos are working properly in other platofrms (Raspberry Pi, ION). Thanks!

[wolfgar]

Hi,
You are right,
Thanks for opening this ticket so that we will properly track this remaining issue...

[Ryo99]

Do this commits to master-pr fix this issue?
3862644
e384ec1
5daa4b1
091b6e8

[smallint]

No. Deinterlacing of HD streams suffers from either limited memory bandwidth or bad implementation. I have now my Cubox with an up-to-date kernel up and running and will continue to work on this in future. If the latter is the case I have already some initial work in place towards an additional mixer thread that could help. In case of hardware limitations (VPU/IPU/GPU utilization) we have to test other options. Stephan already proposed some kernel tweaks but all this needs time and proper testing.

[susisstrolch]

@smallint - can you state more precisely what you mean by "up-to-date kernel"?

[piotrasd]

any progress with deinterlace issue ? for now i think this is the biggest problem :(

[jillesv]

It is like there is no interest in solving this issue. For me it is also very important that 1080i Live TV playback is working. That is why I bought this device in the first place. My raspberry was not powerfull enough to play the 1080i stream. I thought this device was powerfull enough, but now there are other issues that prevent to watch Live-TV. This issue is also not on the known issue list for Openelec and Geexbox... I don't understand why... I think it is really important.

[koying]

@jillesv Your priorities might not be the priorities of everybody...
I personally don't care for instance, and the devs who care may have more important issues at hand.

[rabeeh]

Maybe someone can shed some light on where the bottlenecks are?
Previously smallint mentioned it either suffers from memory bandwidth or bad implementation; anyone can provide more details?
jillesv - for completeness; i suggest you provide a link for a test 1080i content to benchmark against.

[jillesv]

Link to test TS 1080i file: http://jillesathome.nl:5050/fbsharing/lwHy0Rta

[wolfgar]

Hi there,
@jillesv : first you are right, the issue is annoying for liveTV use case and is definitively real.
This thread is about it, so there is no attempt to hide it. But maybe distro should stress it and link to this place...
I understand that you might be frustrated and would like that this issue is already solved but you also have to understand that people who contribute to the development are not the vendors of imx6 devices and do it for free during their free time. So things are sometimes slow to happen
@rabeeh, in fact issue is that
decoding a frame + deinterlacing it (using IPU which has to split it in several blocks because of the vdic resolution limitation) + rendering is sometimes longer than a frame duration hence the jerky effect.
We are not very far from getting it to work smoothly so before changing significantly the current implementation we wanted to check whether tweaking AXI priority (indeed the deinterlacing requires additional memory bandwidth) can do the trick.
If it is not the case, then we would have to change the implementation : Today deinterlacing is performed in the rendering thread and delays the rendering of the frame.
We could try to improve it by having a scheme where, in nominal case, during a frame duration :
frame n+2 is decoded
frame n+1 is deinterlaced
frame n is rendered
Of course at the end we still have to do the 3actions during a frame duration but here we could deinterlace and render at the same time (to the extend of common hw resources of course) while in the current way of working, they are purely sequential operations. So conceptually it could work, but implementing requires a good synchronization and can be tricky...

[jillesv]

Wolfgar,
Thank you for your explanation!

[piotrasd]

so we waiting for fix :) is good to know there is hope :)

anyway i was testing last time - latest build and deinterlace for SD also i no perfect,
picture is not smooth like without deinterlace, when you watch you can feel in like little drop frames or jerky

[wolfgar]

yes there is hope for sure ! ;)
For SD, in fact there are 2 different algorithms : Try to select one instead of automatic, you may have better behavior..
Also what is your board ?

[piotrasd]

MatrixTV v2.1 and i was used latest MatrixTV os v1.0.0.9 and also latest openelec.
(and compiled myself openelc with latets xbmc imx6 master branch)
About algorithms you mean half and full deinterlace from video settings in xbmc ? i was try both.
efect this same ....jerky picture is maybe to big word, but this is special visible when example some text
scrolling,example: some end subtitles of movies or some info bar down of picures on some news program. Without deinterlace eveything is smooth, i can record some samples for for test.

[wolfgar]

Yes I alluded to half an full deinterlace from video settings.
In fact these are xbmc naming but these 2 algos are wired to 2 different configuration of the vdic motion engine. That's why I suggested to try both : one should behave better for fast motion scenes...
OK we will try to improve this

[wolfgar]

@piotrasd : you should have received a mail from me

[smallint]

Sorry for my long absence. I am currently setting up a build environment on my cubox with Archlinux and xbmc compiled already. I am going to look into the deinterlacing issue and will try different methods to test and improve performance. This is scheduled for Monday.
@wolfgar: Should I fork master or is there a better branch to use in terms of the upcoming PR? I think we will need to include new enumerations for deinterlacing with better string representations. The more easy possible merges later the better.

[wolfgar]

@smallint : Nice to see you back !
As you have seen I have removed the deinterlacing support from initial PR in order to add proper imx dedicated values (in the enum) and I though it would be the opportunity to work on this remaining issue before pushing it upstream...
If you want to have a look, you are very welcome of course
I would advise to start from imx-pr branch as it is the candidate from the upstream PR...

[smallint]

I have tested deinterlacing with a dedicated mixer thread that does deinterlacing in parallel to decoding and rendering. The results are not very promising but I will investigate further. The synchronization itself is quite tricky and once this is stable I will do more tests on performance. What I can say is that the performance with my old kernel (3.0.xx) on the Wandboard and the Yocto build was much faster. Not sure if the kernel frequency setting did the trick before.
The hardest part is to do proper logging of all threads to analyze possible bottlenecks. Stay tuned ...

[wolfgar]

HI Jan,
Yes this way of working was expected to be tricky : Especially if we come to wait for deinterlacing to submit a new picture then the whole way of working is useless

Regarding your performance, I am unsure about the root cause :
Maybe the kernel config CONFIG_MX6_VPU_352M ?
or
maybe there are deeper changes in IPU driver for new kernels (I have not checked, I had a good understanding of the 3.0.35 driver because I had to look at it to remove the flickering lines but I don't know if major changes were introduced in the >3.10 kernels)

Take your time, as I know you are working on it there is no risk of duplicate work and do not hesitate to tell me if I can help in any way...

[smallint]

Currently I still need to figure out how exactly the sychronization performs. I am going to build a dummy deinterlacer (e.g. sleep(30ms)) and check if the playback is still smooth. If so I can assume that both pipelines are really parallel and do not block each other, the output should be in the interval of the maximum processing time (VPU or IPU). Once I introduce the real IPU and the performance drops dramatically it is likely that we are dealing with hardware limitations.

Take my word that I am continuously working on that during the next weeks and will let you know how things are going.

[cmichal2]

I recompiled the Geexbox kernel with CONFIG_MX6_VPU_352M, and it makes a big improvement. It doesn't completely fix the issue, but obvious glitches in 1080i videos are much less frequent than without it.

[piotrasd]

maybe kernel 3.14 resolve some problems

[wolfgar]

@cmichal2 : Thanks for your feedback : Which board and which kernel do you use for your test @352m ?

[cmichal2]

I'm using a Cubox-i4. The kernel is 3.10.30 from geexbox-devel

[wolfgar]

Thanks a lot, I asked because contrary to the 3.0.35 version, the 3.10 freescale kernel seemed to ignore this configuration option...
Thanks for your answer, I will have a deeper look at the 3.10.30 kernel used by geexbox for cuboxi...

[cmichal2]

You know, I went grepping through the source, and I couldn't find anywhere that that configuration option actually affected anything. But honestly, it does seem to make a big difference.

[wolfgar]

hehe the same from my previous look at the source (while in 3.0.35, this config was clearly taken into account through code)
For 3.10, maybe there is something hidden/correlated with dts when we select this option, I will check

Anyway, many thanks for confirming that it has the expected effect ! (even if not yet enough any improvement is good at this stage...)

[cmichal2]

I'll be interested to hear if you can find any effect of that config option. I'm a little unsure now of what's going on. After xbmc (and tvheadend) have been running for a day the glitches seem to be more frequent again. I tried each kernel, and immediately after booting it does seem as though with the clock speed option it is better, but I'm not that confident. Could there be a memory management aspect to this?

[smallint]

Funny, while I am working currently on the deinterlacing issue I came to the conclusion that the IMX6 is not powerful enough with current kernel configuration (3.10.30, ArchLinux) to run VPU, IPU and GPU at the same time with 1080i. This is either related to limited memory bandwidth or that the IPU is stalling the VPU. Thats why I wanted to apply the CONFIG_MX6_VPU_352M option as well. But checking the sources I could not find any place where this option is used at all. So from my understanding this option cannot change anything unless there is some real magic done.

I am about to publish some numbers soon. What I would like to have is a small performance test tool built with the XBMC libraries to decode and process a stream using the IMX6 codec. Does there anything exist somewhere?

[rabeeh]

@smallint we had a fix ages ago for LK 3.0.35 to improve IPU to DDR internal buses quality of service. Can you please check that register by -
devmem 0x020e0018
If you want to get best QoS for IPU then try running -
devmem 0x020e0018 32 0xffffffff

@wolfgar Please look at LK 3.14.14 too. It performs way better on the i.MX6 hardware. Jon Nettleton and RMK had added lots of fixes for CMA, GPU, IPU and one featured that boosted the performance on HummingBoard-i1 (the single cpu) was BFQ scheduler that boosted the performance to decode 80Mbps h.264 content.

[smallint]

@rabeeh The performance does not seem to be related to the IPU which processes fine within given time frames but the VPU. Its performance decreases significantly if IPU is active and the decode times are not fitting anymore into one frame (40ms for 25fps). So we need to find a good balance for the two.
Is LK 3.14.14 already available as PKGBUILD for Arch?

[pepedog]

Not in official git or repo
http://myplugbox.com/new/ source plus pkg there
I am having trouble booting hbi1 with it

[smallint]

Thanks a lot, I will try it out. Btw, what is hbi1?

[rabeeh]

@pepedog Only LK 3.14.x has a good support for HummingBoard.
@smallint hbi1 is HummingBoard-i1 (i.e. HummingBoard carrier board with MicroSOM with solo i.MX6 MicroSOM.

[smallint]

Is the current firmware compatible with LK 3.14.x or to put it in other words: can I just replace 3.10.x with 3.14.x and it should work?

[pepedog]

With arch it is comparable.
Remember arch has very few -dev or -devel packages, their bundled with main pkg (xorg-server-devel is notable exception).

[smallint]

@pepedog Thank you very much. I have already recompiled the current kernel on Arch, so no issue at all here. XBMC also compiles fine. I just want to replace my kernel with your package and check the performance difference.

[pepedog]

Will be interested if you can point out any improvements @smallint

[wolfgar]

Hi there,

@smallint : I have sent to you a private email with additional detailed data regarding the way to configure qos for the different blocks

Unfortunately, here we use IPU for 2 different use cases : first one to use DP and to display the fb on the HDMI interface, the other one to use VDI block to deinterlace our fields
But we have a common qos (well at least for read... write should only be used by vdic I think)

@cmichal2 : Apart from the CONFIG_MX6_VPU_352M option, have you changed other options compared to the default geexbox configuration ? Especially, have you changed the CONFIG_PREEMPT config ? I ask because I cannot find how the option VPU_352M would be handled and I wonder whether another option would be responsible for your improved behavior...

[cmichal2]

I enabled highmem, and heavily patched the au0828 tuner driver, but that's all. And those changes are the same in the two kernels I'm comparing. It is possible I imagined the improvement - I'll try to do a better comparison of the two kernels sometime in the next few days, will test Rabeeh's suggestion of setting the ipu qos register as well.

[wolfgar]

Thanks for your answer
As smallint rightly explained, it is not only about the ipu qos : His tests prove the required time for VPU to decode a frame significantly increases when IPU is in use in parallel. As the most obvious common resource is memory bus, it is possible that, on the contrary, ipu priority is too high at the moment
Just to give some additional feedback regarding the Rabeeh suggestion : In fact forcing all IPU accesses to max prio is especially useful when you experience underrun : ie when stream does not arrive on time to be displayed and you loose HDMI sync (the effect is your screen turns black for a moment).
And it was all the more useful when I did not use the GPU to combine video and GUI but used the DP in IPU to do so. At that time 2 streams had to arrive on time to be combined on the fly and displayed...

[smallint]

Here are two plots showing the processing times of an 1080i stream. The first figure is with GPU active while the second is not (frames are not rendered). You can easily see at the first figure how the green plot (VPU decode times per frame in ms with IPU active in parallel) is mostly above 40ms while the red (VPU decode times per frame in ms without IPU active) is much below this limit. The IPU performs fine and is very well below the limit of 40 ms.

This figures are for LK 3.10.30 on a CuBox-i4Pro under ArchLinux.

[smallint]

I checked with LK 3.14 and the overall situation has not improved. The figures are almost the same ... the deinterlacing plot seems smoother now and the mean is also a bit lower. So deinterlacing improved with that kernel.

[smallint]

Regarding LK 3.14: some CEC patches are probably missing. I cannot use my remote anymore after restarting XBMC. Only reboot deactivates it. This is never an issue with 3.10.30.

[cmichal2]

@smallint, do you see any difference if you set bpp=16 vs bpp=32 in uEnv.txt ?

[smallint]

I haven't checked and my current setting is bpp=16. Do you think it would run faster? bpp=32 seems to need even more memory bandwidth than less. But anyhow, it is worth a try.

[cmichal2]

It looks to me like bpp=32 is worse, but I'm learning not to trust my eyes. It would be interesting to have numbers.

[cmichal2]

Baby step: in 3.0.52, setting CONFIG_MX6_VPU_352M does a number of things: sets a couple of voltages to 1.25V rather than 1.175 (pu_voltage, soc_voltage), also disables bus frequency scaling, changes the cpu frequency and the vpu frequency. It looks like all of these settings are now exported in /sys

For example, /sys/bus/platform/drivers/imx6_busfreq/busfreq.13/enable lets you turn bus frequency scaling on/off.

It looks like the voltages can be changed on the fly in /sys/bus/platfor/devices/soc.1/2000000.aips-bus/20c8000.anatop/regulator-vddpu.9/regulator/regulator.5/microvolts (and regulator-vddsoc.10/regulator/regulator.6/microvolts).

The clock frequencies appear to be in /sys/kernel/debug/clk/osc/pll2_bus but I haven't figured out which is which (help!)

Searching the 3.0.52 source for VPU_352M shows the things it touches - not all of which are totally transparent to me. But presumably with the knowledge of what that config option does we could just set the settings in /sys to reproduce the effect of the old CONFIG_MX6_VPU_352M configure option.

There's a little information here: https://community.freescale.com/thread/309304

[smallint]

@cmichal2 I was thinking af something like that after checking the current sources. Since the option has no real effect the VPU frequency must be changable either on the fly or via a kernel parameter (unless disabled at all). Wolfgar told me already how to increase the memory qos parameter for the VPU and it already helped along with other code optimizations to increase the deinterlacing speed. But unfortunately we are still not able to decode, deinterlace and render a 1080i with 25 fps. I was able to show that VPU and IPU can work together within 20ms but a soon as the GPU comes into play the whole things breaks down and we are slightly above 40ms. For sure the old v4l way was much faster but comes with other drawbacks in combination with XBMC (3d, subtext, ...). This stuff is harder to solve than I thought in the beginning. ;) And we are still far away from double rate rendering for HD ...

P.S. Again, LK 3.14 did not help at all to improve the speed. I tested two days all kind of combinations without break through. Btw, got anyone Gstreamer running under Arch to test playbacks? I was not able to install the required plugins ... probably haven't tried hard enough.

[cmichal2]

Can you let me know what you did for the memory qos parameter?
The frame rate target is probably harder than you think. For ATSC in US/Canada, OTA 1080i is 30 fps.

[smallint]

@cmichal2 This is what wolfgar sent me and it worked nicely:

devmem 0x00c49100 w 7
devmem 0x00c49104 w 7

The gives the VPU memory read and write highest priority.

I have also tested a small Canadian stream with 30 fps some time ago and it worked better. Probably the encoding was different to the German 25 fps streams. But we need a lot of tests to figure out the best settings if there are any eventually.

[smallint]

Here comes another plot for VPU/IPU/GPU after some optimizations and the above devmem settings. It is looking better but some frames are skipped for rendering which might explain some of the big jumps in decoding times.

[smallint]

@pepedog Can I use the package linux-imx6-cubox with LK 3.0.35 on my Cubox-i? I am currently running linux-imx6-cubox-dt with LK 3.10.30. I would like to test the older kernel.

[pepedog]

Yes, they all work, and don't conflict, uboot will take zimage first, if present so rename it, or remove the -dt pkg
That 3.14.14 kernel I pointed out to you, sound works but can't boot on hummingboard i1. If I use the recommend default sound stops on hdmi, but hbi1 boots

[cmichal2]

I asked in the freescale forums about CONFIG_MX6_VPU_352M, and got a very helpful response. It looks like they added the patches for this feature back recently (June). I picked up three patches:
ENGR00320349
ENGR00317861
ENGR00313202
from: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.10.31_1.1.0_beta
and applied them to the geexbox 3.10.30 kernel. Now dmesg tells me that:
VPU 352M is enabled!
mxc_vpu 2040000.vpu: VPU initialized
remove 396MHz OPP for VPU running at 352MHz!
increase SOC/PU voltage for VPU352MHz
I'll be very interested to hear if it makes any difference to your measurements.

[smallint]

Guys, to say it in wolfgars words: there is hope!
I reactivated my Wandboard running LK 3.0.35 and tested the current implementation and 1080i@25 rendered smoothly without skips or drops. This Wandboard is running an overclocked VPU.

@cmichael Great, I will test that asap. Can I ask you for a 1080i@30 sample preferably with fast motions (ice hockey game)? I only have a commercial to test with and its boring ;)

[rabeeh]

@smallint do you know for a fact if that's because overclocking the vpu or because cpu freq scaling is disabled (i.e. you are probably running at 1.2ghz)?

[smallint]

@rabeeh No, I don't know. I have to do further tests. But I can say that I have just enabled the 352M config option in the kernel and thats it. No clue if the box is running with 1.2ghz. I can provide any information you need, just tell me. Memory benchmarks have shown that the Wandboard memory throughput is less than the Cubox-i with the latest official Arch kernel but the rendering is slower on the Cubox-i. At this stage I cannot interpret that observations.

[rabeeh]

i suggest then you go back to 352M patch disabled and perform the following -
cat /proc/cpuinfo
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /proc/cpuinfo (yes - again)

please notice the bogomips; it's two times the processor currently running frequency. For instance with 1.2ghz you should be seeing ~2400 bogomips
that's ofcourse only true on LK 3.0.35

changing the scaling governor to performance will force the processor to be at it's highest speed regadless of the workload

[smallint]

The BogoMIPS I checked yesterday were 1988. On the Cubox-i instead 790 (even if xbmc is running). After putting some stress on the box they increased also up 1988.

[cmichal2]

@smallint I'll look for a suitable stream for you. Is 10-15 seconds long enough? It may take me a day or two to get to it.

@rabeeh: with 3.10.30 or 3.14.14 scaling_available_frequencies top out at 996000. Should that go up to 1.2GHz?

[smallint]

@cmichal2 1min would be better because it always takes some time to start the stream and I need to test skipping as well. But I take what you have. Thanks.

[smallint]

I checked with VPU at 352Mhz (Cubox-i, LK 3.10.30) and it is not better ... going back to 3.0.35 on that box and trying again.

[wolfgar]

@cmichal2
afaik not many imx6 based board really go up to 1.2Ghz
In fact imx6Q max frequency is 1.2Ghz for a given reference (the MCIMX6Q5EYM12AD) but other imx6Q references are qualified for 850Mhz or 1000Mhz only : have a look at freescale site, you have real figures...
Edit : ho and thanks for pointing patches for kernel > 3.0

[smallint]

I tested LK 3.0.35 with the Cubox-i and the situation improved. The playback is not perfectly smooth (not yet running with overclocked VPU) but there are very few skips. It seems that VPU, IPU and GPU are better balanced. And performance improved as well, check the figure.

[wolfgar]

@smallint could you diff the kernel configuration please ?

[smallint]

The configs are https://raw.githubusercontent.com/archlinuxarm/PKGBUILDs/master/core/linux-imx6-cubox/config and https://raw.githubusercontent.com/archlinuxarm/PKGBUILDs/master/core/linux-imx6-cubox-dt/config.

The diff is quite large so it is better to do it locally yourself.

[smallint]

After some code cleanups I will push my current testing branch that you can try it yourself. Probably it is related to my configuration and the Arch configuration itself.

[wolfgar]

Thanks a lot @smallint, could you also share your wandboard 3.0.35 config that works fine please ?

[cmichal2]

@smallint, I have a clip for you. If you send me an email, I'll email you a link.

[smallint]

@wolfgar https://raw.githubusercontent.com/smallint/meta-jabe/master/recipes-jabe/linux/files/defconfig except that CONFIG_MX6_VPU_352M=y for the running kernel.

[rabeeh]

@smallint do you have a CuBox-i or HummingBoard?

[smallint]

@rabeeh CuBox-i4Pro

[smallint]

@cmichal2 Although I don't like that beer the clip plays smoothly on LK 3.0.35. Also my test clips render almost smoothly with triple buffering enabled. Again: there is hope!

[smallint]

I added the branch featdeintrework for testing.

[cmichal2]

To provide some feedback on this. I applied the changes in the featdeintrework branch to the xbmc version used in Geexbox (only a little manual work on a few rejected hunks) and have been using it for a few days. I'm still using the 3.10 kernel so I don't expect perfection. It feels to me like it is much better. I do still see occasional stutters in what should be smooth movement, but it is relatively tolerable (certainly compared to the situation without these changes). I haven't noticed it introducing any new problems.

[smallint]

Thank you for the feedback. Yes, it should perform better due to the better parallelization. Are you running LK 3.10 with overclocked VPU or with default config? I am still not happy with the performance with my 25fps streams. I tried lots of combinations regarding kernel and OS but only 3.0.35 with older Vivante libs works perfectly on a Wandboard (I have no Cubox-i kernel for that build). I hope we can figure that out. But I am happy that you are able to watch your streams now in a relatively tolerable manner ;)

P.S. The codec logs a lot at info level. You should comment the PROFILE_BUFFERS define in the codec header to get rid of it.

[cmichal2]

Yes, I am using 3.10 with the VPU clock at 352MHz. Thanks for the pointer to get rid of the logs!
I just came across this thread:
https://community.freescale.com/thread/315369
where there is a link to a patch that is in 3.0.35, but not in the 3.10 kernel that I'm using. The patch is titled:
ENGR00261884 fix system hang when thumbnail or playback interlace clips
At some point I'll try to apply that patch to the 3.10 kernel I'm using and see if it makes any difference.

[smallint]

This patch is not in any of the kernels I am using.

[cmichal2]

I don't think that patch is relevant actually. The only call to the one function touched by the patch is commented out in 3.10.

[rabeeh]

@wolfgar / @smallint - will this be helpful -
http://pastebin.com/aPnfQ1Ed
?

Any one has content to test with?

[fritsch]

Here is content for testing:
https://dl.dropboxusercontent.com/u/55728161/1032_20130801154100.ts <- 1080i mpeg2
https://dl.dropboxusercontent.com/u/55728161/transformers.ts <- 576i mpeg2
https://dl.dropboxusercontent.com/u/55728161/deinterlacing-test.mp4 <- 1080i50 h264

[smallint]

@rabeeh This is @wolfgars patch for his Utilite kernel. Where did you get it from and why didn't you post a Github link but pastebin?

[Gobam]

Hi,
This is just to confirm if there is any advance in this issue. I installed latest OpenELEC version (5.0.1) but it still has problems with 1080i. Thanks!

[wolfgar]

The following PR fixes all "normal" 1080i contents : xbmc#6351

[wolfgar]

As a remembering, all development happens upstream now...

[fritsch]

@Gobam 5.0.1 did not have this rework at all ... 5.0.2 has -> still this is not a user forum

[smallint]

We should close this issue, shouldn't we?

[Gobam]

Hi,

Not sure if I am doing something wrong, but in my case 1080i deinterlaced is still not working. I am testing in a Cubox-i4P with OpelenELEC 5.0.2, which should include the fixes. I am attaching two small samples of 1080i video I am using:

https://db.tt/hkdjYEjO : Captured from 1080i source using Hauppauge HD-PVR2
https://db.tt/Zqs3DnjG: Captured from DVB-T2 TV channel using Tvheadend

In both cases video is really choppy, it runs like in slow motion, and audio is running at normal speed, so it's not syncronized with the video. This is happening also with LiveTV, which is a critical usage scenario in my case. Both samples (and same LiveTV channels) are working flawless in both Raspberry PI B+ and Intel-ION systems, both using the same OpenELEC version (5.0.2)

Please let me know if there is another Kodi version I can test with. Thanks!

[piotrasd]

im not sure if guys from OE apply this to build which is needed for good working deinterlace:

Recommendations for client setup:

enable VPU@352Mhz in kernel
setup 32 bit framebuffer in uEnv.txt (bpp=32)
disable console blanking in uEnv.txt (consoleblank=0)

[Gobam]

I can confirm that uEnv.txt parameters are correct:

mmcargs=setenv bootargs 'boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2 quiet video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 dmfc=3 consoleblank=0'

How can be confirmed that VPU@352Mhz is enabled in the kernel? Thanks.

[piotrasd]

no i was checked
from OE - imx6 project config kernel:

MXC VPU(Video Processing Unit) support
CONFIG_MXC_VPU=y
CONFIG_MXC_VPU_DEBUG is not set
CONFIG_MX6_VPU_352M is not set

[susisstrolch]

CONFIG_MX6_VPU_352M is a relict from older kernels.
There's no bit of code ifdef'ed by CONFIG_MX6_VPU_352M in imx kernel 3.14:
strolch@strolch:~/Development/OpenELEC/build.OpenELEC-imx6.arm-devel/linux-cuboxi-3.14-1f8e124>
grep -r "CONFIG_MX6_VPU_352M" .
./.config:# CONFIG_MX6_VPU_352M is not set
strolch@strolch:

On 02/16/2015 03:14 PM, piotrasd wrote:

no i was checked
from OE - imx6 project config kernel:

MXC VPU(Video Processing Unit) support

CONFIG_MXC_VPU=y

CONFIG_MXC_VPU_DEBUG is not set

CONFIG_MX6_VPU_352M is not set

—
Reply to this email directly or view it on GitHub
#70 (comment).

[smallint]

How can be confirmed that VPU@352Mhz is enabled in the kernel? Thanks.

dmesg | grep VPU

[smallint]

CONFIG_MX6_VPU_352M is a relict from older kernels.

There are patches to make that work again with >= kernel 3.10. I have my VPU running at 352 Mhz with kernel 3.14.

[susisstrolch]

Do you have a patchset against current kernel?

On 02/16/2015 03:30 PM, smallint wrote:

CONFIG_MX6_VPU_352M is a relict from older kernels.

There are patches to make that work again with >= kernel 3.10. I have
my VPU running at 352 Mhz with kernel 3.14.

—
Reply to this email directly or view it on GitHub
#70 (comment).

[smallint]

Check xbmc#5805, there is a post from @cmichal2 from Nov 30, 2014 linking to all required patches.

[fritsch]

Deinterlacing of 1080i50 content is fine for me, without that 352 overclock and overvoltage hack. I really don't like to force that frequency fixed and don't tell users, cause that might harm and if something gets broken, all start to whine.

@rabeeh did some rework with cpufreq - I think this dynamic higher clocking has more potential and is additionally more safe.

@rabeeh what do you suggest from a hw point of view? Clock to 352 Mhz fixed - what are the dangers when doing so? Which patches should distributions like OpenELEC ship to not put the hw at risk?

OpenELEC 5.0.2 ships the latest code done by @smallint but missing the RenderCapture code @wolfgar finished some days ago.

@piotrasd you are always the first whiner in such threads - why don't you just provide some builds for testing with the 352 Mhz patches in, the RenderCapture work and so on? It seems you have too much time.

[piotrasd]

@fritsch sorry i just checked recomended stuff for client setup which was in PR and only show difrents from openelec confs
im not compiled to test, because i dont have time ;)

[smallint]

@fritsch, does OpenELEC 5.0.2 work for your streams as good as the test build with Kodi master you did?

[fritsch]

@smallint: It works the same as kodi master. I only ported the patches that were needed to make it work correctly, see: https://github.com/fritsch/xbmc/commits/imx-rebase-pr

It was integrated into OpenELEC master already: https://github.com/OpenELEC/OpenELEC.tv/tree/master/projects/imx6/patches/kodi

5.0.x does not have this code.

[fritsch]

@piotrasd https://dl.dropboxusercontent.com/u/55728161/OpenELEC-imx6.arm-devel-20150206124358-r20205-gcf981bb.tar ...

[piotrasd]

@fritsch big thanks and sorry i caused frustrations in you ;(

[wolfgar]

I have to say I have run several imx6Q based product (utilite, cuboxi, tbs2910) with VPU@352Mhz for several months without major troubles (it was my own default 3.0.35 kernel config and has become mine with the mentioned patches for 3.14)
Also official freescale support states "There should be no significant side-effect for this config, but it may bring a little higher power consumption." (https://community.freescale.com/message/338488#338488)
So I am not so reluctant to use a VPU @352mhz as it opens the door to streams that cannot be played otherwise (carmen@60p sample for instance)
But it is a personal choice and I perfectly understand that a distro maintainer has concerns because he will be assaulted by users in case an issue occurs...

[fritsch]

@wolfgar: I trust you there fully. But I still wait for @rabeeh comment on this - to not put our users at risk.

I expect more "official" support in all those regards. Can't be that you and @smallint invest day and night to get things going ... Cubox as is is on the crossroad currently ...

[wolfgar]

Of course, no problem,
As I said I perfectly understand this approach
Rabeeh's advice as cuboxi hw designer is clearly relevant...
I only wanted to tell about my own experience (and I might be lucky lol), and about the official freescale post that states there is no risk but to consume more power...

I leave this thread open so that @rabeeh can come and express his point of view regarding VPU frequency for cuboxi products but as soon as this exchange is finished I will close it and link to the current xbmc#6351 that fixes this issue...

[fritsch]

Here is a build with the 352Mhz patch and the rendercapture code include and diverse fixups: https://dl.dropboxusercontent.com/u/55728161/OpenELEC-imx6.arm-devel-20150216220652-r20288-g20bad1e.tar

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

Edit: Handle with care - I don't want to take any guarantees with the 352 Mhz fix.
Edit2: Here is another version with only the 352 Mhz fix, but the RenderCapture (g2d) reverted: https://dl.dropboxusercontent.com/u/55728161/OpenELEC-imx6.arm-devel-20150216223931-r20290-gd87c335.tar

[cmichal2]

I'll be interested too in hearing what rabeeh has to say about the VPU frequency, but to add a few bits more data: I've been running a cubox-i4 with the vpu frequency at 352MHz for ~ 6 months with no issues. I also did some measurements of power consumption and found only a tiny difference with and without the patch (details in xbmc#5805).

[rabeeh]

As @wolfgar mentioned; vpu@352mhz can run without issues at all. The only bad impact it has is that it removes the lower processor frequency from the frequency scaling list; so when the processors are at idle they can't go to it's lower frequency state.
With that saying jnettlet had a patch to fix that too. I'll ping him to see what is the status of that patch too.

[fritsch]

@rabeeh Thanks much - if you can link that patch here, that would be great and we would pick it for OpenELEC
@sraue ping