IssueTracker

Chrome Version: (copy from chrome://version)
Lacros Version (if applicable): (copy from chrome://version)
OS: (e.g. Win10, MacOS 10.12, etc...)

There is a comment during a code review,
https://chromium-review.googlesource.com/c/chromium/src/+/4674645?tab=comments

"The duration in the stts should be selected so that the start timestamp of each frame is as accurate as possible. Imagine one minute (60,000ms) at 60Hz; this code will compute that each frame is 16ms, and so the total duration will be 60s * 60Hz * 16ms = 57,600ms. The video will have drifted from the audio track by 2.4s due to rounding!

Instead, the stts durations should be computed as the difference between the frame's end time, minus the sum of the stts durations so far.

One way to accomplish this is to store the frame end times, then the writer can do:"

int64_t dts = 0;
for (auto end_time : frame_end_times) {
int64_t next_dts = ToTimescale(end_time, timescale);
int64_t duration = next_dts - dts;
WriteI32(duration);
dts = next_dts;
}

TimeDelta unit should not be converted other than its own units so conversion to the timescale should be made in the box writer, not a up-front.

Please use labels and text to provide additional information.

If this is a regression (i.e., worked before), please consider using
the bisect tool (https://www.chromium.org/developers/bisect-builds-py)
to help us identify the root cause and more rapidly triage the issue.

For graphics-related bugs, please copy/paste the contents of the
about://gpu page at the end of this report.