diff options
author | scherkus@chromium.org <scherkus@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-25 02:12:11 +0000 |
---|---|---|
committer | scherkus@chromium.org <scherkus@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-25 02:12:11 +0000 |
commit | 354589750cf3959506e5c2a34e66cc462fb7f3c4 (patch) | |
tree | 7d1a283d2cc5e4c3caf2686c42fcd5a0b5f8eb04 /net | |
parent | 30bcf3718ace8f0ab46be60f318b476b658217b2 (diff) | |
download | chromium_src-354589750cf3959506e5c2a34e66cc462fb7f3c4.zip chromium_src-354589750cf3959506e5c2a34e66cc462fb7f3c4.tar.gz chromium_src-354589750cf3959506e5c2a34e66cc462fb7f3c4.tar.bz2 |
Implemented proper pause-then-seek behaviour for the media pipeline.
MediaFilter now has asynchronous Play() and Pause() methods that are implemented by default. Since we are a completely pull-based 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 end-of-stream, seeking from an end-of-stream 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
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21611 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions