Bugs 529949 and 549744 were resolved by making implementation changes that broke the video frame "reference clock" timestamps. These changes wrapped the timestamps from the capture device into fake base::TimeTicks values. This is an abstraction violation, since TimeTicks values are always interpreted relative to the system clock.
Bug 597034 , and likely bug 587553 , track problems caused by the bad timestamps. In bug 597034 , a workaround was needed because the video frame reference timestamps were bogus. That was a band-aid solution to the real underlying problem.
The correct solution to the original problem is that BOTH the relative timestamp (from the capture device driver) and the reference clock timestamp (TimeTicks::Now()) need to be passed through the video stack, as each is necessary for different purposes:
1. The capture device timestamps (which should be set in media::VideoFrame::set_timestamp()) are needed to communicate the media duration/rate of the video frames for smooth playout.
2. The reference timestamps (from TimeTicks::Now()) are needed for the purposes of resolving Audio/Video synchronization via a common reference clock. The reference timestamp is allowed to be a little "noisy" because it is only being used to align the playout of the separate audio and video streams. In other words, it is used as a target or an "ideal" playout time, but never as an exact presentation time.
Comment 1 by m...@chromium.org
, Apr 8 2016