Drop dependency on webrtc's tick_utils.h.

content/renderer/media/rtc_video_encoder.cc

Index: content/renderer/media/rtc_video_encoder.cc
diff --git a/content/renderer/media/rtc_video_encoder.cc b/content/renderer/media/rtc_video_encoder.cc
index e01a706c25102b9d4f934673a30666172103bb08..ae67c980bc3c3dc8227633703d32bfee5f9f7444 100644
--- a/content/renderer/media/rtc_video_encoder.cc
+++ b/content/renderer/media/rtc_video_encoder.cc
@@ -25,7 +25,7 @@
 #include "media/renderers/gpu_video_accelerator_factories.h"
 #include "media/video/video_encode_accelerator.h"
 #include "third_party/libyuv/include/libyuv.h"
-#include "third_party/webrtc/system_wrappers/include/tick_util.h"
+#include "third_party/webrtc/base/timeutils.h"
 
 namespace content {
 
@@ -422,7 +422,7 @@ void RTCVideoEncoder::Impl::BitstreamBufferReady(int32_t bitstream_buffer_id,
 
   // Use webrtc timestamps to ensure correct RTP sender behavior.
   // TODO(hshi): obtain timestamp from the capturer, see crbug.com/350106.
-  const int64_t capture_time_us = webrtc::TickTime::MicrosecondTimestamp();
+  const int64_t capture_time_us = rtc::TimeMicros();

[perkj_webrtc, 2016/04/14 13:46:23]

IS the todo above easy to fix? This should come from the input frame and not be
stamped here. This is a bug and leads to wrong timestamp at reconstruction of
the frame on the receiving side.

[nisse-webrtc, 2016/04/19 11:12:41]

No idea really, but I don't think this cl should depend on that. pbos and
jansson have commented on the bug recently.

 
   // Derive the capture time (in ms) and RTP timestamp (in 90KHz ticks).
   const int64_t capture_time_ms = capture_time_us / 1000;