[S905X][H265][HDR] frame skipping

Hello,

I’m noticing a lot of frame skipping on H265 content the last month or two. It seems especially visible on slow panning scenes. H264 content is not affected.
I attached a log of when i play the Alien movie which starts with a slow pan with numerous frame skipping. I also see this back in the log with lines stating: DEBUG: CRenderManager::PrepareNextRender Frame Skip:72 iter.pts:44.962 lf:1 latency:0.125 Clock:44.894

Why is this and other h265 content skipping frames? Can I provide more logging/information to find the root cause? Are there settings I could change that maybe help?

pastebin: https://paste.ubuntu.com/p/z39Qgb3bjj/
mediainfo: https://paste.ubuntu.com/p/N4S2JW7MZX/

Go to Settings -> System -> set to Expert -> CoreELEC -> Enable HEVC workaround
Then see if it fixes the problem.

@unicron, can you run dispinfo before and during playback?

I did some more testing after reading another forum thread: Stuttering with certain encodes (CVideoPlayerAudio::Process - stream stalled)

There the following parameter is discussed:
/sys/module/amvdec_h265/parameters/dynamic_buf_num_margin

This parameter definitely has an effect. As soon as the system boots its on 16, and when I play the movie it is set to 8. I tried setting it to 12 and 16 instead while playing the movie. The result is a huge improvement.

Considering when I started noticing the stuttering this seems to be related to the patch at the end of december: https://github.com/CoreELEC/CoreELEC/commit/b4af77383efff4dddb6d42019751d6ed0aae138e

Also, what does the number actually mean because the patch says increasing the number of buffers, while the value is actually becoming lower? Is more buffers not always better, also for 1080p content?

@TheCoolest, @CI6N0Z Later I will also try the mentioned HEVC workaround and look at the dispinfo and report back.

Edit:
Looking at the HEVC seek workaround: https://github.com/CoreELEC/CoreELEC/commit/1e6d096d9de1086e63c8be5282e7a56a92b1b9ab#diff-db64b7fb2b4710058c7d9b27553459fd
It again changes dynamic_buf_num_margin behavior. At least looking at the history I can see it makes sense now why it is set to 8 on my device as soon as I start playing the movie.

The thing is with the latest version of the patch that introduces:
|| !CServiceBroker::GetSettingsComponent()->GetSettings()->GetBool(CSettings::SETTING_COREELEC_AMLOGIC_HEVCWORKAROUND)). It changes the behavior for 1080p content compared to the previous patch version, while the title only suggests 4K content. All because of the ‘!’ exclamation character.

I tested also with enabling the work around and as expected this fixes the problem. :slight_smile:

And the dispinfo: http://ix.io/1HVa

Edit 2:
Are you guys sure the patch is actually right, because I think the ‘||’ should be a ‘&&’ ? To me it almost seems like a bug and not the intended behavior for both 1080p and 4K
As in:
if ((hints.width > 1920) || !CServiceBroker::GetSettingsComponent()->GetSettings()->GetBool(CSettings::SETTING_COREELEC_AMLOGIC_HEVCWORKAROUND))
if ((hints.width > 1920) && !CServiceBroker::GetSettingsComponent()->GetSettings()->GetBool(CSettings::SETTING_COREELEC_AMLOGIC_HEVCWORKAROUND))

That would fix the 1080p content and I think also fix the expected behavior of the HEVC workaround for 4K. With an ‘OR’ the UI switch does actually nothing to 4K content as the patch suggests

The HEVC workaround (increasing the dynamic_buf_num_margin value) requires resetting the decoder after you skip within a video, which caused adverse effects for many users, especially with HDR content. We saw that most of the content affected by this issue was 1080P<= encodes, so we came up with a compromise where the HEVC workaround will only affect 1080P and below HEVC videos.

Hello,

It is the first time that I use CoreELEC. I have used the LibreELEC community builds before.
My box is an MXQ Pro+ 4K (s905x, 2GB).
The latest build that works for me perfectly is LibreELEC (community) Version: 7.0.3.012l
I did not upgraded from that, because after this build, every version has stuttering and frame skipping during h265 HDR contents.
I do my testing with this video: The_World_in_HDR_in_4K_HDR10.mkv
Unfortunately I have the same issues with CoreELEC 9.0.1. I have tried all the settings under Settings/System/CoreELEC including HEVC workaround but no luck.

You probably have a bad encode of that file, because it plays fine for me on my S905X devices.
The HEVC workaround only works for 1080P or less files on the S905*/S912 builds.

I have seen high skipped frame counts on 4K UHD rips from MakeMKV 1.14.3 (H265, of course). Running them through MKVToolNix GUI v33.1.0 seems to fix it right up. Reduces the number of skips from potentially hundreds to just the number that seem to occur when the display is brought up to show them.
Your problem may be entirely different, but I now take a pass through MKVToolNix for all my UHD before they end up on the media server.
Better regulation in the mux could explain why fiddling buffer space also seems to work (never tried it).

If it’s bad encoded, why does it work on LibreELEC 7.0? Was it “bad encoded” proof?

You can check it yourself, what is the problem with it?

Same issue, frame skipping:
bbb_sunflower_2160p_30fps_normal.mp4
https://download.blender.org/demo/movies/BBB/

As well:
HD-Club-4K-Chimei-Inn-60MBit.mp4
https://4ksamples.com/4k-chimei-inn-60mbps/

I never seen the source for that build, so it’s hard to say. Maybe Kszaq used a high default value for the buffers.
Either way, I watched many of those videos, I never seen an issue with any of them on my devices, including World In HDR.
I’m not saying that there isn’t an issue, just mentioned how things are at this point.

You might say that some implementations are more tolerant of incorrect encoding or multiplexing than others.
That can be by accident or hard won experience. No way to tell and it tends not to be very portable. Just as the HEVC workaround has its complications, most efforts to workaround media issues have some unpleasant side effects.
And it might not be the media’s fault, but it probably is.
@TheCoolest may have a different take.

The simple fact is that every single UHD Remux I tried works just fine without any workarounds, on S905X and S922X. It’s only encodes that I’ve seen with this problem.

Please send me one sample/test file, that should work without any issue.

What can I say but that it fixes the issues for me with release CoreElec 9.0.1 on a 912 box.
I simply tried remultiplexing the MKV from MakeMKV and the original and remuxed version were worlds apart in skipped frames reported. I tried this with 4 different UHD films where I noticed either visual or audio glitches on that box and got similar results with each using a script addon that puts the skip and other info on the screen (forget the name and author, at the moment).
This is not precisely the 905X mentioned, but the lower end chips are usually going to be more, not less, sensitive to resource issues and performance requirements.