Millisecond rounding issues

[rmrm]

This might not be fixable on all cases, but still...

Aegisub truncates video timestamps to the millisecond. However when muxing to MKV, timestamps are rounded to the nearest millisecond. For an example of a problem caused by this, see the attached testcase. Frame 1159 has a timestamp of 1159*1001/24000=48.3399... seconds which Aegisub reports as 48.339. A subtitle starting on 48.34 is not shown on that frame.

However after muxing to MKV, that timestamp rounds up to 48.340, showing on that frame.

Of course fixing the MKV case breaks the MP4+ASS case (apparently VSFilter does as Aegisub and truncates to milliseconds - see "Test2" in frame 808 which has a timestamp of 33.7003... but gets shown with a start time of 33.70). I think it's reasonable to try and get the MKV case right since that's the most likely container for frame-precise timed subtitles.

Or maybe add a switch, or a warning ("mux the video to mkv first if that's what you're going to use"), or something.

[Plorkyeran]

I don't think this is really fixable on our end, as assuming that the subs will be muxed into matroska with 1ms precision has the potentially to break every single other case.

The simplest workaround is to simply not time lines such that rounding errors could shift the start or end to different frames. All of the various frame snapping features in Aegisub (ctrl-3/4/5/6, the TPP, etc.) set the start and end times to the middle of the frames precisely to avoid this sort of problem. Shifting all lines by zero frames will do the same thing to any lines timed in a different way.

[Plorkyeran]

As of r4662 MKV-style rounding is now used when v1 timecodes are loaded.

I don't think there's really anything else we can do about this, as displaying a warning whenever a non-MKV video is opened would be awful.