Issue with some x265 content

I’ve got several series of a show which will not play on the Vero 4K correctly.
Audio is heard then at intervals audio drops off and you get video for around 0.5 seconds instead.

I’ve given a link to a sample I cut.

Issue with Vero 4k+ with latest Leia. But I reset to default today (Krypton) and have same issue.
Plays fine with i386 on Krypton (CPU decode). And also Fire tv 4k stick Leia RC1.

In kodi.log I get:
NOTICE: CVideoPlayerAudio::Process - stream stalled

I’ve not given logs, as I think this should be easily reproducible with the sample.
I suspect it’s with the GPU Vero uses. If so not really a Vero issue. Sorry if I should be asking over in Kodi forumn, but you guys are the best :slight_smile:


Is playback local or from your network?

Only if the issue isn’t unique to your setup, I would suggest providing logs.

Thanks Tom.

I had hoped someone would have tried to reproduce the issue.

Playback is over the LAN. I can play 50Gb+ files, so this tiddler is not an issue.
Played the above sample with debug enabled:

The sample doesn’t terminate correctly, but up until the end has same issues as the full thing.

Thanks. I can reproduce it but with slightly different log messages. I hope someone like @sam_nazarko knows how to fix it.


I just took a quick look at this and can reproduce playback problems with the clip.
You should be able to get it to play with:

echo 16 > /sys/module/amvdec_h265/parameters/dynamic_buf_num_margin before playback. However this is not appropriate for all videos.

I will see if I can identify characteristics in your sample that warrant the increased buffer size and adjust this dynamically.


I should have a workaround for this now, but I don’t have time to test this just yet.


Changed /sys/module/amvdec_h265/parameters/dynamic_buf_num_margin from 12 to 16.
Works ok for 20 secs, then issues for another min or so. Then it it plays ok.

Sam I’ll pm you a link to the full file.

I’ve run into the same issue Sam. The above suggestion works well in my case.

What was the name of the title that you were playing?


Actually it’s a few different titles, converted by the same person. I gather the settings they chose caused the issue.

Probably an encode not a remux ?

Mine was an encode, I did send a extract of the file to Sam. He said it could take a long time to fix. I gave up!

Format version                           : Version 4
File size                                : 9.19 MiB
Duration                                 : 34 s 751 ms
Overall bit rate                         : 2 219 kb/s
Encoded date                             : UTC 2018-12-06 16:05:40
Writing application                      : mkvmerge v27.0.0 ('Metropolis') 64-bit
Writing library                          : libebml v1.3.6 + libmatroska v1.4.9
Writing frontend                         : StaxRip v1.7.0.0

ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main@L5.1@Main
Codec ID                                 : V_MPEGH/ISO/HEVC
Duration                                 : 34 s 743 ms
Bit rate                                 : 1 925 kb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Standard                                 : NTSC
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Bits/(Pixel*Frame)                       : 0.039
Stream size                              : 7.97 MiB (87%)
Default                                  : Yes
Forced                                   : No
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : A_AAC-2
Duration                                 : 34 s 731 ms
Bit rate                                 : 288 kb/s
Channel(s)                               : 6 channels
Channel layout                           : C L R Ls Rs LFE
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Delay relative to video                  : 20 ms
Stream size                              : 1.20 MiB (13%)
Title                                    : English 5.1 Surround
Language                                 : English
Default                                  : Yes
Forced                                   : No```

Was this the Simpsons clips you sent? I fixed those in February and verified they here. Looks like I forgot to tell you it was fixed!


Hi Sam, embarrassed to say yes it is the Simpsons! It’s not working still, and on the positive side you have given me back ~100 hours of my life back :slight_smile:

Same issue though:
019-07-03 14:56:18.616 T:3443520224 NOTICE: CVideoPlayerAudio::Process - stream stalled pts:11.048 clock:11.058
2019-07-03 14:56:29.705 T:3443520224 NOTICE: CVideoPlayerAudio::Process - stream stalled pts:26.450 clock:26.455

Running the OSMC June update (Kodi compiled 2019-06-21 by GCC 6.3.0 for Linux ARM).

simp-004 from eMMC looks OK here.

I just downloaded it from dropbox and played it from /home/osmc and get the same issue. So surprised it works fine for you!

I just got it working by disabling “Allow hardware acceleration - Amcodec”. Obviously not a long term solution.

Checking again…


It would help to know the full encoding parameters that include things like references, because if the reference count isn’t extra high, the profile (Main@L5.1) is more than is needed for the video. It should be Main@L4.0 based solely on the resolution and frame rate.

More references mean more stored frames in memory to refer to, which means more memory allocation. If the extra memory requirements are close to the limit of the chip, it could cause issues with playback. But, if the video doesn’t actually need it, then it’s just a waste.

There are free or moderately priced tools to fix this kind of thing with H.264 streams, but I don’t know of any for H.265 streams.

Handbrake does h.265 now. Personally I would stick with h.264 for HD content as there is not a very big difference in file size for the same video quality, but there is a big difference in encode speed.

Handbrake is a front-end to encoding tools.

I was talking about tools like VideoRedo, which can fix errors in an H.264 bitstream without re-encoding. This includes fixing metadata like the profile and level that that are stored in the bitstream. The newest version of VideoRedo does support H.265, but it’s still in beta, and still pretty buggy.