Change the TimeSource interface to return wallclock time for video.

media/renderers/audio_renderer_impl.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "media/renderers/audio_renderer_impl.h"
 
 #include <math.h>
 
 #include <algorithm>
 
@@ skipping 148 matching lines @@
   base::TimeDelta current_media_time;
   {
     base::AutoLock auto_lock(lock_);
     current_media_time = audio_clock_->front_timestamp();
   }
 
   DVLOG(2) << __FUNCTION__ << ": " << current_media_time;
   return current_media_time;
 }
 
-base::TimeDelta AudioRendererImpl::CurrentMediaTimeForSyncingVideo() {
-  DVLOG(3) << __FUNCTION__;
+base::TimeTicks AudioRendererImpl::GetWallclockTimeForMediaTime(
+    base::TimeDelta time) {
+  base::AutoLock auto_lock(lock_);
+  if (last_render_ticks_.is_null() || playback_rate_ == 0.0)
+    return base::TimeTicks();
 
-  base::AutoLock auto_lock(lock_);
-  if (last_render_ticks_.is_null())
-    return audio_clock_->front_timestamp();
+  base::TimeDelta base_time;
+  if (time < audio_clock_->front_timestamp()) {
+    // TODO(dalecurtis): This will estimate using the wrong playback rate, if it
+    // has changed recently... Is this actually a problem?

[xhwang, 2015/03/23 22:20:14]

scherkus showed me how time could go backwards in this case. If that happens,
will we have jittering in video frame scheduling?

[DaleCurtis, 2015/03/25 00:31:45]

If someone is rapidly oscillating the playback rate then yes, scheduling could
get a bit ugly; otherwise I'd expect just a momentary glitch on some playback
rate changes, which I think is acceptable.

I've clarified the comments on TimeSource about the potential issues that can
occur if a time before the current media time is requested.

[xhwang, 2015/03/25 04:10:50]

Just OCC, when time goes backwards, could we render two video frames in the
wrong order? I wonder whether there's a way to make sure wall time never goes
back when media time advances. We can chat on this offline....

+    base_time = audio_clock_->front_timestamp();
+  } else if (time > audio_clock_->back_timestamp()) {
+    base_time = audio_clock_->back_timestamp();
+  } else {
+    // No need to estimate time, so return the actual wallclock time.
+    return last_render_ticks_ + audio_clock_->TimeUntilPlayback(time);
+  }
 
-  return audio_clock_->TimestampSinceWriting(base::TimeTicks::Now() -
-                                             last_render_ticks_);
+  // In practice, most calls will be estimates given the relatively small window
+  // in which clients can get the actual time.
+  return last_render_ticks_ + audio_clock_->TimeUntilPlayback(base_time) +
+         base::TimeDelta::FromMicroseconds((time - base_time).InMicroseconds() /
+                                           playback_rate_);
 }
 
 TimeSource* AudioRendererImpl::GetTimeSource() {
   return this;
 }
 
 void AudioRendererImpl::Flush(const base::Closure& callback) {
   DVLOG(1) << __FUNCTION__;
   DCHECK(task_runner_->BelongsToCurrentThread());
 
@@ skipping 551 matching lines @@
            << buffering_state;
   DCHECK_NE(buffering_state_, buffering_state);
   lock_.AssertAcquired();
   buffering_state_ = buffering_state;
 
   task_runner_->PostTask(FROM_HERE,
                          base::Bind(buffering_state_cb_, buffering_state_));
 }
 
 }  // namespace media