Fix ChunkDemuxer seek deadlock

media/filters/video_renderer_base.cc

Index: media/filters/video_renderer_base.cc
diff --git a/media/filters/video_renderer_base.cc b/media/filters/video_renderer_base.cc
index df7350c23d6b640df37cb2101c18a0fe12b30b52..f2edff1cefe63ddde0e915ca2e3ada978cbd6e37 100644
--- a/media/filters/video_renderer_base.cc
+++ b/media/filters/video_renderer_base.cc
@@ -336,8 +336,6 @@ void VideoRendererBase::PutCurrentFrame(scoped_refptr<VideoFrame> frame) {
 }
 
 void VideoRendererBase::FrameReady(scoped_refptr<VideoFrame> frame) {
-  DCHECK(frame);
-
   base::AutoLock auto_lock(lock_);
   DCHECK_NE(state_, kUninitialized);
   DCHECK_NE(state_, kStopped);
@@ -352,6 +350,15 @@ void VideoRendererBase::FrameReady(scoped_refptr<VideoFrame> frame) {
     return;
   }
 
+  if (!frame) {

[Ami GONE FROM CHROMIUM, 2012/01/29 22:12:38]

I thought this test encompassed the entire remainder of the function.  But now I
see that's not the case.  Is it really correct to not look at the ready_frames
in this case?

[acolwell GONE FROM CHROMIUM, 2012/01/30 00:14:14]

I believe so. Getting a NULL frame means that the demuxer has no more data to
give and continuing to ask will only give you more NULL responses. This means
that we will never exit a seek. The NULL frames are triggered by a new seek
requested at the WebMediaPlayerImpl level so finishing out a preroll wouldn't do
us any good because all the data will be immediately flushed anyways.

Added a comment indicating why we are early terminating the seek.

+    if (state_ != kSeeking)
+      return;
+
+    state_ = kPrerolled;
+    ResetAndRunCB(&seek_cb_, PIPELINE_OK);
+    return;
+  }
+
   // Discard frames until we reach our desired seek timestamp.
   if (state_ == kSeeking && !frame->IsEndOfStream() &&
       (frame->GetTimestamp() + frame->GetDuration()) <= seek_timestamp_) {