[dhead]

Thanks wolfgar.

I like this scheme,.
I think Github commits (and hashes) tells me the rest of the story.

[joelbaby]

How can we tell if hardware acceleration is actually being used? Does it appear when you press 'o'? I am not sure why the CPU usage is identical whether you turn hw accel on or off.

[steeve]

How can we tell if hardware acceleration is actually being used? Does it appear when you press 'o'? I am not sure why the CPU usage is identical whether you turn hw accel on or off.

If the codec is iMX-<something>, you are

[Jönke]

Am i the only one not having 100% smooth 23,976 playback ? Every now and them i have a slowdown
tested with Openelec Gotham and Helix .

[wolfgar]

Hi Jonke,
Maybe related to this PR : https://github.com/xbmc/xbmc/pull/4592
Stephan

[jazzbo]

I've been having an issue with some of my bluray rips where every few seconds of so I get visual digital artifacts, usually in horizontal sections, as well as moments where the screen will turn partially or totally green. The audio is unaffected and plays fine. This is on my cubox-i4pro. Things tend to get worse with more action on the screen. I posted in the cubox forums here (there is also a full mediainfo listing of the video in the replies) and someone else said they were seeing the same thing.

I've tried more recent builds of both Geexbox and OpenELEC (including the recent Helix versions of OpenELEC), and none have improved the situation.

Looking at mediainfo, it appears the only possible common ground is that they are all 1080p h.264/MPEG-4 AVC (my MPEG-2 or VC1 blu-rays all play fine) and have a reframe value of 2. Also if I take the resultant MKV files and transcode them with handbrake they play fine. I'll also say that the original files play fine on the screen on my Macbook, so I don't believe it's a problem with my ripping software (MakeMKV).

Any ideas on what setting I might try? I can also provide a sample video that shows the problem if that would help.

[wolfgar]

Hi Jazzbo

I had a look a your post and for now, I don't know what the issue could be.
A sample would be very welcome so that we can reproduce and investigate your issue.
Also note that the best place to report such imx6 issue is https://github.com/xbmc-imx6/xbmc/issues

Best regards
Stéphan

[joelbaby]

I posted in the cubox forums here (there is also a full mediainfo listing of the video in the replies)

It might (might) be related to the fact that your audio is encoded in DTS-HD MA. Does it still happen if you encode, but change the audio to a non HD Audio format (e.g. DTS?).

[jazzbo]

I posted in the cubox forums here (there is also a full mediainfo listing of the video in the replies)

It might (might) be related to the fact that your audio is encoded in DTS-HD MA. Does it still happen if you encode, but change the audio to a non HD Audio format (e.g. DTS?).

Yes, in fact I've gone to just including a stereo mixdown and the problem persists.

Wolfgar took a look at a sample I sent and he believes it may be a bug with how the VPU handles the complicated SEI block in the h264 stream. I've been looking on my end to see if there is a way to remove that SEI information without reencoding. (If i process the file through handbrake the problem goes away but I was hoping to avoid that step and what ever quality loss might occur depending on my settings.)

Edit: I originally wrote SIE, not SEI.

[jsntyyl]

My device is wandboard quad, installed latest xbmc-imx-git(archlinuxarm with latest linux-wandboard 3.17.?), everything is ok but the color, it is much dark than normal, whatever the ui or playing video, I tried to change the bpp of the video parameter, nothing happened, it is strange that last xbmc-imx-git version worked ok.

reply to myself:
I searched google, found this page http://wiki.xbmc.org/index.php?title=Settings/System, so it is all about the color range, and my tv did not support full color range, but I cant find the option "Use limited color range (16-235) " in the Video Output tab.

replay again:
According to this page: http://imx.solid-run.com/forums/viewtopi...f=10&t=927, it seems that there is no "Use limited color range (16-235)" in arm devices at all.

[wolfgar]

Hi jsntyyl

Yes you have found the whole explanation by yourself.
Are you really sure your TV has no option to accept full color range ? (sometimes there is an esoteric option hidden in a menu)

Regards
Stephan

[jsntyyl]

thanks for the reply.
yes, it's pretty much sure that tv doesn't support full color range, there is a option called color system but it is grey, can not enter in.

[Hedda]

When Gotham and mainline (The Hoff ;-) / helix) have splitted, we decided to continue to rebase master-pr by following mainline to be ready for a PR to upstream while providing a imx6 port for the stabilizing Gotham on master...

@wolfgar, as you probably know Gotham and xbmc.org's mainline master (Helix) repo have now split, so I'm wondering if the plan is for all the i.MX6 code to soon be submitted as a pull request for XBMC mainline and and merged now?

That is, https://github.com/xbmc/xbmc master is no longer in feature freeze and listed as pre-alpha so should accept patches, even if the i.MX6 code is not fully stable yet.

[wolfgar]

Hi Hedda,

Yes the plan is to submit a PR with all the i.MX6 code in a near future.
I will sync with other devs to check if everyone is fine with the idea to go for it now...

Regards
Stephan

[pegro]

Hi,

since dynamic resolution detection was added I can no longer use my TV's native resolution of 1360x768. Why are non-standard (especially detailed) modes ignored when reading from /sys/class/graphics/fb0/modes in EGLNativeTypeIMX:robeResolutions?

The modes on my system are
D:1024x579p-59
D:1280x720p-59
S:1280x720p-50
S:720x576p-50
S:720x576p-50
S:720x480p-60
S:640x480p-60
S:720x480p-60
S:1280x720p-60
V:1152x864p-75
V:1024x768p-75
V:1024x768p-70
V:1024x768p-60
U:832x624p-75
V:800x600p-75
V:800x600p-60
V:640x480p-75
V:640x480p-60
U:720x400p-70
D:1280x768p-60
D:1360x768p-59
V:640x480p-60

Question is if there is a reason for not including the 'D:' modes apart from keeping the list short.

Regards,
Peter