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
Bug 1154802 provided a workaround for this race condition. So enable it in all platform.
MozReview-Commit-ID: BS1iW4O7TsZ
--HG--
extra : rebase_source : ac825a25b195b22106ae70cb412a0b61bd846bfb
Fix permafail for mda on WinXP which has no h264
MozReview-Commit-ID: 35tlO5vPTLD
--HG--
extra : rebase_source : 4d0edc219f75bd2107a3828a4df6419d7449657a
Test:
- That video decode suspends when enabled and delay is reached.
- That video decode doesn't suspend when disabled.
- That video decode doesn't suspend when video finishes before suspend delay.
These tests need to run from content process to observe the suspend
notifications via nsIObserverService, but access to gBrowser is in
chrome process in e10s. Thus, the reason for loading
background_video_chrome.js into chrome process and invoking functions
via async messages.
MozReview-Commit-ID: 2eE97FEUMPu
--HG--
extra : rebase_source : e48cc4dab54648bf0830f59f346a09ab3fb73f6e
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
Bump deps. Previous deps resulting in failures with current builds.
MozReview-Commit-ID: BUEfDmmE00E
--HG--
extra : rebase_source : a5437a86a875531945c558fab9427c6c31059289
The spec requires the MediaKeyStatusMap.get(keyId) function to return an 'any'
type, which is undefined for known keys, or a MediaKeyStatus enum value for
known keys.
https://w3c.github.io/encrypted-media/#idl-def-mediakeystatusmap
MozReview-Commit-ID: 3TOFYLacZSc
--HG--
extra : rebase_source : cd067f545cdbd9352ba64fea914128201b458d9c
There are various differences between the new ogg player and the old OggReader that leads to inconsistencies on how durations are reported.
1- The old OggReader only use the end time as duration of the video, ignoring the start time of the first sample. This leads to incorrect duration calculation.
2- The OggReader do not ignore undecodable frames located at the beginning of the video, and those are used by the MDSM to calculate the start time. This leads to durations sometimes being shorter than they ought to.
MozReview-Commit-ID: 6yi1P4N6tPE
--HG--
extra : rebase_source : 93e678aa762519d27444a57f8a12d2bd569b025d
This exercises the decoder update logic path that doesn't rely on
AudioSink to advance time.
MozReview-Commit-ID: EZ6lb8zsqTu
--HG--
extra : rebase_source : 36f8b33b1aaaba40ca378a4da4d9dfda311c571c
Given the implementation of BaseMarionetteArguments.parse_known_args,
remove call to parser.parse_args in Marionette mach commands
(marionette-test, session-test,
firefox-ui-update, firefox-ui-functional,
external-media-tests).
Instead, create an argparse.Namespace from the already-parsed
arguments, and pass this to parser.verify_usage.
MozReview-Commit-ID: 20agrkhwlLF
--HG--
extra : rebase_source : 32b0df89c1fbc52af57884d6ba764502b64ac590
Make the EME mixin also reset the widevine GMP. This gives us some
widevine downloader coverage, as well as meaning that EME tests that
rely on widevine should work.
MozReview-Commit-ID: AyeeLu2lJRK
--HG--
extra : transplant_source : %13ck%EA%AD%8F%B8.%E5%A0%EC%2C%B4%40h%E0s%0C%1D%B4
Chris Pearce
Kilik Kuo
Bryce Van Dyk
Ralph Giles
Jean-Yves Avenard
Phil Ringnalda
Carsten "Tomcat" Book
bechen
ctai
Dan Glastonbury
Wes Kocher
clui
Sebastian Hengst
Henrik Skupin
Eugen Sawin
Jan-Ivar Bruaroey
Andrew McCreight
Alastor Wu
Anjana Vakil
Kaku Kuo