[fritsch]

Now to the test streams (meaning Auto+auto deinterlacing settings):
All of mine (except 1920x1080i60, see below) and all of fritsch's test-streams (http://solidrun.maltegrosse.de/~fritsch/) work perfectly except
- if 720p50: showing codec-info triggers many frame skips
- if 1080p50: massive audio async, and slowed down video.

1080p50 is too much for this hardware. That will most likely never work.
50 progressive frames is also quite a lot - only open the codec screen from time to time for a very short time, it's not a benchmark. Perhaps we find a way to update those states only every 10 fps or something.

[bubi]

1080p50 is too much for this hardware.

Then I'm wondering what this marketing BS from Freescale means (http://www.iwavejapan.co.jp/product/iW%2...uction.pdf): "Dual HD 1080p decode, Dual 720p encode, single stream up to 1080p60, 50Mb/s"
Well, the doc even speaks of "1080p60 h.264 MVC decode". But it's an i.MX6 A9. Do we really have an A9 here?

Anyways, for de-interlacing my 1920x1080i60 sample should work, shouldn't it?
i60 ---(de-interlacing)--> 29.97p --> 59.94fps (playback on TV) ?
But it doesn't. Seems like it's handled like 1080p60 - my 1080p60 samples behave the same.
Perhaps some misdetection of a fully interlaced stream?

[fritsch]

They talk of "decode" - not display :-)

But others can answer that better. I have no idea, how this can be done with the memory that is integrated.

Edit: Post your Debug Log, post a link to your sample.

[bubi]

Some rebounds.
- I forgot to mention that text-rendering of the GUI is broken somehow. Fonts mostly look like they're bold. Not all lines and it changes when you e.g. scroll in a list. Codec-info somehow's pulsing bold and normal rendering while video playback.
- Settings-GUI of Confluence is flickering sometimes. Also sometimes shows some odd light grey overlay.
- tried forcing 23.976Hz for 23.976fps video via advancedsettings.xml. Restarted kodi. Got my HDMI-audio-dropouts on HD-audio back. Now it's even back with old settings and can't explain the reason.
Sorry for this unprecise report, I'll try to do more investigations.
- interestingly I'm doing nothing with Cubox the last +1.5h and cputemp constantly went up from 50° to now 65°C. WTF?
So, for further thorough testing we should all check what temperature the system has got atm to exclude any kind of core down-clocking? This is going to be tough.

But for this thread's reason, here comes the log about my 1920x1080i60 fully interlaced sample:
Sample(again): https://www.sendspace.com/file/h3znta
Log: https://www.sendspace.com/file/fk9lcw
(Hmm, doesn't this forum support attaching files?)

[fritsch]

Can you please disable CEC for testing. I see that erroring out quite often in your log, even mainloop blocking wise.

[wolfgar]

Hi,

Regarding temperature issue you mention.
First note that this core temperature is not dangerous.
Yet, it is surprising to have such behavior while you do nothing. May I ask you where (I mean on which screen) you let your box during this temperature increase ?
I bring your attention that on main screen the RSS feed alone can explain such a behavior...

About 23.976Hz, I am sorry, to my mind there is no way to configure a proper 23.976Hz output :
I am not optimistic because of a mention in HDMI audio clock computation which states
"All other TMDS clocks are not supported; the TMDS clocks divided or multiplied by 1,001 coefficients are not supported."
(Extract from §33.2.6.1 from iMX6Q RM)
So it seems to mean that even if we manage to set 24/1.001 pixel clock rate then we are unable to have proper audio clock rate...

Kind regards

[fritsch]

The xbian guys have a CEC idle patch, that hooks into Application.cpp and makes the render only update every 750ms when this mode is taken: Perhaps something for mainline: https://github.com/xbianonpi/xbian-packa...erV2.patch

[jimicr]

@bubi, what skin are you using? I have the same problem running Shednox. Confluence and normal nox keep my temp blow the 40C.

[bubi]

I'm using std Confluence. The odd thing is, that I didn't encounter this high temperatures with OpenELEC 5.0.0 or 5.0.1 distributions. This is entirely new.
The night AVR and TV was off/standby and CuboxTV was idle with an open ssh-session and loglevel=2 from advancedsettings.xml
Now I just checked cputemp, it's at 61°C, though TV & AVR is off?!
After turning the TV & AVR back on - Kodi is showing an idle Confluence - cputemp went down back to 37°C.
So, somehow power management works the other way 'round? Clocking down when it's used and clocking up, when idle?!

There seem to be bug in the component debugging settings however, because when I disable component debugging, the sub logging options line (- where I had activated CEC-logging) isn't chooseable, but somehow active, because I still have CEC-logging lines in the debug log.
fritsch, I'll try to generate another log without the CEC messages. I'll attach it, when finished.

> 24/1.001Hz
Thanks for investigating, wolfgar. Problem is, my TV just shows "24Hz" and I don't know if it's really 24.000 rather than 23.976. Same thing for 60<->59.94Hz.
I don't know much about this issue, and am going to check some more settings and videos.
I just thought, that Kodi could speed up 23.976 video frames to 24.000 and the HDMI-audio-clock also, which would result in synchronous 24.000fps. I vaguely remember that this HDMI1.3 Lip-Sync feature has got some tuning-option - but I could also be entirely wrong about this point. I'll have to read some more docs. But iMX6Q RM already stating a restricted number of (audio)clocks isn't quite encouraging.

[fritsch]

> 24/1.001Hz
Thanks for investigating, wolfgar. Problem is, my TV just shows "24Hz" and I don't know if it's really 24.000 rather than 23.976. Same thing for 60<->59.94Hz.
I don't know much about this issue, and am going to check some more settings and videos.
I just thought, that Kodi could speed up 23.976 video frames to 24.000 and the HDMI-audio-clock also, which would result in synchronous 24.000fps. I vaguely remember that this HDMI1.3 Lip-Sync feature has got some tuning-option - but I could also be entirely wrong about this point. I'll have to read some more docs. But iMX6Q RM already stating a restricted number of (audio)clocks isn't quite encouraging. Sad

Kodi can do that, yes. But not with bitstream audio. "The packets" 32ms don't tell anything about their content. With pcm audio we can resample it and you won't realize much.

[smallint]

"Dual HD 1080p decode, Dual 720p encode, single stream up to 1080p60, 50Mb/s"
Well, the doc even speaks of "1080p60 h.264 MVC decode".

The VPU (decoder) can handle this. The 1080p50 sample decodes with 16ms per frame which would be enough. But then rendering comes into play which increases the memory bus load due to more reads and writes. The average deccode+render time goes then up to 27ms which is not enough anymore. I don't know what we can do about that. There are probably still some more aggressive optimizations possible but all that should work in all cases. Is rendering 1080p50 a real use case for this box?

[bubi]

Thanks for the insight.
No, I don't think 1080p50 is really necessary. At least not for me - I don't know where fritsch's sample came from.
Just for me, I'd be happy already if all interlaced/prorgressive up to 1080p30 respectively 1080i60 videos would "just work" in conjunction with bitstreaming. What would be all kind of possible Blu-ray streams.
Though, additional GBbps networking would also be very nice for video starts, seeking etc. But that's an issue we could possibly track down later.

[fritsch]

That's a benchmark sample. That FernetMenta and I used for xvba development in 2011. That file is 5 fps lower the max an old AMD e350 can decode on its uvd.

There is a 60p dog sample somewhere a e450 can do. We used those for regression testing.

So for now 1080p35 and 1080i60 is the edge. The i60 also only at 30fps Fender I think.

[smallint]

Sample(again): https://www.sendspace.com/file/h3znta

I can't render that smoothly neither with vanilla kernel. Decoding takes already about 31ms (average) and with rendering the frame processing time goes up to 39ms which does not fit into 30 fps anymore. Using another kernel with VPU running at 352Mhz reduces the (average) decoding times to 25ms and (average) overall frame processing to 31ms. Nonetheless it can't be displayed smoothly probably due to decoding time or rendering time peaks. I would have to investigate further ...

[fritsch]

It seems the Broadcom chip on the Pi2 is a bit more capable in that regard. 1080p50 is no problem there.
One should clearly decide wisely when buying a cubox for kodi, cause of the known limitations.