We have removed unencrypted decoding via GMP, so we can remove its test.
MozReview-Commit-ID: 5VRbcbDFrhu
--HG--
extra : rebase_source : 33eb8fb084c48ecd2dcf28ba3caf5da37fa5de26
Add a puppeteer to manipulate twitch streams, particularly live streams. This
puppeteer overrides and extends upon video puppeteer to do this, and in
particular must handle streams that do not have a set length.
Two tests have been added to test that playback starts, and that playback
doesn't stall during a minute of playback. These tests currently don't
differentiate between advertising context and normal stream content, as both are
taken to represent successful playback. However, there is functionality to
detect advertisement playback using the data-screen attribute on the player HTML
element. Aside from it providing data useful in future tests, the data-screen
element code provides an example of interaction with twitch specific HTML
attributes.
The tests currently use the /food twitch channel, which is run by twitch and has
a ~24 hour uptime. Twitch have indicated they are working on a dedicated test
stream which these tests may use in future.
MozReview-Commit-ID: 6dNIm6noEqc
--HG--
extra : rebase_source : 6f3923e11ef62933b0d1263f58c7357e3b677c6f
1. requestLongerTimeout() is not needed because we don't have slow machines as B2G anymore.
2. Bug 634747 and 846769 are already fixed.
MozReview-Commit-ID: JbKtxHLdr8I
--HG--
extra : rebase_source : 7603c61637b8b142c8013bb8f431a49a93fac0c1
The media attribute in source element is no longer needed in media element case. Remove related test case.
MozReview-Commit-ID: 7ckvEAl6HL4
--HG--
extra : rebase_source : d5346029fb115a0445733c90d43af00fe4919aa8
We only care that we will enter suspended mode after a minimal time. On slow machines (like the linux try box) there are so many things at play that could delay a particular event.
So we remove the upper time test.
MozReview-Commit-ID: IAZVyuetYVp
--HG--
extra : rebase_source : 467d6a32dff88791d1238c0654d81b6d4afafc31
Case: invoke load() on an element should reject pending promises in order.
Expected result: the pending promises are rejected in order.
MozReview-Commit-ID: AJMX7uLTEN0
--HG--
extra : rebase_source : cd5e704f28db634d3700c9995097577a30a47549
extra : source : 9e41353b32c2c4674ac609b202efca8dabbbb1b5
Case: invoke load() on an element should resolve pending promises in order.
Expected result: the pending promises are resolved in order.
MozReview-Commit-ID: 1FSdBd3zwrB
--HG--
extra : rebase_source : fddd8742d80b68fced9ac9c09f8d918af4e6bba7
extra : source : 9c0a4abd7ff8ebffc1fc4369a335be299b8ba3dd
Case: step1: create an element with its paused member to be fause and networkState to be NETWORK_NO_SOURCE.
stpe2: invoke load() on the element and the load() rejects the pending promise.
Expected result: reject the pending promise.
MozReview-Commit-ID: 34Hj9Xyuq8H
--HG--
extra : rebase_source : a7d3c8710e2c01071750f0ea1d783f7f2c9588db
extra : source : d9ea68265f212eba8a4f1f8797eecddcb23ab07d
Case: step1: create an element with its paused member to be fause and networkState to be NETWORK_EMPTY.
stpe2: invoke load() on the element and the load() leaves the promise pending.
Expected result: the pending promise should finally be resolved.
MozReview-Commit-ID: CbUs1barMSP
--HG--
extra : rebase_source : c0626618d0bf50433dabb072d4221f5fbcfdbd35
extra : source : 7fa1839898a1042e83bd277d6bd819da7790e7ac
Case: re-invoke the load() on an element which had dispatched a task to resolve a promise.
Expected result: the already dispatched promise should still be resolved.
MozReview-Commit-ID: CGthPmPeaif
--HG--
extra : rebase_source : 3c377a62ecf6f84c382f49d856be8c07871c59b0
extra : source : cebac214f77710b911f56674ed92989aa1fa5957
Case:: invoke pause() and then play() on an element that is already playing.
Expected result: resolve the promise.
MozReview-Commit-ID: DaYzxTgEWwL
--HG--
extra : rebase_source : da599574a03a71d486168a2e11a36e2bc4e91237
extra : source : 46699200222d0884017176d6df429224e6b1b3ce
Case: change src of an element with pending promises.
Expected result: reject all the pending promises.
MozReview-Commit-ID: 6iPl5iLOgKX
--HG--
extra : rebase_source : 0e662da2fd0e4db2364af2083d606599a98c4c60
extra : source : f12056fd4bc303ece7ba8ea7a4c305a03877e9cb
Case: invoke load() on an element with pending promises.
Expected result: reject all the pending promises.
MozReview-Commit-ID: Kg5FHAmhF4L
--HG--
extra : rebase_source : db6dc8b32e4c67963694e295a3a7ae536bb0a912
extra : source : 2576d87906f71cf44f00bb7e447af2393587a4f6
Case: invlke play() and the pause() on an element that deoen't have enough data to play.
Expected result: reject the promise.
MozReview-Commit-ID: 8x5dFhhbTVJ
--HG--
extra : rebase_source : 281b16f0cfd208ee6caf06cbc5f6e8dceaa4303b
extra : source : 34b7647611521957a069735b839822c13ec81296
Case: invlke play() and the pause() on an element that already has enough data to play.
Expected result: resolve the promise.
MozReview-Commit-ID: BdbYHf7moyH
--HG--
extra : rebase_source : c0fa86c888c936f9a19622c74e135e5aafdbc754
extra : source : de021cfd2633cb7c0bc307ce67fe80b54010bd93
Case: invoke play() on an element which had its source changed (to a invalid source) after suffering from an error.
Expected result: reject the promise.
MozReview-Commit-ID: 3EDf0TpTwYb
--HG--
extra : rebase_source : 51077022d99bbb53c6eb401c4f9492cf62cc34bd
extra : source : 5d6a3ff4c554448e5f60700a876598c70273a952
Case: invoke play() on an element which had its source changed (to a valid source) after suffering from an error.
Expected result: resolve the promise.
MozReview-Commit-ID: 9ZxT7TRVR6v
--HG--
extra : rebase_source : 763203d44ce6322fc4123a980e97d90339ce0d49
extra : source : 747b49e8a4be3150383270cc01bb8c0e241f67b9
Case: invoke play() on an element with MEDIA_ERR_SRC_NOT_SUPPORTED has been set.
Expected result: reject the promise.
MozReview-Commit-ID: Bp4Ng6gKUa1
--HG--
extra : rebase_source : 8b9dc3480c021beef91922ef3d00f8f5465bb1dc
extra : source : b4a7b91df34da2fe8fe9eda5e3860f9dcd103733
Case: invoke play() on an element with an unsupported content.
Expected result: reject the promis.e
MozReview-Commit-ID: 1zZc0PhBmAD
--HG--
extra : rebase_source : ece4f5f385b6eb0900a5f32c73921f61dfb4fa06
extra : source : 85f306eeec51c4b3505d6f9a94c2c5380a916cd3
Case: invoke play() on an element that is already playing.
Expected result: resolve the promise.
MozReview-Commit-ID: 83IbJNF7Rzd
--HG--
extra : rebase_source : b94f474de5c85f79e4cd7661fd578a8e2580cd2c
extra : source : e95c39a6abe4e59e64270716669584eda6081cbb
Case: invoke play() on an element that has enough data
Expected result: resolve the promise
MozReview-Commit-ID: JAloJxN933Z
--HG--
extra : rebase_source : 26c85effe88faecaf95bef6254db2afeede76c30
extra : source : 0170fac6a144c1878a775366fe3e7cc59f09de61
Case: invoke play() on an element that doesn't have enough data
Expected result: resolve the promise
MozReview-Commit-ID: 7bUs8cy5Fkv
--HG--
extra : rebase_source : 02b18756f2c70f02ea4bb3c204b58cc6ede71a20
extra : source : dddcd63380f0f5c0cac5fe22e0af0ffcdef07a09
The test case itself does not really do what it claims.
Disable it now (for landing bug 1244768) and will rework it later.
MozReview-Commit-ID: H2sCX58eypr
--HG--
extra : rebase_source : 0a5165df23cd79e4a3605fa2c2dbfb27055468cf
'fmt ' and 'LIST' chunks could theoretically (but unlikely) have an odd length,
in which case the following chunk will start at the next even offset.
Added test case.
MozReview-Commit-ID: DkpBTaUqnf8
--HG--
extra : rebase_source : 0d8cfbc0d2d0da1f3317f901ef44c4fb67968dae
Test that a WAV file with 0xFFFFFFFF data chunk length does not overflow, by
playing it; If it did overflow, its duration would be 0, and therefore would
not play.
MozReview-Commit-ID: EiWLb5otSnh
--HG--
extra : rebase_source : 2a3fb908f69b7b2032dfbc9df88e5390c66133f0
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
This is follow up work to the VideoPuppeteer changes that have it take snapshots
to prevent racing. For this work the motivations are the same: prevent racing by
querying a stable snapshot of video state, rather than making sequential JS
requests to the browser between which video state may change.
Much of the YouTubePuppeteer has been made internal, so the class can
encapsulate its snapshotting. The property methods have been rolled into the
snapshotted data named tuple to make it clear they're derived from snapshotted
data.
A number of broken parts of the code have been removed or reworked:
- Disabling autoplay was not working and has been removed. This is partially
addressed by using embedded URLs (in another commit) -- embedded videos do not
play next video automatically. However, there may be merit in reinstating a
working version of this in future if possible - particularly for videos that
can't be embedded, which we have some of in our tests.
- Ad skipping was not working. The getOption('ad', 'displaystate') JS call
appears to always report an ad is not skippable even if it is. Code related to
skipping ads has been removed for now, and ads are waited out. This may also
be something worth revisiting if a working implementation is possible.
***
Review feedback: update YT puppeteer to use more concise calling conventions,
compatibility with changes to VideoPuppeteer.
MozReview-Commit-ID: CCxf9ItFYtl
--HG--
extra : rebase_source : 99aac08fd86d41e7fa3df9b00604dd583ca27bf8
The tests that use VideoPuppeteer often expect the state queried by the
puppeteer to be consistent if done closely in the code. However, this has not
been the case, as there can be significant lags in the data returning from
marionette. This means that if one line queries the current time of the
underlying video, and the very next line queries the same thing, there can be
significantly different results.
This causes issues with tests making multiple sequential checks on the
underlying video, and the state changing between checks. On test fails it means
that the information logged my be inconsistent with the state that resulted in
the test failing, as time passes between the fail check and the logging.
This patch attempts to address this by having the VideoPuppeteer store a
snapshot of state and examining that instead. This snap shot should be
internally consistent.
I've removed a large number of public members from the class, and moved a couple
of the testing functions into the class. The thinking here is that the new logic
complicates the internal state of the class, and I want to keep the interface
slim to hide that complexity.
***
Review feedback: Log interval, expected duration, stall wait time, and timeout
times in VideoPuppeteer string.
***
Review feedback: make video var script a class var instead of a staticmethod.
***
Review feedback: move _fetch_state_script to be a property on VideoPuppeteer.
***
Review feedback: simplify calling of _create_video_state_info with a dict.
Fix played docstring.
***
Review feedback: simplify _create_video_state_info using kwargs.
MozReview-Commit-ID: 6mN56bFMge0
--HG--
extra : rebase_source : a25a9a45c8dced9439360b9664b1d768100ed2be
Previous changes that I'd made broke the reporting of the baseURI on videos.
This changeset aims to fix those breakages, and also puts the baseURI on the
state snapshot.
MozReview-Commit-ID: 8YgPpHzoX1E
--HG--
extra : rebase_source : 28840d1e47e9f2909eb67bc376a3a85874427149
This API has been deployed to release for some time. There isi
no longer value to being able to quickly disable it.
MozReview-Commit-ID: Jj6CyWzP93g
--HG--
extra : rebase_source : 2dc0547229b53865a4f7cfcf7ca417eb3dec0356
The tests expected that the error code would be MEDIA_ERR_DECODE whenever we fail to open a video. However, MEDIA_ERR_DECODE is to be used only when "An error of some description occurred while decoding the media resource, after the resource was established to be usable."
All those files have errors in their metadata. Which makes the resource unusable to start with.
Similarly, networkState would be set to NETWORK_NO_SOURCE if the metadata couldn't be read.
MozReview-Commit-ID: KXVJmD3ZQlT
--HG--
extra : rebase_source : 1ec3d7e764d832702e662f0b650363498e0b0761
The tests expected that the error code would be MEDIA_ERR_DECODE whenever we fail to open a video. However, MEDIA_ERR_DECODE is to be used only when "An error of some description occurred while decoding the media resource, after the resource was established to be usable."
All those files have errors in their metadata. Which makes the resource unusable to start with.
Similarly, networkState would be set to NETWORK_NO_SOURCE if the metadata couldn't be read.
MozReview-Commit-ID: KXVJmD3ZQlT
--HG--
extra : rebase_source : 0aa759ceff22f0c30e650593190a4d0e85292a07
We've had large numbers of shutdown hangs with the Windows H.264 decoder stuck
calling IMFTransform::ProcessOutput(), blocking shutdown. I can reproduce this
with videos with dimensions less than 32 pixels.
Chrome also encountered this with the WMF decoder:
https://bugs.chromium.org/p/chromium/issues/detail?id=373288
The WMF H.264 Decoder is documented to have a minimum resolution of 48x48 pixels.
So this patch causes us to reject H.264 files with either width or height less
than 48 pixels.
I have been able to play files down to 34x34 pixels on Windows 10, but it seems
safest to just follow the what's documented in MSDN, and reject files that are
smaller than the documented minimum.
MozReview-Commit-ID: 5peP6UGnAaB
--HG--
extra : rebase_source : 6e29812642bc3f8ca0f5b39b36064a6d50e09ea7
- Use format() instead of old style formatting (%s, etc).
- Remove unneeded positional args on format strings.
- Break some long lines for pep8 conformance.
- Use brackets instead of \ to continue long lines.
- Log interval on video puppeteer.
- Remove an unneeded media source check. We have explicit media source checks
in tests, and the media source prefix has changed, rendering the check broken.
MozReview-Commit-ID: 4FPVoOD0P5B
--HG--
extra : rebase_source : 3bfdc4a5aee5c419e4ccacc923ec539cbaa1d14f
The VideoPuppeteer now uses played ranges where possible to calculate the
remaining time. It will also use the played ranges to determine the expected
duration where possible. This is more accurate than using the time when the
tests first poll the video. The first poll time was previously self._start_time,
but I've renamed this to self._first_seen_time, to reduce ambiguity -- the video
may have started playing before this time.
The playback_done function has had it's remaining time check relaxed. Previously
it was possible to skip over the window where a video would be considered
complete, that window is now expanded so that if the start threshold is passed
the video is considered played.
A concrete example: the tests could play a 90 second video, but the duration of
the test is set to 60 so only part of the video need be played back before the
test completes. If a 1 second interval was used in the tests there would be a
window between 59 to 61 seconds during which if the video were polled it would
be considered complete. However, due to latency polling may not take place in
this window, leading to racy fails. Now the tests will consider any point beyond
59 seconds to be complete.
MozReview-Commit-ID: J6DpqCbZxUg
--HG--
extra : rebase_source : 7990e4eee0bce30718b875f652c7148110cd4c3f
This is a quality of life change. Since VideoPuppeteer uses, and since I plan on
using the played ranges of a video element more, it is useful to output them as
part of the str representation.
MozReview-Commit-ID: LwVPfVtFF1v
--HG--
extra : rebase_source : 1ebe4b7a7176a15f7e9300dee84103a8f6b86708
Many of the youtube URLs were not being used in tests. Many were are/also dead.
Furthermore, non-embedded links are causing issues due to the next video auto
play feature defaulting to on in youtube.
This is a quick once over to remove unused links, prune some of the dead, and
rewrite those that can be embedded to embedded URLs. In future I would like to
see the embedded links and non embedded separated into their own files. However,
theses changes are a halfway house that will not break compatibility downstream.
MozReview-Commit-ID: 4aPMNjD3LC4
--HG--
rename : dom/media/test/external/external_media_tests/urls/youtube/long3-crashes-720.ini => dom/media/test/external/external_media_tests/urls/youtube/long2-crashes-720.ini
rename : dom/media/test/external/external_media_tests/urls/youtube/long4-crashes-900.ini => dom/media/test/external/external_media_tests/urls/youtube/long3-crashes-900.ini
rename : dom/media/test/external/external_media_tests/urls/youtube/short0-10.ini => dom/media/test/external/external_media_tests/urls/youtube/short1-10.ini
rename : dom/media/test/external/external_media_tests/urls/youtube/short3-crashes-15.ini => dom/media/test/external/external_media_tests/urls/youtube/short2-crashes-15.ini
extra : rebase_source : a5abcc8d7b1f1f1e3e2b6303f91b6183f4e4d9ee
Rework the Youtube puppeteer to look up player and video element based on class
names, instead of ID. This means that the tests can work with embedded players.
This has the benefit that we can use youtube embedded links
(youtube.com/embedded/<videoId>), which do not suffer from auto play related
issues (auto play jumping to another video).
MozReview-Commit-ID: 9UFyL7di6gH
--HG--
extra : rebase_source : 69301bfa2b7ea9fd729742ae670ecb6e8209c4f9
Change test files to specify the mime type of the file. This is checked
by media test manager so that changes in mochitest.ini are not needed.
MozReview-Commit-ID: 4hFQmRknBOY
--HG--
extra : rebase_source : b76a8dfe071dec320a7ebef8fc071e671278c1fa
Kartikaya Gupta
Jay Harris
Cameron McCormack
Florian Quèze
Carsten "Tomcat" Book
Andreas Pehrson
Chris Pearce
JW Wang
Bryce Van Dyk
Phil Ringnalda
Sebastian Hengst
Chris Peterson
ctai
Jean-Yves Avenard
Henrik Skupin
Kaku Kuo
bechen
Andrea Marchesini
Gerald Squelart
Paul Adenot
Ehsan Akhgari
Jesse Ruderman
Iris Hsiao
Kilik Kuo
Ralph Giles
Dan Glastonbury
Wes Kocher
clui