In Bug 1522238, we use webrtc::Clock::GetRealTimeClock() to set the frame timestamp.

As Andreas pointed out during review, we get the actual capture time above in QueueVideoChunk as a timestamp. We could convert that to a TimeDuration, e.g. by subtracting TimeStamp::GetProcessStart() and use that instead.

The wrinkle is that those timestamps could be in the future, which webrtc.org code explicitly disallows in video_stream_encoder.cc, resetting any future timestamps to the current time.

Beyond that, there's a bit of risk if we're not using the same epoch as the webrtc code for our timestamps, that if they do overwrite it, we'll end up sending out wildly varying timestamps which could cause difficult to track down bugs. Meet relies upon the timestamps being valid, so we should test that site carefully if we make any changes to the timestamps.

One solution that Andreas mentioned for the future timestamp problem is to buffer them locally in MediaPipeline until the future is now. We could also try to fix the upstream code to support this properly.

Here's an example of where the frame timestamp is expected to be directly comparable to the webrtc.org real time clock [1].

[1] https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/media/webrtc/trunk/webrtc/modules/rtp_rtcp/source/rtcp_sender.cc#482

This also fixes what looks like a bug with the timestamp (wrong base) in
WebrtcMediaDataDecoderCodec.

The new Pacer includes both pacing of incoming frames, and the duplication logic
from VideoFrameConverter. It guarantees that no events happen early, thanks to
MediaTimer.

The largest difference from the old pacing logic is that only one timer is used,
VideoFrameConverter used two -- one for pacing and one for same-frame
duplications. The same-frame timer was positioned later in the pipe, to avoid
convert the same input frame multiple times, something users of the new Pacer
will have to handle. Two timers however uncovered flaws from nsTimer -- namely
that the ordering between two timers is not guaranteed as there is no nsTimer
API using absolute timestamps. Using only one timer avoids this.

Backed out for causing bp-hybrid build bustages on TestPacer.

Push with failures

Failure log for OS X Cross Compiled plain
Failure log for Linux x64 plain
Failure log for Windows 2012 x64 debug

Backout link

https://hg.mozilla.org/mozilla-central/rev/d4a050b13db0
https://hg.mozilla.org/mozilla-central/rev/f5270dce0170
https://hg.mozilla.org/mozilla-central/rev/d091a7c071ba
https://hg.mozilla.org/mozilla-central/rev/d5aba13d6d90
https://hg.mozilla.org/mozilla-central/rev/17fbdf16f20f
https://hg.mozilla.org/mozilla-central/rev/7d48e575c07d
https://hg.mozilla.org/mozilla-central/rev/2e9e4635a3cc
https://hg.mozilla.org/mozilla-central/rev/810bed84bde4
https://hg.mozilla.org/mozilla-central/rev/4fe3ec529a44
https://hg.mozilla.org/mozilla-central/rev/e3a169560ee8