Bug 1349253 - modify the assertion; r=jwwang
authorKaku Kuo <kaku@mozilla.com>
Wed, 07 Jun 2017 18:52:36 +0800
changeset 411029 bf544b2ca2bc17569da68b4fbb277594f05eb4b6
parent 411028 c02a8965ab7cf4f71c5d0e1688d5398f9dc23a5c
child 411030 2d432523af9ff9bd0b059a49e4b5aa4fd3f56b28
push id7391
push usermtabara@mozilla.com
push dateMon, 12 Jun 2017 13:08:53 +0000
treeherdermozilla-beta@2191d7f87e2e [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersjwwang
bugs1349253
milestone55.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 1349253 - modify the assertion; r=jwwang While MDSM calls MFR::Seek(), MFR tries to do video seek first and then the audio seek. Video-seek and audio-seek are applied sequentially, and if something wrong in video-seek, MFR discards the whole seek operation without applying audio-seek. video | audio | waiting | waiting | What MDSM receives ----------------------------------------------------------------------------- X | X | resove mSeekRequest ----------------------------------------------------------------------------- O | X | reject mSeekRequest with type=VIDEO, error=WAITING ----------------------------------------------------------------------------- X | O | reject mSeekRequest with type=AUDIO, error=WAITING ----------------------------------------------------------------------------- O | O | reject mSeekRequest with type=VIDEO, error=WAITING ----------------------------------------------------------------------------- So, here, AccurateSeekingState::OnSeekRejected() has a unified code to handle WAITING_FOR_DATA error for both video and audio type, and it uses the aReject.mType variable to distinguish different types. But, it mixes the assertions. We should also apply assertions according to the type that is in concern. MozReview-Commit-ID: F7RpnFghcKk
dom/media/MediaDecoderStateMachine.cpp
--- a/dom/media/MediaDecoderStateMachine.cpp
+++ b/dom/media/MediaDecoderStateMachine.cpp
@@ -1282,20 +1282,21 @@ private:
   }
 
   void OnSeekRejected(const SeekRejectValue& aReject)
   {
     mSeekRequest.Complete();
 
     if (aReject.mError == NS_ERROR_DOM_MEDIA_WAITING_FOR_DATA) {
       SLOG("OnSeekRejected reason=WAITING_FOR_DATA type=%d", aReject.mType);
-      MOZ_ASSERT(!mMaster->IsRequestingAudioData());
-      MOZ_ASSERT(!mMaster->IsRequestingVideoData());
-      MOZ_ASSERT(!mMaster->IsWaitingAudioData());
-      MOZ_ASSERT(!mMaster->IsWaitingVideoData());
+      MOZ_ASSERT_IF(aReject.mType == MediaData::AUDIO_DATA, !mMaster->IsRequestingAudioData());
+      MOZ_ASSERT_IF(aReject.mType == MediaData::VIDEO_DATA, !mMaster->IsRequestingVideoData());
+      MOZ_ASSERT_IF(aReject.mType == MediaData::AUDIO_DATA, !mMaster->IsWaitingAudioData());
+      MOZ_ASSERT_IF(aReject.mType == MediaData::VIDEO_DATA, !mMaster->IsWaitingVideoData());
+
       // Fire 'waiting' to notify the player that we are waiting for data.
       mMaster->UpdateNextFrameStatus(
         MediaDecoderOwner::NEXT_FRAME_UNAVAILABLE_SEEKING);
       Reader()
         ->WaitForData(aReject.mType)
         ->Then(OwnerThread(), __func__,
                [this](MediaData::Type aType) {
                  SLOG("OnSeekRejected wait promise resolved");