Introduce TimeSource notifications to the VideoRenderer.

media/renderers/renderer_impl.cc

Index: media/renderers/renderer_impl.cc
diff --git a/media/renderers/renderer_impl.cc b/media/renderers/renderer_impl.cc
index 8088b07c7157d298c34283d4cd1ea3e7611ad645..ceb1e015255f1718af91368bd9eb6ce12cbbc0e7 100644
--- a/media/renderers/renderer_impl.cc
+++ b/media/renderers/renderer_impl.cc
@@ -35,6 +35,7 @@ RendererImpl::RendererImpl(
       video_renderer_(video_renderer.Pass()),
       time_source_(NULL),
       time_ticking_(false),
+      playback_rate_(0),
       audio_buffering_state_(BUFFERING_HAVE_NOTHING),
       video_buffering_state_(BUFFERING_HAVE_NOTHING),
       audio_ended_(false),
@@ -177,6 +178,16 @@ void RendererImpl::SetPlaybackRate(float playback_rate) {
     return;
 
   time_source_->SetPlaybackRate(playback_rate);
+
+  const float old_rate = playback_rate_;
+  playback_rate_ = playback_rate;
+  if (!time_ticking_ || !video_renderer_)
+    return;
+
+  if (old_rate == 0 && playback_rate > 0)
+    video_renderer_->OnTimeProgressing();
+  else if (old_rate > 0 && playback_rate == 0)
+    video_renderer_->OnTimeStopped();

[xhwang, 2015/04/07 06:13:08]

This will definitely work. I just wonder whether we can have a slightly cleaner
interface. Here are some brainstorming ideas:
- VideoRenderer actually can detect time stop because wall_clock_time_cb starts
to return null time. This could replace OnTimeStopped()...
- Even with that, we still need something like OnTimeProgressing() to kick start
decoding again.
- Maybe we can just reintroduce SetPlaybackRate() to VideoRenderer again :( ?
Sounds bad though...
- Maybe we can extend/reuse VideoRenderer::StartPlayingFrom(time) such that when
|time| is null, we keep the original |start_timestamp_| and just kick start a
Read()?

[DaleCurtis, 2015/04/07 16:51:40]

Yeah, I considered all of these except the last one; I don't really like them
any more than your comments suggest. The detection one ends up with repeated
polling.

Adding SetPlaybackRate back can make things a little more accurate in the future
VideoRendererAlgorithm, because we can instead calculate the frame duration
based on the frame timestamps + playback rate instead of the wallclock
timestamps (which might have shifted between subsequent calls; this could be
fixed by instead changing WallClockTimeCB to work with a vector of timestamps if
it ends up being a problem).

I think the last idea you suggest won't work for preroll.

Another complicated idea I had in the vein of what we discussed, is to create a
TimeSourceOracle who is a TimeSource. All renderers would expose a
GetTimeSource() which vended a subset of today's TimeSource interface (say
TimeSourceFeeder). The oracle would decide amongst the TimeSourceFeeder objects
and also notify them as time starts or stops.

In the ideal case that would have saved a bunch of code in AudioRenderer,
Renderer, and VideoRenderer. In the actual case, the AudioClock is strongly tied
into the AudioRendererImpl and AudioRendererAlgorithm so it didn't end up saving
very much after all and seems overly complicated.

 }
 
 void RendererImpl::SetVolume(float volume) {
@@ -532,6 +543,8 @@ void RendererImpl::PausePlayback() {
 
   time_ticking_ = false;
   time_source_->StopTicking();
+  if (playback_rate_ > 0 && video_renderer_)
+    video_renderer_->OnTimeStopped();
 }
 
 void RendererImpl::StartPlayback() {
@@ -543,6 +556,8 @@ void RendererImpl::StartPlayback() {
 
   time_ticking_ = true;
   time_source_->StartTicking();
+  if (playback_rate_ > 0 && video_renderer_)
+    video_renderer_->OnTimeProgressing();
 }
 
 void RendererImpl::OnAudioRendererEnded() {