This can be reproduced with any h264 stream, created by ffmpeg/libx264 or not.
The pts of first packet/block will always be a few ms ahead after re/muxing, which adds to the total duration (10.080s vs 10.000s in this case)

Change History (17)

Well, for starters it's making the final duration value wrong (Should be 10 seconds, ends up being 10.08 seconds in the examples above).

Aside from that, now that we're writing cues for subtitle packets, those extra milliseconds added during muxing are in many cases making a video keyframe cue have a higher timestamp than the timestamp from a subtitle cue that comes right after it, which should not happen and promptly triggers warnings in mkvalidator (Something that doesn't happen with other codecs, like vp8 or theora, that start at pts 0).

Maybe the subject of the ticket should be changed? What's happening here is that during muxing, a few ms are added to each packet's ts value.
I don't know if starting at 0 or not is correct for mkv-h264, but afaics that's not the actual issue here.