[fritsch]

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

For what it's worth, I really like my cubox and it does what I do daily in a perfect way: LiveTV 1080i50. Additionally I have attached an esata HDD which serves the local network via its Gbit ethernet port, without heating up the environment.

When I want to watch bit perfect movies in 23.976 fps and bitstream passthrough I use something else.

</offtopic>

[wolfgar]

Hi

Regarding the issues with AXI priorities tweaking please try to use only the following setting :
devmem 0x020e0018 w 0xffff007F

Also I have good news : I have a first version of rendercapture that just works with good perfs.
Main restriction is the maximal downsizing cannot go beyond 8:1 ratio (it is a IPU IC restriction) but it works, I have to clean the code an will publish it this week

Kind regards
Stéphan

[fritsch]

@wolfgar:

Thank you very much. Then the PR would be complete and could go in directly.

[Memphiz]

That means we would get a problem i guess ( at least for fullhd resolution ) - boblight addon requests 80x80 pixels - what would happen in that case?

[bubi]

About my full-interlaced sample of Bizet's Carmen. Sorry for the delay. Here's the log without CEC-msgs, but extra ffmpeg- & audio-logging. I hope this is ok.
https://www.sendspace.com/file/qdb48s

Regarding broken/bold fonts:
I removed these following lines and the fonts and GUI look fine again.

<gui>
<algorithmdirtyregions>1</algorithmdirtyregions>
<nofliptimeout>1000</nofliptimeout>
</gui>

I just used this on my Carmen-sample:

devmem 0x020e0018 w 0xffff007F

Didn't help. Something weird's going on with this sample. It's just a sample from a Blu-ray + flac 5.1. No problems on a PC.

One should clearly decide wisely when buying a cubox for kodi, cause of the known limitations.

Yes, but the limitations weren't quite visible when most of us bought the boxes, just marketing lies like this: http://www.solid-run.com/cuboxtv/

When I want to watch bit perfect movies in 23.976 fps and bitstream passthrough I use something else.

Not very encouraging. Rather makes my :cry:

[smallint]

Regarding broken/bold fonts:
I removed these following lines and the fonts and GUI look fine again.

Oh yes, I forgot to reply on that one. Actually dirty region algorihtms 1 and 2 are broken due to some rework done on that one. Maybe it is fixed already, I haven't checked. I need to pull the latest master and merge it.

Yes, but the limitations weren't quite visible when most of us bought the boxes, just marketing lies like this: http://www.solid-run.com/cuboxtv/

I can understand your frustration and although I am not part of the Solidrun marketing team they said "a powerful GPU, and a VPU that plays almost any codec imaginable.". "Almost any" is not "Any". I would have been even more frustrated if I would have bought a box with a proprietary firmware that fails in playing some videos as it is the case with many TVs and I can't do anything about it but waiting for updates that never happens.

The issue we are having with your samples might be related to ffmpeg (as I see many entries in your logs) or your dump, hardware limitations or the wrong phase of the moon. I don't know and someone with more experience may enlight us here.

I can tell from my tests with your specific sample that the current Kodi iMX implementation is not fast enough to handle the output of ffmpeg fed into the decoder and renderer at 30fps.

Is your sample a raw dump of the blu-ray or did you convert it?

[wolfgar]

That means we would get a problem i guess ( at least for fullhd resolution ) - boblight addon requests 80x80 pixels - what would happen in that case?

Damn OK so the 8:1 constraint I allude would not be acceptable for fullhd as the result is simply a black thumbnail if you try to go beyond this ratio
I am currently reworking the whole thing to get rid of this limitation...
I have already a quick and dirty workaround implementing it as a 2 steps process to be able to reach 1:64 ratio instead of 1:8 (the second step deals with such a small image that it is almost free)
Before cleaning it up I am checking if I can have another path by using gpu2d for this operation
Really I would do anything to be friendly with boblight users

[bubi]

Is your sample a raw dump of the blu-ray or did you convert it?

It's a raw dump I extracted with eac3to. So all Blu-ray stream limitations should apply which are more restrictive than H.264 High Profile the chipset should be able to decode.
The only thing I changed is the audio track: DTS-MA -> Flac.
Checked mkvmerge v7.0.0 and mkvmerge v7.5.0, so multiplexing should't be the issue.
Maybe subtitle-overlay is to blame (meaning, taking too long)?

One thing is odd (29.940 fps):
Media-info:

Code:

Frame rate                               : 29.940 fps
Original frame rate                      : 29.970 fps
...
Scan type                                : Interlaced
Scan order                               : Top Field First

My old Windows-ffmpeg is confirming the uncommon frame-rate:

Code:

Seems stream 0 codec frame rate differs from container frame rate: 59.94 (60000/1001) -> 59.92 (719/12)

But the frame-rate doesn't seem to matter, because after several remuxing and frame-rate changes, the problem remains.
E.g. one remux just with audio, no subtitles. Now MediaInfo shows this:

Code:

Frame rate                               : 30.000 fps
Original frame rate                      : 29.970 fps

=> problem remains. Even when I try to mux with a PCM-audio track.

Afterwords I muxed a mkv with the video only. And the problem remains also, because the people still seem to walk too slow (I compared it to a PC's output). The video-decoding itself just seems to be too slow. This is weird, too slow for 29.97fps?
Btw, disabling de-interlacing slows down video decoding even more!

EDIT:
After some researching I recognize that this sample is PAFF rather that MBAFF. x264 just does MBAFF-encoding, so this may be encoded by mainconcept or another encoder.
MBAFF does interlacing on macroblock level, PAFF on (whole) picture level.
So I think the issue is:
MBAFF 60i is more like 30p decoding
PAFF 60i is more like 60p decoding with seperate fields (= 2 times 1920x540).
Is it possible that the hardware decoder needs two passes for one PAFF frame, doubling the decoding time?
EDIT2:
To be more precise, I should state that above i60 means 29.97fps fully interlaced. But after deinterlacing we should have 29.97p which should render in time? Nope.
Just for some comparison: An old and trusty ION1-chipset (2009) was totally unimpressed by Blu-ray data-streams, also - of course - every Blu-ray player available (since 2006?) is capable of up to 1280x720p60 and 1920x1080i60, called 30i here: http://en.wikipedia.org/wiki/Blu-ray_Disc#Video - Erm, what year do we have right now?
EDIT3:
Something comes to my mind, because I also recoded the sample to MBAFF using x264 several times (what didn't help).
Recoding didn't help, because I got flickering. This means that the stream probably has got some tff/bff changes. Unfortunately I don't have the software to analyze a .h264 stream, but changing tff/bff-flags could trigger additional decoding delay, e.g. tff->bff: one additional field time-frame needed, what would be ~17ms. I don't know, what ffmpeg, or the hw-decoding threads do, but perhaps tff/bff-changes aren't handled well.
Field-changes could also explain the uncommon/inconsistent mkv-container frame-rate of 29.94

[rabeeh]

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.

I'm running right now 1080p60 content on 1080p 60hz display using HummingBoard-i2ex; but not on Kodi but directly through gstreamer.
The decoder is very much capable; the main issue is when blending through the gpu.

[bubi]

Interesting! What are you doing what I'm doing wrong?

No, seriously, what's your operating system exactly and what do you recommend?
While playing videos, kodi already is in full-screen mode, no scaling is active, no colorspace transversion active, and even without de-interlacing, without subtitle overlays and without audio whatsoever rendering seems to be too slow.

So, what are we supposed to do when "blending through the gpu" is the main issue?
My CPUs are quite idle all the time. Use them instead?
Could you please also upload your working 1080p60 content somewhere? Thanks.

[rabeeh]

Hi,
Few notes -
1. I'v just ran the same code on the solo (i.e. HummingBoard-i1 or CuBox-i1) and runs 1080p60 h.264 35Mmbps test content without issues.
2. I have 1080p60 content; but this is coming from a customer; so i can't share. But any 1080p60 would work.
3. To test gstreamer on the solo you can use the image from here -
https://dl.dropboxusercontent.com/u/7266...emo.img.xz
4. Flash it and then 'ctrl-alt-f2' and login as linaro/linaro
5. Use the following command to stream 1080p60 -
gst-launch souphttpsrc location=http://192.168.15.2/content/T2C00201_1080p60.ts ! decodebin2 ! queue ! mfw_v4lsink
6. gst-1.0 is mostly ready to use that too; imxipuvideosink needs to be enhanced a bit to detect that gfx/video planes are same size (1920x1080) and then the ipu can blend and transmit to the display on the fly
7. "blending through the gpu" is the main issue - this means that when blending using the gpu then this generates lots of ddr traffic. What should be really done in the case that gfx/video planes are equal in size (i.e. playing 1080p content on 1080p TV) is use the ipu to do the blending (as what the mfw_v4lsink gstreamer plugin does).
8. A hint from the fsl reference manual that the vpu can burst better (probably on the read side) when using 'tile' mode frames.

[bubi]

Thanks for the hints. I'm going to try your ubuntu image tomorrow - not enough time right now.

I have 1080p60 content; but this is coming from a customer; so i can't share.

This is somewhat understandable. But I've been searching for almost two hours now and haven't been able to find any proper H.264 1080progressive(!)60/59.97 content with a decent data rate. (I've been ignoring game captures because they often have frame drops and wouldn't be appropriate here). I'd be glad if somebody could help out here. We'd need some reference sample we all could download and check out ourself.
Not that I really needed 60p - it's just that you wrote it would work. Leaving aside at this time, that we even haven't mentioned restrictions of reference frames, b-frames, stream-rate and vbv-buffer etc., which still have to be tracked down some day.

... But any 1080p60 would work.

I'm sorry but so many things just don't work properly, I don't know what should work anymore. All features at the same time... never! Just thinking of HD-passthrough and GBit networking while playing a video and trying to control it via IR receiver. Work means something totally different to a consumer - and CuboxTV was meant for a consumer not a tinker, as far as I recall.

[fritsch]

famouse dogsample: https://dl.dropboxusercontent.com/u/5572...0207_1.mp4

Format settings, ReFrames : 2 frames
Format settings, GOP : M=2, N=30
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 29s 563ms
Bit rate : 24.1 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.940 fps

Have fun (or not).

[smallint]

rabeeh, could you test Bubi's sample (Carmen) with your gstreamer pipeline and come up with some numbers? We are currently rendering like v4l does bypassing the GPU so GPU is not an issue anymore. I also tested that sample with bare metal rendering and it could not be rendered smoothly at 30fps. I would be interested in your results.

[smallint]

famouse dogsample: https://dl.dropboxusercontent.com/u/5572...0207_1.mp4

Can't get less than 17ms on average per frame with VPU@352M.