Some videos cannot be put into an mkv container being playable fluently v2.7

[jan771]

"Some timing information are incorrect" appears if you open the mp4 container:

timestamp.jpg

But the mp4 file is playing fluently, once you pack it as mkv it won't anymore. Regardless if you drop the timing information or keep it.

[eumagga0x2a]

Please provide a sample.

[jan771]

uploaded the files,
Balduin, sticky.mkv
Balduin, fluent.mp4
https://cloud.gmx.net/ngcloud/external?guestToken=djXXsvFRRsaWTpYg-9jgbQ&loginName=@334663428440331676#/:

also would be great, a possibility to manually tag audio lane type meta, because some aac-tracks are not being recognized correctly.

[eumagga0x2a]

Thank you, in the source video the PTS of decoded frames are wrong, the presentation timestamps supplied by the demuxer seem to be OK. No matter whether you deny dropping timestamps or not, we discard the correct ones from the demuxer and drop a lot of frames with PTS going back as the result (the "sticky" output).

[jan771]

you actually don't drop frames - you can convert it back to mp4 and it will be fluent again. I think it is due to sth. else in the mkv muxer, maybe a wrong frame rate? Or Timestamps only calculated for every 2nd frame? It seems that only 25fps instead of 50fps, but in fact 50fps are in the video-lane.

Maybe the timestamps are calculated for every frame, but every 2nd one gets the same stamp, unless somewhere in the code it thinks the video hast 25frames. Or the muxer did not get the 50fps option.

[AQUAR]

MKVToolnix explains the following:
The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.

That seems to explain why the video stutters on B frames when remuxed into an MKV container.

[eumagga0x2a]

The MKV sample doesn't stutter in mpv either, but my analysis was wrong anyway. PTS provided by the container are wrong, they are equal DTS, but the video seems to contain B-frames, so we end up with frames out of order. P-frames' PTS is "going back" then – the video seems to contain only of I- and B-frames (when decoded by Lavcodec).

The source for the MP4 sample was probably an AVI generated by services like online tv recorder who do cruel things like putting H.264 in AVI.

[jan771]

In my case the sticky.mkv is stuttering. I can only put this video stream in an mp4 container in order to prevent the video from stuttering.
I am using k-lite codec pack mega.

[AQUAR]

The PTS provided by the MKV container are wrong because it is missing the CTTS atom that provides timing offsets for some B frames.

I don't understand the ins and outs, therefore I'll just guess that the PTS/DTS is provided from other metadata (XPM?) when packaged in the MP4 container.

If you really want to put this media into an MKV container and avoid the stuttering, then you might try to remux it first into a transport container (TSMuxer) and then remux that into the MKV container (MKVToolnix) as that seems to incorporate these offsets.