From 7ab0a911f94230b6d80e760d3112b016f23edc07 Mon Sep 17 00:00:00 2001 From: "ronghuawu@chromium.org" Date: Wed, 18 Apr 2012 02:14:58 +0000 Subject: Flush regardless if there's pending read, because there's no guarantee that the video decoder will fullfill the pending read. For example, in the RTC case, the video call may have been stopped by the time or the network may have broken, as a result the pending read may never complete. So I think we should always call the decoder flush and the decoder will take care of any pending request (with dummy or real frame) before flush. BUG=123134 TEST=media_unittests and webrtc video call Review URL: http://codereview.chromium.org/10094016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@132723 0039d316-1c4b-4281-b951-d872f2087c98 --- media/base/filters.h | 3 +++ 1 file changed, 3 insertions(+) (limited to 'media/base') diff --git a/media/base/filters.h b/media/base/filters.h index b32234f..e10048c 100644 --- a/media/base/filters.h +++ b/media/base/filters.h @@ -125,6 +125,9 @@ class MEDIA_EXPORT VideoDecoder : public Filter { // Non-NULL frames contain decoded video data or may indicate the end of // the stream. NULL video frames indicate an aborted read. This can happen if // the DemuxerStream gets flushed and doesn't have any more data to return. + // + // When Flush() is called VideoDecoder implementations should fulfill pending + // reads prior to executing the Flush() callback. typedef base::Callback)> ReadCB; virtual void Read(const ReadCB& read_cb) = 0; -- cgit v1.1