Previously the tests would check if playback had started by looking at the first
recorded time, and then looking at the current time. If there were a lag it was
possible for the first recorded time to be at the end of the video (i.e.
playback already finished), in which case the video playing would not register.
This patch instead uses the played ranges from the video element. Now so long as
there is a non-empty played range we trust playback started.
MozReview-Commit-ID: 5C39A42KRdj
--HG--
extra : rebase_source : e4e8a35df3bac4c9e7765272acb6300b44b45d4e
This behaviour changed as part of Bug 1279493, and the tests should be updated
to reflect this.
MozReview-Commit-ID: oITf0hVjKk
--HG--
extra : rebase_source : 26f54e0ac49a2f27f364c75a63851df5a85ce18f
I also added more testing around ClearKey's base64 decoding, since that affected
how keyIds were handled.
MozReview-Commit-ID: 2UH1JNT4NC3
--HG--
extra : rebase_source : 8e2c861e6b030d7e4a1378d3fafed7630324d940
Calling NotifyDataArrived from each sourcebuffer will cause multiple unnecessary NotifyDataArrived to the MediaFormatReader when it could only be done once. Additionally, it ensures that the media duration is updated prior to the reader actioning on the notification.
Extra: mEnded is only ever accessed on the main thread, there's no need to make it atomic.
MozReview-Commit-ID: IKq7IRBbWic
--HG--
extra : rebase_source : 6cf18b1f71f5ee6c8e82c73bdd2857e783f343b8
The duration in the MediaDecoder is the canonical. It has as such a more up to date value than the mirror.
Under some circumstances, the MDSM may have reached the end of media playback before the duration mirror had time to update. So perform the currentTime adjustment in the MediaDecoder instead.
MozReview-Commit-ID: 1RFr4mT5LpA
--HG--
extra : rebase_source : 3151d86561b53d5d1922c7c16f042792bfd47283
With MediaSource, the duration is always known and exact. It is entirely possible that we have played data at some point, then removed that data and adjusted the duration.
MozReview-Commit-ID: HZe2yXtQfIL
--HG--
extra : rebase_source : be1b57575c28142d6b3091b23894a7e4e1c9b405
Functions deprecated in GTK3 are often used for compatibility with GTK2
builds.
MozReview-Commit-ID: F220phw3wVO
--HG--
extra : rebase_source : 128e885652b184c5a7916378d9cebb067ab97eb0
1. Called from SourceBuffer::AppendDataCompletedWithSuccess() where mMediaSource->GetDecoder() is not null.
2. Called from MediaDecoder::ResourceCallback::NotifyBytesDownloaded() which is disconnected in Shutdown().
MozReview-Commit-ID: 103pxZP02Bb
--HG--
extra : rebase_source : 72e8a9c29d5ca6a4932de3a119497b05bfadbe68
1. Called from SourceBuffer::AppendDataCompletedWithSuccess() where mMediaSource->GetDecoder() is not null so this must happen before Shutdown().
2. Called from SourceBuffer::Ended() where mMediaSource->GetDecoder() is not null.
3. Called from MediaDecoder::ResourceCallback::TimerCallback() which is canceled in Disconnect().
MozReview-Commit-ID: 5dqVuOcrABy
--HG--
extra : rebase_source : a134f552c4fae2317cbf93dc1e861199d4c91346
This is a follow up from bug 1289623, as I missed a few cases in that bug.
MozReview-Commit-ID: DM7FtVSZUo3
--HG--
extra : rebase_source : 4fd7ae93b1418ded54f0c21a50a654fc962d4892
Bump deps. Previous deps resulting in failures with current builds.
MozReview-Commit-ID: BUEfDmmE00E
--HG--
extra : rebase_source : a5437a86a875531945c558fab9427c6c31059289
This file only uses functions on nsIXPConnect, so it can get it from
nsContentUtils and stop including xpcprivate.h, which eliminates
another file from being rebuilt when xpcprivate.h gets touched.
MozReview-Commit-ID: AT5Khu0vkyf
--HG--
extra : rebase_source : fa40afb7df9afe1dede714c111947e4e85aee34e
Add native method calls to AndroidGamepadManager to replace the gamepad
events in GeckoEvent. Implement those calls in AndroidGamepad.cpp. The
jni/Refs.h change is necessary to fix a compile error when using
jni::BooleanArray.