Long decodes lead to slowdown and huge log files

[davidvankemenade]

Checklist

• ✅ I have searched the issues page for any duplicate issues open or closed and confirmed that this bug has not been reported before.
• ✅ I have tested the issue with the current build.
• ✅ I have attached log files, uploaded sample data, and commands used so that the issue can be easily reproduced by the developers.

Bug Description

• When processing 4-hour tapes, vhs-decode.exe slows down by about 40%. This seems to happen at certain frames where the console outputs thousands of lines like this one:
  [s16le @ 000001e7762f3bc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 329406142149 >= -329406140347
• The debug log doesn't report any issues around the frames involved, except that these frames take longer to process than non-affected ones looking at the timestamps.
• The .tbc output files are ultimately completed as usual, it just takes much longer to get to the end.
• There is nothing special to see in the video around the frames affected.
• The first frame in which this issue occurs is in the region of 205000.

Steps to Reproduce

1. Capture 4-hour tape using DdD at 16 bits
2. Perform lossy compression from 40msps to 28msps 8-bit in line with https://github.com/oyvindln/vhs-decode/wiki/RF-Compression-&-Decompression-Guide#linux-down-sampling-scripts
3. Run decode.exe vhs --use_saved_levels --ire0_adjust --overwrite --frequency 28 --level_detect_divisor 2 --recheck_phase --pal --threads 4 --tape_format SVHS compressed.flac outputtbc 1>stdoutput.log" 2>&1
4. Inspect log files - https://drive.google.com/file/d/1k2qST__paiZnL4iat3_FpZMnAmPKw2eo/view?usp=drive_link

Expected Behaviour

• No unusual errors should be reported.
• Long files should decode at around the same speed as shorter files.

Actual Behaviour

• Thousands of errors are output to console for certain frames.
• Decode process is slowed down by about 40%.

Environment

• Decode version: 0.3.0 (Windows release)
• Operating System: Windows 10
• Hardware Used: DdD

Additional Information

• I think this is not related to the lossy flac compression used as input. Until recently I was able to process long tapes like this without these repeated errors.
• The two parameters I recently changed to speed up the decode are adding --use_saved_levels and using --level_detect_divisor 2 instead of 1.

Is there anything in the code that could explain this behaviour?

Is it related to tbc-video-export?

No

[davidvankemenade]

I can exclude the lossy flac compression from this. I've repeated the decode with the original .s16 file. The bug occurs earlier this time around:

File Frame 144070: SVHS
[s16le @ 00000219d9f86340] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 230584299520 >= -230584298227