Jerky playback with some H265 1080p movies

As I said earlier it could by crappy encoded file.
HW decoder code is Amlogic code and it’s not fully available for change. And not all issues could be easy found and fixed…
If it stuck very rare then it could be some video pattern that probably will be fixed by Amlogic in the future.

How can I see exactly what is wrong with the encoding ? Or how can I be sure I choose the right settings if I choose to re-encode ?

I fixed it with a simple remux with mkvmerge. Your reencode is just bad. Remux takes a few seconds only.

1 Like

Will try that, thanks !

I do see a small hiccup at 0:11. Remuxing did not fix it. Plays fine on Intel and nvidia.

1 Like

Indeed the hiccup remains, unfortunately :frowning:
I used command

mkvmerge -d 0 -A -S -o <temp.file.mkv> <original.file.mp4>

I have had a few (very few) videos that very rarely stutter and so far the fix I have found appears to be working.

The fix relates to a value in the amlogic kernel (“dynamic_buf_num_margin”). There was a fix introduced in CoreELEC 9.0 that would set this value to 16 if you had enabled it in Settings-System-CoreELEC and the video was 1080p resolution or lower. It was called “Enable HEVC seek workaround” or similar. The default value was 8. In Matrix 19.0 (and I think in v9.2.6), the default value is now 7.

With my few problem videos (and now your sample), they all stutter in the same place with that value left alone. If I set it to 16, the stutter disappears. So far I have experienced no side effects changing the value to 16. Since v9.2.6 that option has been removed from the gui, so I make use of the “autostart.sh” script file to set this value at startup of CE. This file should be placed in “/storage/.config” directory within CoreELEC. I also ensure that the files properties are RWX for all groups (I do this via WinSCP program).

The command to insert into this text file is:-
echo 16 > /sys/module/amvdec_h265/parameters/dynamic_buf_num_margin

One thread that mentions this is here:-Stuttering with certain encodes (CVideoPlayerAudio::Process - stream stalled)

I don’t have any 4k videos, all mine are 1080p or 720p. Still, I think this is worth trying. Your sample plays perfectly with this value set to 16, but with the default value of 7, I see exactly the same results as you quoted.

I would have a go with changing the “dynamic_buf_num_margin” value and see if that fixes it for you.

PS. I actually did manage to find a couple of 4k HDR videos and with the very quick testing I have done, these all seem to playback fine and skip forwards and backwards without issue (so far…). This is with the “dynamic_buf_num” still set at 16 - ymmv.

3 Likes

With your fix, it almost works. Anyhow, I will mark this as the solution. Let me explain how it “almost” works, in case one of those Amlogic programmers worth their name wants to spend a rainy weekend debugging it :slight_smile:

I have three files with this exact beginning movie sequence now, in the same location

  1. Original Movie
  2. Sample Movie
  3. Sample mkvmerged movie

After modifying the dynamic_buf_num_margin parameter, at first run of a file the stutter still appears. But at the second run or a rewind to beginning, the playing is smooth. Tested with all three files, same behaviour.

@ukmark62, do you have samples that really required value 16?
If I remember there were some videos that don’t work with such big value.

@cromagnon, we don’t have Amlogic programmers here. Be more polite in your sarcastic expressions.
Back to the topic: Do you see any difference between values 8 and 16 in your movies? Or 8 is enough for your videos?

I retested all files with dynamic_buf_num_margin = 8

For the small sample files the result is the same as for 16.

But for the original movie file, the stutter at 0:11 appears even after rewind. So I think I will stick to 16. Which by the way is not a perfect value, because if I wait a few minutes, at the replay it stutters again. In case you wonder, there is no networking involved, files are stored on a USB portable HDD connected in one of the four USB 3.0 ports, from which I can copy with 80 MB/sec through Odroid N2’s Samba share.

I have 2 movies so far that I have encountered it. In both cases, they playback perfectly on v9.2.5 with the “Enable HEVC workaround” set to on. There is only 1 very small section in both movies that I see the stutter. The stutter lasts barely a second and then everything is ok and it always happens in the same place . I have a ton of movies that don’t have any problem with the value set at 7,8 or 16.

I think the issue was with 4k HDR movies when the value was set to 16. I have only 3 4k HDR movies encoded at x265 10bit and, so far, they have been fine with the 16 value. This is running Matrix 19.0

It’s not a biggie, but the workaround hasn’t given me any problems. Both movies with the issue are encoded x265 10bit movies. The vast majority of my movies are encoded the same way and these are perfect - very weird. All files on portable 4GB external USB HDD.

@ukmark62, @cromagnon
Please check tomorrow nightly as it will be ready.
Try without any modifications(value will be 8 by default and 4k buffer increased) and with value 16.

@boot2k3 Same results. My 2 problem movies (and the universal sample) still skip when value is 8, but run perfectly when value is 16. I am now using Matrix nightly.

Or maybe you mean the nightly that will be built today?

Could you also share a part of sample where it is visible and can be repeated?

Current nightly already contains changes… so additional buffer doesn’t matter for your issues.

Also if rewind it back after this skip frame does it repeat this skip frame?

I extracted a sample from the 2 movies and guess what? It works regardless of the value 7,8 or 16. The extraction obviously affects it.

The original 2 movies (and universal sample mentioned in the thread) all show the same small skip at the exact same point. If I rewind 10 secs and play, the skip is repeated in the same place. I tried this 3 consecutive times with value of 7(default). With value of 16 (and also 12), no skip, and rewind 10 secs and still no skip - tried 3 times for each.

As I said, this happens very rarely and some people may not even notice, but there is always a small skip in the same place and increasing the value to 12 or 16 “fixes” it.

You should be able to use the universal sample - I find this gives consistent results. My movies will be much too big to upload.

Bit of a breakthrough!!!

My 2 problem videos were mp4. I muxed them to mkv using mkvmerge and the problem has disappeared. So no need to alter that dynamic_buf_num_margin anymore!!

PS. The universal sample still has the issue (even tried remuxing with mkvmerge) and I can only get it to play smoothly by setting the value to 12 or 16. But my problem movies now work with the default value of 7 (as mkv files). Also, that universal sample plays back very choppily on my Win 10 machine (10th gen i7 laptop).

As I said from the very beginning this Universal is crappy encoded file and it has some specific parts that only works with value 16.

I don’t know what mkvmerge tool did, but the mkv files play flawlessly.

Updated to nightly build.
For the sample posted, I still need value 16 to play smoothly.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.