Posts by jd17

I understand, sounds logical!

I'll start testing the new "Frankenstein" based build right away - but I'll focus on the issues I had with a few files and a/v-sync etc. - basically non-UHD stuff.
I won't do any 2160p / 10bit / BT.2020 / HDR10 testing until I have the new cables - I don't want to bring any more noise into this than I already have.

Quote from RedCat

johngalt I tired ur new build, but no change. Maybe it was worse. 20 times start 4k video, but 16x no signal, 4x film start. I tired rouge one 4k, and planet earth II 4k films. Afternoon I bought a new HDMI 2.0a cable too, but no change.

But with MM kernel (8.0.2a, 8.0.1l-mm) everything is good.

Well, MM kernel probably only works good for you because the bandwidth is much lower.
No BT.2020 and only 8bit.

Are you sure the cable you bought is the real deal?
Can you check with another device?

Quote from wesk05

It is intriguing why there is this difference in playback performance. I checked the clips that jd17 has listed and all of them played fine...

I am sorry that I caused so much confusion over nothing.
My issues seem to be cable related so everything should be fine once I get the proper cables.

Quote

...except for the LG OLED Wonders one. I think Kodi has issues with that file. It doesn't play in Kodi on any plaftform.

Yes, I can see that this file is an exception.

I will exclude it in future testing.

Unfortunately I will be on a business trip next week and on a stag weekend after that so it'll be a while before I can continue tests with the new cables.

I'm still open to any tests needed until Monday (bank holiday in Germany).


johngalt why do you want to go back to Nougat Frankenstein now? I'm not sure I understand that...
I thought we were on a good path to making full Nougat viable...

This is not about 10bit AVC!

The files in question are regular 720p and 1080p 8bit AVC stuff, BT.709.

The output is the issue. Those files play perfectly with 8bit output, but look like slowmotion with 10bit output.
The weirdest thing though is, that not all AVC videos are affected.
My own x264 stuff is perfectly fine.

10bit output is the rootcause for the weird behavior of those H.264 files.
They play fine on regular 8bit output, but go slow-motion on 10bit output.
Again, my x264 (8bit) encodes are fine with 10bit output.

The attachments do not have an impact.

Maybe I misjudged the delay before and it is only those 175ms... I'll have to do more testing.

Quote from mmpp

My usb MCE remote works fine, btw.

Thanks for the tip!

Quote from mmpp

x264 and x265 are names of encoder libraries, the corresponding standards are called h.264 and h.265.

I know that of course - which is why I said "weirdly".
It does not make sense, but my own x264 encodes play absolutely fine, while untouched H.264 stuff does not.

Normally H.264 = AVC = x264, I have never seen any software being selective about it either, but I am just reporting what I see.
I know that too many reference frames can make a big difference, but the tested H.264 files were "harmless" in that regard: 2 and 4 reference frames are well within the norm.

I don't see anything else being special about these files...
Wait - they have jpg attachments. I'll see if those are the root cause.

Quote from kubrickdave

I don't have sync issues at all (never had them on any build).

Normally I have 175ms on 23.976fps videos which is quite common in Kodi.

Quote

Edit: Have you tried disabling HDMI lip sync on your AVR?

I never had it enabled.
However, it might be possible that the AVR causes the delay due to the 10bit signal?
It is an older model that is not capable of HDMI 2...
I'll see if 8bit vs. 10bit output makes a difference.

Quote from mmpp

While hevc worked fine with the latest test version, my 720p h.264 23.976fps encodes were quite jerky and not watchable.

I can confirm that weirdly, H.264 is extremely buggy, it looks like slow motion.
However, both x264 and x265 seem fine.

Also, a/v is severely out of sync, at least for DTS, DTS-HD and Dolby TrueHD.
All tested videos were 23.976fps, but the async goes far beyond the usual 175ms...

Quote from jd17

I actually noticed a problem with the [...] MM build (8.0.2a) today.

A certain range in the lower grayscale flickers.
It can easily be reproduced by setting the screensaver to 5% dim and pause a [...] video during a scene that covers various brightnesses.
Some areas in that frame will most likely show that flicker once the dim kicks in.

I am happy to report that the flicker I see in MM Krypton seems to be gone in this Nougat build as well.
Both with unchanged 8bit output and 4:4:4 10bit output.

I would like to do some testing for frame drops or skips too, but without IR remote, I don't really know how to trigger PlayerDebug... Any ideas?

Cables....
It all comes down to f*cking cables.

It's sad really, I should have thought about that before...
Those black screens screamed HDMI cable signal losses.

I tested all 7 HDMI cables I have, the outcome is unbelievable and sad in my eyes.

The worst performing cables were the shortest (0.5m) and newest high speed cables.

The best performing cable by far was the oldest, longest (5m), non high speed HDMI 1.3 (!) cable.

The short cable that came with the Mini M8S II box is particularily bad and tied for worst with one other short cable...

It was very obvious how well a cable performed. Some even failed the 60fps videos (4:2:0) while others were perfectly fine.
The worst ones already showed "white sparkling dots" while the video was loading.

The most critical framerates seem to be 25fps and 50fps.
That is the crucial test.
If everything runs well at YCbCr 4:4:4 without dropouts/losses on a 2160p / BT.2020 / 10bit / HDR10 video with a frame rate of 25fps or 50fps, you have a properly good cable

I will of course order a few new cables now...
However, I'd still like to test 4:2:0 if I may.

Quote from johngalt

I'm thinking this is a bandwidth issue -- either cable, or these boxes really aren't made equal. Within the next day I'll push support for manually specifying 4:2:0 and we can see how it goes.

I thought about that too... I will test another cable tomorrow.
However, what is the first refresh rate that uses 4:2:0 automatically? Do you know that?

Just to recap my tests with 4:4:4:

23.976: fail
25.000: fail
29.970: pass
30.000: complete fail
50.000: fail
59.940: pass
60.000: pass

Blue were HDR10 / BT.2020 / 10bit videos, so probably a higher bandwidth.

59.94 and 60 fps will definitely be 4:2:0, those would have the highest bandwidth.
29.97 is confusing in that mix. 23.976 fails even as 2160p / BT.709 / 8bit, whereas 29.97 is fine with the same specs....

Quote from johngalt

When you first boot, could you try echo '422,10bit' > /sys/class/amhdmitx/amhdmitx0/attrinstead of the 444 command and see if you still get the dropped signal?

Interesting.
23.976fps seems to be stable with 4:2:2.
However, 25/50fps still loses the signal right away and 30fps won't play.

Just to make sure, I also tested 4:4:4 again but same result, signal is dropped quickly in the 23.976fps Samsung demo.

Quote

Btw, I found why we can't do manually set 4:2:0 on this kernel and will reenable support. It shouldn't matter for us, but gives us more options for testing).

I'd like to test that too.
At least in my mind, 4:2:0 should be ideal? All video is in 4:2:0 and all the converting would be done in the TV? Doesn't that make sense?

Quote

I'm quite confident I can take this 10 bit support to the MM kernel as well if needed.

I don't think there is a reason to go back to MM if everything works well in Nougat...

Since I saw those flickers in the Krypton MM build I can't unsee them.

Quote from aandrass

Which LibreELEC is recommended for 4K HDR playback?

Be patient just a little longer.
The dev team is very close now, but the linked build still has some issues (like no IR remote).

I'm sure we'll have a fully working UHD build soon.

It sometimes starts out like the black screens / signal losses we have had for a while now in Krypton.
Video plays, than black screen, then it plays again for a while - but at some point, the signal is completely lost.
Sometimes, it is lost completely right away.

OK here it is, I only copied the last bit for you, starting the video...

22:42:14.167 T:4117397584  NOTICE: VideoPlayer: Opening: /var/media/jd_usb_64gb/9. Samsung_HDR_Wonderland_2160p_hevc_10bit_23.976hz_bt.2020_hdr10.ts
22:42:14.168 T:4117397584 WARNING: CDVDMessageQueue(player)::Put MSGQ_NOT_INITIALIZED
22:42:14.168 T:3718247328  NOTICE: Creating InputStream
22:42:14.179 T:3718247328  NOTICE: Creating Demuxer
22:42:14.578 T:3718247328  NOTICE: Opening stream: 0 source: 256
22:42:14.578 T:3718247328  NOTICE: Creating video codec with codec id: 174
22:42:14.578 T:3718247328   ERROR: CBitstreamConverter::Open hvcC data too small or missing
22:42:14.580 T:3718247328   ERROR: Unable to load libamplayer.so, reason: libamplayer.so: cannot open shared object file: No such file or directory
22:42:14.580 T:3718247328 WARNING: CAMLCodec::CAMLCodec libamplayer.so not found, trying libamcodec.so instead
22:42:14.583 T:3718247328  NOTICE: Creating video thread
22:42:14.583 T:3718247328  NOTICE: Opening stream: 1 source: 256
22:42:14.583 T:3552138144  NOTICE: running thread: video_thread
22:42:14.583 T:3718247328  NOTICE: Finding audio codec for: 86018
22:42:14.584 T:3718247328  NOTICE: Creating audio thread
22:42:14.584 T:3694130080  NOTICE: running thread: CVideoPlayerAudio::Process()
22:42:14.762 T:3718247328  NOTICE: Opening stream: 0 source: 256
22:42:14.762 T:3718247328  NOTICE: Creating video codec with codec id: 174
22:42:14.763 T:3718247328   ERROR: Unable to load libamplayer.so, reason: libamplayer.so: cannot open shared object file: No such file or directory
22:42:14.763 T:3718247328 WARNING: CAMLCodec::CAMLCodec libamplayer.so not found, trying libamcodec.so instead
22:42:14.763 T:3718247328  NOTICE: Opening stream: 1 source: 256
22:42:14.840 T:3552138144  NOTICE: CAMLCodec::OpenDecoder - using V4L2 pts format: 64Bit
22:42:14.903 T:3694130080  NOTICE: Creating audio stream (codec id: 86018, channels: 2, sample rate: 48000, no pass-through)
22:42:14.934 T:4117397584  NOTICE: Display resolution ADJUST : 3840x2160 @ 23.98 - Full Screen (33) (weight: 0.000)
22:42:15.722 T:4117397584  NOTICE: VideoPlayer: OnLostDisplay received
22:42:16.059 T:4117397584   ERROR: EGL error in CreateSurface: 3003
22:42:16.059 T:4117397584  NOTICE: CreateWindow: Could not create a surface. Trying with a fresh Native Window.
22:42:16.311 T:3694130080   ERROR: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer
22:42:18.437 T:4117397584  NOTICE: VideoPlayer: OnResetDisplay received
22:42:40.914 T:4117397584  NOTICE: CVideoPlayer::CloseFile()
22:42:40.915 T:4117397584  NOTICE: VideoPlayer: waiting for threads to exit
22:42:40.924 T:3718247328  NOTICE: CVideoPlayer::OnExit()
22:42:40.924 T:3718247328  NOTICE: Closing stream player 1
22:42:40.924 T:3718247328  NOTICE: Waiting for audio thread to exit
22:42:40.999 T:3694130080  NOTICE: thread end: CVideoPlayerAudio::OnExit()
22:42:40.999 T:3718247328  NOTICE: Closing audio device
22:42:41.085 T:3718247328  NOTICE: Deleting audio codec
22:42:41.086 T:3718247328  NOTICE: Closing stream player 2
22:42:41.086 T:3718247328  NOTICE: waiting for video thread to exit
22:42:41.142 T:3552138144  NOTICE: thread end: video_thread
22:42:41.193 T:3718247328  NOTICE: deleting video codec
22:42:41.288 T:4117397584  NOTICE: VideoPlayer: finished waiting
22:42:41.691 T:4117397584  NOTICE: CVideoPlayer::CloseFile()
22:42:41.691 T:4117397584  NOTICE: VideoPlayer: waiting for threads to exit
22:42:41.691 T:4117397584  NOTICE: VideoPlayer: finished waiting
22:42:41.691 T:4117397584  NOTICE: CVideoPlayer::CloseFile()
22:42:41.691 T:4117397584  NOTICE: VideoPlayer: waiting for threads to exit
22:42:41.691 T:4117397584  NOTICE: VideoPlayer: finished waiting

dmesg:
aiQM

log:
cXJi

I enabled debug logging on the second attempt because of that message:
"cat: can't open '/storage/temp/kodi.log': No such file or directory"
However, it still appeared... But I got a link anyhow, hope that's ok?

I used this one:

Quote

2160p / BT.2020 / 10bit / HDR10 / 23.976fps (Samsung HDR Wonderland demo):
Signal is lost after a few seconds. Stopping retrieves signal (in menu).

EDIT:
Hmm, log link seems empty... What do I do?

Sure, what is the process, do I play a critical video and type those commands in putty while it is playing? Or after?

BTW:
AVR confirms 10bit at least for 1080p.
It says YCbCr 30bit.

Quote from johngalt

New build:

.
.
.

10bit output:

• On a new boot before any other playback has been performed, run the following: echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr

I just tested your build (I enabled 10bit output right away).
BT.2020 is definitely passed.
HDR10 seems to work great too.

10bit probably works as well, unfortunately the TV does not tell me.
It looks good from a first glance, no obvious banding in either 8bit or 10bit videos.

Observations (menu is set to 1080p60):

1080p / BT.709 / 8bit / 23.976fps:
Seems fine.

1080p / BT.709 / 10bit / 23.976fps:
Seems fine.

1080p / BT.709 / 8bit / 25fps:
Seems fine.

2160p / BT.709 / 8bit / 23.976fps (LG Syndney demo):
Signal is lost after a few seconds. Stopping retrieves signal (in menu).

2160p / BT.709 / 8bit / 25fps (LG Skiing demo):
Signal is lost after a few seconds. Stopping retrieves signal (in menu).

2160p / BT.709 / 8bit / 29.97fps (LG Chicago demo):
Seems fine.

2160p / BT.709 / 8bit / 30fps (LG Wonders demo):

Video won't start.

2160p / BT.709 / 10bit / 50fps (LG La Boheme demo):   
Signal is lost after a few seconds. Stopping retrieves signal (in menu).

2160p / BT.709 / 10bit / 59.94fps (LG OLED Art demo):
Seems fine.

2160p / BT.709 / 10bit / 60fps (LG Eclipse 2 demo):
Seems fine.

2160p / BT.2020 / 10bit / HDR10 / 23.976fps (Samsung HDR Wonderland demo):
Signal is lost after a few seconds. Stopping retrieves signal (in menu).

2160p / BT.2020 / 10bit / HDR10 / 59.94fps (Samsung HDR Chasing the Light + Sony Camp demo):
Seems fine.

2160p / BT.2020 / 10bit / HDR10 / 60fps (LG Colors of Journey demo):
Seems fine.


Conclusion:
Apparently 2160p at 23.976 / 25 / 30 and 50 fps is an issue, at least while the menu is set to 60 fps.

Quote from Pelican

You have no idea what are you talking about...

Just compare Planet Earth II BD and Planet Earth II UHD BD rip.

You preferring that rip still does not make it right (at least not in any Marshmallow or Nougat Frankenstein build).
Preference ≠ reference.
What is so difficult to understand about that?

But sure, let's agree that I don't know what I'm talking about because I am not judging those build's UHD capability based on a UHD HDR capture on a non-HDR display. I can live with that.