Android video capture: only use reference time for outbound timestamp.

media/capture/video/android/video_capture_device_android.h

Index: media/capture/video/android/video_capture_device_android.h
diff --git a/media/capture/video/android/video_capture_device_android.h b/media/capture/video/android/video_capture_device_android.h
index a0796eec803a5d4e99c73865f5f37e6c36203e03..9830e8aeba099bee3f310e086dc137a08973d945 100644
--- a/media/capture/video/android/video_capture_device_android.h
+++ b/media/capture/video/android/video_capture_device_android.h
@@ -87,7 +87,8 @@ class CAPTURE_EXPORT VideoCaptureDeviceAndroid : public VideoCaptureDevice {
                             jint uv_pixel_stride,
                             jint width,
                             jint height,
-                            jint rotation);
+                            jint rotation,
+                            jlong timestamp);
 
   // Implement org.chromium.media.VideoCapture.nativeOnError.
   void OnError(JNIEnv* env,
@@ -130,7 +131,6 @@ class CAPTURE_EXPORT VideoCaptureDeviceAndroid : public VideoCaptureDevice {
   std::list<base::Closure> photo_requests_queue_;
 
   base::TimeTicks expected_next_frame_time_;

[miu, 2016/08/31 21:09:16]

Seems like we should just get rid of |expected_next_frame_time_| and
|frame_interval_|. There were, at best, estimates. Now that we're plumbing in
the actual timestamps, let's get rid of these and the code doing any
"guesstimating."

[braveyao, 2016/08/31 23:01:28]

These two variables are for satisfying framerate constraints on Android. Before
we have another way to do it, they should be kept. 
If there is better way to do this, we can do it in anther cl.

[miu, 2016/09/02 21:49:15]

Acknowledged.

-  base::TimeTicks first_ref_time_;
   base::TimeDelta frame_interval_;
 
   // List of |photo_callbacks_| in flight, being served in Java side.