Use microsecond timestamp in cricket::VideoFrame.

webrtc/media/engine/webrtcvideoengine2_unittest.cc

 /*
  *  Copyright (c) 2004 The WebRTC project authors. All Rights Reserved.
  *
  *  Use of this source code is governed by a BSD-style license
  *  that can be found in the LICENSE file in the root of the source
  *  tree. An additional intellectual property rights grant can be found
  *  in the file PATENTS.  All contributing project authors may
  *  be found in the AUTHORS file in the root of the source tree.
  */
 
@@ skipping 465 matching lines @@
     // Allow error to be no more than 1.
     EXPECT_NEAR(cricket::VideoFormat::FpsToInterval(30) / 1E6, interval, 1);
 
     last_timestamp = timestamp;
   }
 
   // Remove stream previously added to free the external encoder instance.
   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;
   encoder_factory.AddSupportedVideoCodecType(webrtc::kVideoCodecVP8, "VP8");
   std::vector<cricket::VideoCodec> codecs;
   codecs.push_back(kVp8Codec);
 
   FakeCall* fake_call = new FakeCall(webrtc::Call::Config());
   call_.reset(fake_call);
   std::unique_ptr<VideoMediaChannel> channel(
       SetUpForExternalEncoderFactory(&encoder_factory, codecs));
 
   EXPECT_TRUE(
       channel->AddSendStream(cricket::StreamParams::CreateLegacy(kSsrc)));
   channel->SetSend(true);
   FakeVideoSendStream* stream = fake_call->GetVideoSendStreams()[0];
 
   FakeVideoCapturer capturer1;
   EXPECT_TRUE(channel->SetCapturer(kSsrc, &capturer1));
 
   cricket::CapturedFrame frame;
   frame.width = 1280;
   frame.height = 720;
   frame.fourcc = cricket::FOURCC_I420;
   frame.data_size = frame.width * frame.height +
                     2 * ((frame.width + 1) / 2) * ((frame.height + 1) / 2);
   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);
   // Deliver next frame 1 second later.
   frame.time_stamp += rtc::kNumNanosecsPerSec;
   rtc::Thread::Current()->SleepMs(1000);
   capturer1.SignalCapturedFrame(&frame);
 
   int64_t capturer1_last_timestamp = stream->GetLastTimestamp();
   // Reset input source, should still be continuous even though input-frame
   // timestamp is less than before.
   FakeVideoCapturer capturer2;
   EXPECT_TRUE(channel->SetCapturer(kSsrc, &capturer2));
 
   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.
   EXPECT_GT(stream->GetLastTimestamp(), capturer1_last_timestamp);
 
   EXPECT_TRUE(channel->RemoveSendStream(kSsrc));
 }
 
 VideoMediaChannel* WebRtcVideoEngine2Test::SetUpForExternalEncoderFactory(
     cricket::WebRtcVideoEncoderFactory* encoder_factory,
@@ skipping 3037 matching lines @@
 }
 
 // Test that we normalize send codec format size in simulcast.
 TEST_F(WebRtcVideoChannel2SimulcastTest, SetSendCodecsWithOddSizeInSimulcast) {
   cricket::VideoCodec codec(kVp8Codec270p);
   codec.width += 1;
   codec.height += 1;
   VerifySimulcastSettings(codec, 2, 2);
 }
 }  // namespace cricket