Non monotonic errors with split/merged mkvs

[Travillion]

Hello,

I have a large h264 source that I split on keyframes (keyframes identified with FrameCounter). Running ffprobe on the intact source and these cut sections reveals no errors. However, when I merge several of the sections back together with mkvmerge or MKVToolNix, ffprobe on the resulting merged file reveals numerous errors of this type:

[null @ 000002ce0d0e5d80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 56077 >= 56077

They are all on stream 0 (the video). The source, cuts, and merged mkv have 1 video and several audio and subtitle tracks (tracks match for each file since they all come from the same source and are unmodified). This happens even if I merge all the pieces back together (i.e., rebuild it exactly). No re-encoding is done at any stage. mkvmerge does not produce any error messages during splitting or merging. Using ffmpeg's concatenate function to merge also produces non monotonic errors, which maybe suggests something is happening in the splitting, although ffprobe finds no errors on the split files.

I've had issues like this in the past, but I was using Windows 7 and external drives at the time, which Moritz pointed out to me caused problems (those problems weren't restricted to 'non monotonically increasing' errors). I have a new machine now and am running Widows 10 and an m2 SATA SSD. I have an i9-9900K and 32GB RAM. I was using the latest version of mkvmerge 34 and replicated this on 33 and 32.

I haven't checked playback because I can't discern where the errors are (are the referenced numbers frames or ms?) and I haven't had time to watch the entire output file. I don't know what the implications of these errors are, or why they are being produced and if there's anything that can be done about it. What generally causes a non monotonic error? This is my first edit on my new machine, could it be a hardware configuration issue? I can't figure out why cutting and merging is producing these errors when no alterations besides simple cutting is occurring, and the the files pre-merge all report no errors by ffprobe.

[Selur]

What do the command line calls you use look like? (assuming you do this in a command line)
Does this also happen if you use MKVCutter?

[Travillion]

My command line for splitting looks like:
mkvmerge -o output-parts.mkv --split parts-framesx,-xx,-xx,- input.mkv

Command line for merging:
mkvmerge -o merged.mkv output-parts-001.mkv + output-parts-003.mkv

I haven't tried MKVCutter. The above workflow has generally worked for me in the past and usually handles my subtitles and audio tracks well. Perhaps I should try your tool.

I'm perplexed as to where these errors are coming from. What usually causes a non monotonic error?

[Selur]

What usually causes a non monotonic error?

problems with time codes,... is your content interlaced, telecined or vfr ?
instead of

 --split parts-frames: xx,-xx,-xx,-

Have you tried using:

--split parts-frames:start1-end1,+start2-end2,+start3-end3

note the '+'s.

[Travillion]

I have tried the code with the plus signs, and used to use that as my preferred method. However, because it is effectively cutting and merging, I always got non monotonic errors. The only way I could get error-free segments was to make distinct cuts. However, merging them now is producing the same errors I was trying to avoid.

Content is h264 1080p 23.976, no interlaced, vfr, or telecine.

I wonder if there is something wrong with the source, even though ffprobe reveals no problems.

[Selur]

found https://stackoverflow.com/questions/31691943/ffmpeg-concat-poduces-dts-out-of-order-errors but there the errors appear due to vfr content. (mix of 24 fps, 25 fps and 30 fps content)
Does it change the result if you add the fps to the mkvmerge call ? (using --default-duration or --fix-bitstream-timing-information)

[Travillion]

Thank you for the suggestion, I will try that later today.

[Travillion]

My command line for splitting looks like:
mkvmerge -o output-parts.mkv --split parts-framesx,-xx,-xx,- input.mkv

Command line for merging:
mkvmerge -o merged.mkv output-parts-001.mkv + output-parts-003.mkv

I haven't tried MKVCutter. The above workflow has generally worked for me in the past and usually handles my subtitles and audio tracks well. Perhaps I should try your tool.

I'm perplexed as to where these errors are coming from. What usually causes a non monotonic error?

I tried using mkvmerge on another video project and ran into cutting/joining problems again. Just like last time, mkvmerge cut the segments without producing errors, ffprobe revealed no errors, merging produced no errors, but ffprobe on the resulting file lists several errors. I can't understand why, but cutting/merging on my new system with mkvmerge/mkvtoolnix is not working well.

I tried MKVCutter but could not get it to run properly. I tried the latest two versions and both displayed the same behavior. The GUI launches, I select an mkv to open. It calls mkvinfo and reads in lines, then just disappears when it's done reading the file.

I'm running Windows 10 64-bit, Intel i9-9900k, 32GB RAM, and an m.2 SSD. Any ideas what is happening?

[jagabo]

Try cutting 2 frames before the keyframes.

https://forum.videohelp.com/threads/393342-Start-video-property#post2552202

[Travillion]

Try cutting 2 frames before the keyframes.

https://forum.videohelp.com/threads/393342-Start-video-property#post2552202

Thank you for the suggestion. The issue is not the cut points. I can verify that segments are being cut on the desired IDR frames. The issue is that for some reason they are not recombining without errors. They cut where they are supposed to cut, and ffprobe reveals no problems. I combine the desired segments and it plays fine, mkvmerge output indicates no errors, but ffprobe finds all sorts of issues with the resulting file. This did not happen on my old system when writing to an internal drive. On my new computer, it happens with all attempts. There seems to be some sort of incompatibility, but I don't know what that could be.