Issue with some x265 content

points · 6 December 2018 20:05

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

Tom_Doyle · 6 December 2018 20:22

Hi,

Is playback local or from your network?

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

Thanks Tom.

points · 8 December 2018 16:18

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: https://paste.osmc.tv/ifoqukexaf

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

grahamh · 8 December 2018 17:49

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

sam_nazarko · 8 December 2018 19:55

Hi

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.

Sam

sam_nazarko · 8 December 2018 20:09

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

Sam

points · 8 December 2018 20:35

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.

sammyrc34 · 3 July 2019 08:06

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

sam_nazarko · 3 July 2019 09:01

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

Sam

sammyrc34 · 3 July 2019 12:09

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

k2u3 · 3 July 2019 12:10

Probably an encode not a remux ?

points · 3 July 2019 13:38

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

Video
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

Audio
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```

sam_nazarko · 3 July 2019 13:45

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!

Sam

points · 3 July 2019 14:02

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

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).

sam_nazarko · 3 July 2019 14:25

simp-004 from eMMC looks OK here.

points · 3 July 2019 14:45

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.

sam_nazarko · 3 July 2019 15:24

Checking again…

Sam

nabsltd · 3 July 2019 15:51

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.

darwindesign · 4 July 2019 00:11

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.

nabsltd · 4 July 2019 01:03

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.