Very strange issue around 1 hour mark of encoded videos

[Jacketbg]

First of all big Thank You for your work on dovi_tool!

I have a very strange reoccurring issue and I'm not sure if it's a bug or something that I'm not doing right..

Almost all (probably even all) of the DV encodes that I tried to do with dovi_tool have a strange issue somewhere around the 1 hour mark. Depending on the player it manifests as either few broken frames, freezing/stuttering or reverting my TV (LG C2) from DV to HDR as is the case with Infuse on AppleTV 4k. It's very strange and usually happens somewhere between the 1h 0m and 1h 20m mark. It's easily reproducible by seeking 5 seconds before the broken frames. I even cut a 5 second segment with ffmpeg and it's visible there too. VLC shows the following messages when this happens:

videotoolbox warning: vt session error: 'kVTVideoDecoderBadDataErr'
videotoolbox error: decoder failure, Abort.
main warning: Reloading the decoder module
main debug: removing module "videotoolbox"
videotoolbox warning: vt session error: 'kVTVideoDecoderBadDataErr'

I'm using dovi_tool 2.1.0 and I am encoding with the latest ffmpeg master 20231103 (tried with 5.1.1 and the result was the same, so it' not an issue ffmpeg). My x265 version is compiled from source: x265 3.5+110-8ee01d4:[Linux][GCC 4.8.5][64 bit] 10bit

I don't crop or resize. I'm extracting RPU like this:

ffmpeg -loglevel panic -i input.mkv -c:v copy -vbsf hevc_mp4toannexb -f hevc - | dovi_tool -m 2 extract-rpu - -o /tmp/rpu.bin

Then passing to x265 cli like this:

--dolby-vision-rpu '/tmp/rpu.bin' --dolby-vision-profile 8.1 --vbv-bufsize 160000 --vbv-maxrate 160000 --input-depth 10 --output-depth 10

There are no errors or warnings from x265 during the process. It finishes with this:

x265 [info]: VES muxing with Dolby Vision RPU file successful in x265

Is there anything wrong with my process? Has anyone else experienced similar issues?
I can upload a sample 5 second clip with the issue and the rpu file, or test anything else if needed. I didn't want to open an issue directly as I am not sure if this is a bug or just something that I'm doing wrong.

[quietvoid]

A sample that reproduces the issue is necessary for me to look into it.

[Jacketbg]

Sure, here's the 5sec clip: https://www.dropbox.com/scl/fi/qoih5lpw6z87zfyvq5fxi/dv-break.mkv?rlkey=aiyk8erqa9sbi89yjo6ow10qi&dl=1
I cut it from the original file like this:
ffmpeg -ss 01:00:27 -to 01:00:28 -i original.mkv -an -sn -map 0:v -c copy cut.mkv

[quietvoid]

It doesn't seem like there's anything wrong with the clip on my side.
It might just be related to a hardware decoder issue.

There are definitely known issues with some x265 settings and high motion, where some hardware fail decoding and show artifacts.

[Jacketbg]

Strange... This issue happens suspiciously close to 86400 frame (on two of my videos at least it' just a few seconds after 1:00:00) and I was wondering if there is something special going on there.
This is my whole ffmpeg/x265 command line. Do you think some of those parameters could cause this? I haven't noticed any issues on non-dv files though and I use basically the same settings:

ffmpeg -v quiet -loglevel error -i - -map 0:0 -an -sn -vsync 0 -f yuv4mpegpipe -strict -1 - |\ 
x265 - --y4m --log-level error --rskip 2 --rskip-edge-threshold 2 --rc-lookahead 40 \
--aq-mode 1 --aq-strength 1 --no-sao --selective-sao 0 --deblock -1:-1 --psy-rd 4 \
--hdr-opt --repeat-headers --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc \
--master-display 'G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)' \
--max-cll '1000,400' --dolby-vision-rpu '/tmp/dovi_rpu.bin' --dolby-vision-profile 8.1 \
--vbv-bufsize 160000 --vbv-maxrate 160000 --input-depth 10 --output-depth 10 \
--crf 17 --preset slow --frames 128721 -

Thank you for looking into this.

[quietvoid]

I do see the artifacts on my Amazon FireTV Stick 4K Max, so it's definitely a hardware decoder problem. Not related to Dolby Vision.
AFAIK --rskip 2 can cause such issues, but it usually only causes issues with hardware decoders.

[Jacketbg]

Thanks for the tip! I will definitely try to do an encode without --rskip 2.
In my case with Infuse on AppleTV 4k gen 3, when it hits the bad frames the screen goes blank for 2-3 seconds, Dolby Vision turns off and the video reverts to HDR. When I then reset the video (after the problematic timestamp), everything is OK until the end of the movie.

[quietvoid]

I only get major glitches and artifacting here.
The video itself fails decoding regardless of Dolby Vision or not.

[Jacketbg]

Thanks again. I will continue to search for the culprit and will get back here. The encode without --rskip 2 should finish tomorrow and we'll see how it ends up.

[Jacketbg]

I think you might be right! The video without --rskip 2 doesn't seem to suffer the same glitch at this timestamp, although I have to watch it fully later today to completely verify.
I got this option from different places suggesting it preservers grain better. A very nice side effect from it was that it also reduced encoding time drastically for me:
1 minute segment without --rskip 2:

encoded 1440 frames in 761.14s (1.89 fps), 23287.15 kb/s, Avg QP:20.74

1 minute segment with --rskip 2:

encoded 1440 frames in 366.80s (3.93 fps), 24775.18 kb/s, Avg QP:20.68

This is on Xeon Silver 4310. The whole movie took 10h 30m instead of 6h 20m. That's a big hit, but I'll take it instead of ending up with a broken bitstream.
I will get back here after watching the whole movie.

Thanks again for the suggestion! I would never have guessed that this option will cause such issues. I also couldn't find any information online about this, which is very strange as this seems like a major issue with this option and it is recommended left and right on forums for grain retention...