Bug 1120014 - Initialize MediaSourceReader::mLast{Audio,Video}Time to 0 rather than -1. r=rillian, a=sledru
authorBobby Holley <bobbyholley@gmail.com>
Fri, 09 Jan 2015 17:20:58 -0800
changeset 242859 201fee3158c1
parent 242858 7edfdc36c3cf
child 242860 aa8cdb057186
push id4322
push userryanvm@gmail.com
push date2015-01-14 15:18 +0000
treeherdermozilla-beta@82cce51fb174 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersrillian, sledru
bugs1120014
milestone36.0
Bug 1120014 - Initialize MediaSourceReader::mLast{Audio,Video}Time to 0 rather than -1. r=rillian, a=sledru There isn't actually any initialization code that sets them at 0. Instead, we currently rely on the fact that our first decoder ends up active regardless of what its buffered range reports. So as long as invoking the first Request{Audio,Video}Data is resolved, this ends up ok. But while that is usually the case, it isn't _always_ the case, especially in the case where the MP4Reader rejects with WAITING_FOR_DATA.
dom/media/mediasource/MediaSourceReader.cpp
--- a/dom/media/mediasource/MediaSourceReader.cpp
+++ b/dom/media/mediasource/MediaSourceReader.cpp
@@ -41,18 +41,18 @@ extern PRLogModuleInfo* GetMediaSourceAP
 #define EOS_FUZZ_US 125000
 
 using mozilla::dom::TimeRanges;
 
 namespace mozilla {
 
 MediaSourceReader::MediaSourceReader(MediaSourceDecoder* aDecoder)
   : MediaDecoderReader(aDecoder)
-  , mLastAudioTime(-1)
-  , mLastVideoTime(-1)
+  , mLastAudioTime(0)
+  , mLastVideoTime(0)
   , mPendingSeekTime(-1)
   , mPendingStartTime(-1)
   , mPendingEndTime(-1)
   , mPendingCurrentTime(-1)
   , mWaitingForSeekData(false)
   , mTimeThreshold(-1)
   , mDropAudioBeforeThreshold(false)
   , mDropVideoBeforeThreshold(false)