Better seeking for <video> and <audio>

There two problems surrouding the seek feature for
<video> and <audio>:
1. After each seek, the time goes back and forth until
   stable, so user has to "fight" the time bar for
   seeking.
2. When playing an audio file, sounds plays a litte bit
   and then the play position rewinded and plays again.

The cause of above problems:
1. There are demuxed packets and decoded buffers inside
   decoders and renderers. When seek is requested only
   demuxer flush its buffers, decoders and renderers
   still plays a little bit of the old buffer, thus
   updating the time incorrectly.
2. When playing a media file, WebKit does:
   1. load()
   2. pause()
   3. seek(0.0f)
   4. play()
   Since load() does prerolling internally, there were
   some decoded buffers in the renderers, and when
   seek(0.0f) is fired the play position reset to time
   0 and decode starts from there again, the internal
   buffer queue in the renderer would then look like:

   | 0.0s | | 0.1s | | 0.2s | | 0.0s | | 0.1s | ...

   Thus playback at the beginning goes back and forth.

To solve the seek problems, here's what is done in this CL:
1. All decoders and renderers should receive the seek signal.
2. When seek signal is received, discard all buffers and
   schedule read again.

With this CL, we can now scrub an <audio> tag with the timebar.
The downside of this fix is that we don't have prerolling
(notice that due to how WebKit starts playing back we didn't
preroll anyway...), this should be fixed in another CL.

Review URL: http://codereview.chromium.org/113891

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17242 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 9 insertions, 0 deletions

diff --git a/media/base/pipeline_impl.cc b/media/base/pipeline_impl.cc
index 88c3537..49ffb98 100644
--- a/media/base/pipeline_impl.cc
+++ b/media/base/pipeline_impl.cc
@@ -488,6 +488,15 @@ void PipelineThread::SeekTask(base::TimeDelta time,
        ++iter) {
     (*iter)->media_filter()->Seek(time);
   }
+
+  // TODO(hclam): we should set the time when the above seek operations were all
+  // successful and first frame/packet at the desired time is decoded. I'm
+  // setting the time here because once we do the callback the user can ask for
+  // current time immediately, which is the old time. In order to get rid this
+  // little glitch, we either assume the seek was successful and time is updated
+  // immediately here or we set time and do callback when we have new
+  // frames/packets.
+  SetTime(time);
   if (seek_callback) {
     seek_callback->Run(true);
     delete seek_callback;