Bug 1120014 - Initialize MediaSourceReader::mLast{Audio,Video}Time to 0 rather than -1. r=rillian
authorBobby Holley <bobbyholley@gmail.com>
Fri, 09 Jan 2015 17:20:58 -0800
changeset 223098 84c65d67215fbd78274d13a07167cd069b1ab9ef
parent 223097 5f6cebc36e84fb574d5809ac91bb1a42190658f4
child 223099 02ab5234c39e95266c536a9129ca56e87f9ea03e
push id28082
push usercbook@mozilla.com
push dateMon, 12 Jan 2015 10:44:52 +0000
treeherdermozilla-central@643589c3ef94 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersrillian
bugs1120014
milestone37.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1120014 - Initialize MediaSourceReader::mLast{Audio,Video}Time to 0 rather than -1. r=rillian 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)
   , mPendingSeeks(0)
   , mSeekResult(NS_OK)
   , mTimeThreshold(-1)