This removes the ability for ClearKey to instantiate persistent-license
sessions using the EME APIs.
MozReview-Commit-ID: FXj5YORxpas
--HG--
extra : source : b69b2435f1059a5c7b1dd26947ea500b381ec7f0
The specification doesn't require there to be a 'type' member of
the keyids init data format.
MozReview-Commit-ID: 7mOm7KwyyuC
--HG--
extra : source : c9fb674f3cb8dff4fe8734e0426e67825878015d
Can not play mp4 on XP. So add the canPlayType checking for the test failure.
MozReview-Commit-ID: KH70XsQkYYF
--HG--
extra : rebase_source : fc08ea1aad6094757dcc7f72662d0d214b4bdeb7
totalVideoFrameCount was previously incorrectly set to the number of demuxed
frames.
According to the current W3C specs [1], it should instead be the total number of
frames that have been presented, plus frames that have been discarded.
Also added a check that discarded<=total in mochitest.
[1] https://wicg.github.io/media-playback-quality/#concepts
MozReview-Commit-ID: Gnv1roM5n0A
--HG--
extra : rebase_source : 1f018612fbaf43867f5c92e59d62d718a3b08535
This removes the ability for ClearKey to instantiate persistent-license
sessions using the EME APIs.
MozReview-Commit-ID: KXyuRNMJKIZ
--HG--
extra : rebase_source : fd5c66f8929dfdb28ceb5cb82a75181a9168ca81
Media element capture pushes data to MSG ahead of currentTime which together
with the direct listeners that we use in MediaRecorder we end up finishing
the recording in less than the 250ms that this test uses as the recording
timeslice.
Lowering the timeslice here seems to fix this. I'm using 1 here since it's the
minimum valid number.
MozReview-Commit-ID: KAlRoHWHPSV
--HG--
extra : rebase_source : cc2af7829dca734b0411383a6b92dd0691533411
Starting capture after tracks are known ensures that we can start getting data
immediately as we play() the element. Before there was a risk of missing some
initial data, which caused this intermittent.
MozReview-Commit-ID: FxaiiVtKaKD
--HG--
extra : rebase_source : 15eac09da8757fba81d52c66c22a4439ee956e84
Bug 1307016 attempted to address issues with output not being ascii and thus
being incompatible with terminals on test machines. However my changes in that
bug introduced two issues:
- They introduced a bug where field names were being read from an incorrect
source.
- They attempted to construct a string internally then converted that string to
ascii replacing non-ascii chars. This is an issue as in python 2 strings are
implicitly ascii, so the initial conversion to a string would fail if the
underlying object couldn't be represented as ascii.
Both of these issues are addressed here. The first by fixing the bad source in
the code, the second by converting to unicode for the intermediate
representation.
MozReview-Commit-ID: HC6Fd9TLRe2
--HG--
extra : rebase_source : bb7493b9074baa0273fb4110465f8bd13477f1d6
At least some of the environments the tests are running in do not appear to play
nice with non-ascii characters. Some of the jenkins runs are currently unhappy
due to this. This patch sees that all fields are encoded as ascii with
non-compatible characters replaced.
MozReview-Commit-ID: 6qSCyUujMLE
--HG--
extra : rebase_source : bb19b261b10aeb9bb9a47a2d47fefc7604000430
Tests that a fragmented MP4 file without a PSSH, but with encrypted valid
tracks with valid TENC boxes, is able to load with EME. This is a test for
the code path added in bug 1300069.
We setup MSE before starting up EME, so that we exercise the "waiting for
cdm" step in the MediaDecoderStateMachine, which was regressed in bug 1300069.
MozReview-Commit-ID: BXgdzAikWoH
--HG--
extra : rebase_source : b03910c96c8f61622ce7bc9fb7b53adc209526a4
Update VideoPuppeteer and make small changes in YoutubePuppeteer to support
retrieval of buffered ranges for wrapped video element. This will help diagnose
test failures, particularly stalls we're having at the moment. Because the
namedtuple storing state has all its fields logged the __str__ methods of the
puppeteers don't need to be updated, the new field will be logged automatically.
MozReview-Commit-ID: LYwXJfB71RE
--HG--
extra : rebase_source : 5d9100e33b030a56330ccaf7459b6e9206142907
The played ranges being retrieved in VideoPuppeteer and YoutubePuppeteer were
often referenced as some variation of 'time ranges'. This patch makes that more
specific and references the played ranges as variations of 'played ranges'. This
removes ambiguity if other time ranges are retrieved in future, such as the
buffered ranges.
MozReview-Commit-ID: CInjDCCIQkV
--HG--
extra : rebase_source : cdf5572b830ecc11b9319e23400746755fa8149c
We want to resume video-decoding as soon as possible so playback is less likely to reach the end before finishing all tests.
MozReview-Commit-ID: 4NrbejT8LgI
--HG--
extra : rebase_source : 5c3151a212a1a797cd3d71cfae5510e494af1041
When a test case times out, it will dump debugging info for each media element in the tree.
We would like to remove the ones that pass the test to avoid noise.
MozReview-Commit-ID: HgyvUfpyCqA
--HG--
extra : rebase_source : 4a1187db14c13bdd976179ba3d2b25123c9acb78