1. Sort by TextTrack. 2. Sort by time. 3. Sort by the order of added to TextTrack.
MozReview-Commit-ID: 4nwx6U5dMpy
--HG--
extra : rebase_source : 2998c48982e40604b068ffca525691c5b69ae2cf
This removes the dependency on the Marionette server-side logging API
from the external media tests. Instead, we rely on client-side logging
alternatives.
MozReview-Commit-ID: 8kMhMflYh4q
--HG--
extra : rebase_source : 0994bc9549309d7e603a5a9b550c31a7a3332b4a
As long as we're undecided whether the data we're being fed is actually a valid MPEG stream, we only search a limited amount of data for a valid frame header before giving up. Once we have found a valid frame header however, we change our behavior and search until EOS for the next frame in order to cope with possibly corrupted streams.
In practice it has turned out that the first MPEG frame we detect might in fact be a false positive. Therefore, we now turn any found frame into a candidate frame at first and only accept it as the real first frame if it is followed by at least two other matching frames in succession.
As currently implemented, our MAX_SKIPPED_BYTES logic however doesn't know about this and turns itself off as soon as we've found anything that *looks* like a valid MP3 frame header. This means that if that frame was in fact a false positive, we can now go off on a wild goose chase through what might potentially be the *whole* file while looking for putative followup frames.
To fix this, the parser now records not just whether it has found *any* frame, but also whether it has detected a *succession of valid frames* and then sets the amount of bytes to be searched for the next frame based on that state.
MozReview-Commit-ID: 3WQTfLg88kV
--HG--
extra : rebase_source : 2bd84568f1e138d1d9bafdab96ddae705dd0a286
(1) Check if we should instantiate HLSDecoder in DecoderTraits::InstantiateDecoder.
(2) Reply CANPLAY_MAYBE in CanHandleMediaType on Fennec.
MozReview-Commit-ID: 4Y6Ju5yk6ha
--HG--
extra : rebase_source : 0755d580ac3e415849afc9f7f5f6ffd2d0dfc870
The next version of the Widevine CDM (970) has a new H.264 decoder and it does
not appear to be outputing frames it decodes in presentation order, so we need
to reorder the frames output by the CDM.
MozReview-Commit-ID: HMsQVN3NCIU
--HG--
extra : rebase_source : 68ef406556087434fa12b72ae5ed5c2e1bce2b64
The same reason as P1. ShutdownState::Enter() disconnects callbacks to prevent
DecodeError() from being called during shutdown.
MozReview-Commit-ID: EFZiE2zkcUZ
--HG--
extra : rebase_source : 279d5fcdc79f2d4d7861cea627c4314b26aa5da5
Now we can init some members in the constructor and remove the setters
that are called only once.
MozReview-Commit-ID: 2hkrIA6pFlh
--HG--
extra : rebase_source : 33c008ef1508597e64ef7f92b028867dbd4ffba6
extra : source : fa213ee733ea881f4f76dac06c9b4709aeba4b91
We will add more fields to MediaDecoderInit and be able to remove some setters.
MozReview-Commit-ID: BVx935IHQHf
--HG--
extra : rebase_source : 6d167265e478ce39881ceada1303e9ca18189bbf
extra : source : 0c26f909568f673591ad6720458dfc912c01daad
The sandbox blocks loading of GMPs when the GMP resides in a directory stored
in a path which contains a symlink or junction point. So resolve GMP paths
fully before instantiating the GMP process.
MozReview-Commit-ID: EvPCpNIDNwg
--HG--
extra : rebase_source : 7df8236c9988a674ae128faf63b949fd711ab4e0
This patch is adapted from Tor bug 1517.
To offer some protection against timing attacks by JS content pages, in this
patch we round the various time-exposing APIs (such as Date and
Event.timeStamps) to the nearest 100 ms when the pref "privacy.resistFingerprinting" is on.
MozReview-Commit-ID: eGucM9nGTn
--HG--
extra : rebase_source : 3ee600b07943f3954e9a2a9561391f2f7821bb86
The VP9 decoder doesn't properly set the sample duration, leading to all samples being marked as having a zero duration.
The compositor drops those frames incorrectly. This issue will be addressed in bug 1222874.
MozReview-Commit-ID: JQdtTL4nAN
--HG--
extra : rebase_source : 7c69cd3522c4b2231a07ab3f3c1d012843ac2f69
Using a float to store the last duration was unwise (as it has only a 24 bits mantissa), luckily it wasn't used except very particular circumstances.
MozReview-Commit-ID: BpL8ufQFNeR
--HG--
extra : rebase_source : b4a5a1301be4a0a81d1907b6296cbb4b6c4877d9
SupportsMimeType is called in the content process, for which, following bug 1338011, dxva is marked as disabled.
CanCreateWMFDecoder already performs the check of allowing VP9 only if it's hardware accelerated, so we don't need to test if dxva is enabled prior.
MozReview-Commit-ID: 7Jvaop6ZznU
--HG--
extra : rebase_source : 854e7b09718863e710843d11c9327de47abf1076
Make sure we test the other major container we
need to parse correctly.
MozReview-Commit-ID: AnrGADFXPkw
--HG--
extra : rebase_source : 5e20580d0900a62f923b96089410845c187ac2a7
Prior bug 1313398, the only time we would call H264Converter::CreateDecoderAndInit was if we encountered AVC3 content where the H264 extradata didn't exist in the metadata.
AVC3 was the only situation where mDecoder would be null after construction.
However, now, it is possible for the construction of the decoder to be interrupted, which would leave mDecoder null. For AVC1 content, if this happened, we wouldn't have in-band SPS/PPS necessary for CreateDecoderAndInit to complete.
So we use whichever extradata is available.
MozReview-Commit-ID: 702xj045LAv
--HG--
extra : rebase_source : e85077cedfece066398e36d8a4dd16f4bd406db6
This is a simpler approach required as both InitPromise and FlushPromise are exclusives.
It's in practice simpler too.
MozReview-Commit-ID: ItaAhC0Bk8T
--HG--
extra : rebase_source : 2c68b8843cfccd784bfcf1ae4fd08407ee891349
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
--HG--
extra : rebase_source : d18c3197ec2a08f2f184150e0c4a08da200a34b0
