Use microsecond timestamp in cricket::VideoFrame.

webrtc/media/engine/webrtcvideoengine2_unittest.cc

Index: webrtc/media/engine/webrtcvideoengine2_unittest.cc
diff --git a/webrtc/media/engine/webrtcvideoengine2_unittest.cc b/webrtc/media/engine/webrtcvideoengine2_unittest.cc
index e1f540660f2f87a96b0acbbf9168beb89e9c6a6f..f720d37d003ff597f93ca8e7ddbea6d31b558b5e 100644
--- a/webrtc/media/engine/webrtcvideoengine2_unittest.cc
+++ b/webrtc/media/engine/webrtcvideoengine2_unittest.cc
@@ -483,6 +483,8 @@ TEST_F(WebRtcVideoEngine2Test, PropagatesInputFrameTimestamp) {
   EXPECT_TRUE(channel->RemoveSendStream(kSsrc));
 }
 
+// TODO(nisse): This test should be no longer needed when the

[perkj_webrtc, 2016/04/08 14:52:18]

why not? 

[nisse-webrtc, 2016/04/11 06:58:56]

Because it should be the responsibility of whoever creates the frames to use
rtc::TimeMicros timescale, which by definition is increasing. And then there's
no need for the videoengine to check for or fix jumps in that time stamp.

I'm not 100% sure we can get rid of all time jump hacks, though. One mostly
hypothetical case is a camera with a free running clock. Then the if the
capturer determines a fix offset on first frame and applies that as frames are
created (like in a previous iteration of this cl), then as the the cameras clock
slowly drifts away, we will get smallish time jumps when switching between this
source and other sources which use a properly synchronized clock.

We may also be small jumps at source switch due do different delays for the two
sources (or simply races) between the frames being captured, and they reach
WebRtcVideoSendStream::OnFrame.

If downstream code is confused by small time jumps, yet another alternative may
be to record the timestamp of the latest seen frame and enforce increasing
timestamps by simply dropping frames which are too early. Or setting timestamp
to last_timestamp+1 until it catches up.

But I don't think it's appropriate for the videoengine to compute and apply an
offset to all frames. That will break lipsync to audio channel using
rtc::TimeMicros timestamps. And when removing that, this test should be deleted
or significantly revamped.

+// timestamp_us refactoring is done.
 TEST_F(WebRtcVideoEngine2Test,
        ProducesIncreasingTimestampsWithResetInputSources) {
   cricket::FakeWebRtcVideoEncoderFactory encoder_factory;
@@ -512,8 +514,8 @@ TEST_F(WebRtcVideoEngine2Test,
   std::unique_ptr<char[]> data(new char[frame.data_size]);
   frame.data = data.get();
   memset(frame.data, 1, frame.data_size);
-  const int kInitialTimestamp = 123456;
-  frame.time_stamp = kInitialTimestamp;
+  int64_t initial_timestamp = rtc::TimeNanos();
+  frame.time_stamp = initial_timestamp;
 
   // Deliver initial frame.
   capturer1.SignalCapturedFrame(&frame);
@@ -531,7 +533,7 @@ TEST_F(WebRtcVideoEngine2Test,
   rtc::Thread::Current()->SleepMs(1);
   // Deliver with a timestamp (10 seconds) before the previous initial one,
   // these should not be related at all anymore and it should still work fine.
-  frame.time_stamp = kInitialTimestamp - 10000;
+  frame.time_stamp = initial_timestamp - 10 * rtc::kNumNanosecsPerSec;;
   capturer2.SignalCapturedFrame(&frame);
 
   // New timestamp should be at least 1ms in the future and not old.