Merge 21611 - Implemented proper pausethenseek behaviour for the media pipeli...

Merge 21611 - Implemented proper pausethenseek behaviour for the media pipeline.

MediaFilter now has asynchronous Play() and Pause() methods that are implemented by default.  Since we are a completely pullbased system, it turns out only AudioRendererBase and VideoRendererBase need to override them to halt reading from decoders.

When a seek is received by the pipeline, it goes through the following state transitions:
 1) Playing > Pausing > Paused (notify filters to stop reading)
 2) Paused > Seeking (notify filters to flush buffers and preroll)
 3) Seeking > Playing (preroll completed, resume playback)

The key to this system is that there must be no pending reads in *any* filter when we start transitioning into the seeking state.  That means the audio/video renderers do not complete their pausing>paused transition until they have completed all pending reads.  To reiterate, since we're pulled based if the renderers are not reading any data, then *nothing* is happening in the pipeline.

We get a lot of nice benefits from this assertion, namely no callbacks are ever "lost", they are always replied to until we are fully paused.  Furthermore, we can guarantee that the first buffer received after a Seek() will be guaranteed to be discontinuous.

This change also properly handles endofstream, seeking from an endofstream state, and displaying frames while paused.  In summary, I was able to call Seek() in a while(true) loop without crashing or going out of sync.

BUG=16014, 16021, 17456
TEST=seeking should be way more robust

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

TBR=scherkus@chromium.org


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=21799

[scherkus (not reviewing), 2009-07-28 02:12:37]

LGTM