MockAdManager did not define setVolume() in this one test, causing the
test to throw an exception. This exception got swallowed and did not
fail the test, but was noticed in the JS console during a Karma debug
run.
Some assets might rely on networking engine filters (request and
response filters) to properly download their assets. However, the
preload manager's need to use a fresh networking engine also caused it
to not use any filters set on the player already. This changes the
process of setting up a preload manager, to make it copy over any
filters defined on the player's networking engine.
Fixes#6698
We've tried to enable setting server certificates to optimize playback
start, but turned out that with our widevine certificate shaka was
throwing 6004 error. The issue is not reproducible starting from Tizen
5.5. The same certificate was working properly also on Chrome.
On PlayStation, cached `MediaKeySystemAccess` objects may corrupt after
several playbacks, and they are not able anymore to properly create
`MediaKeys` objects. To prevent it, clear the cache after each playback.
Make it configurable via `streaming.clearDecodingCache`.
Chromecast WebDriver Server and Karma both used iframes, which caused
complications when testing on Chromecast. The test environment couldn't
directly access `cast.__platform__` APIs, and more recently stopped
being able to access EME due to presumed mistakes in the platform's
implementation of iframe permission policies.
This resolves the issue by removing iframes at both levels.
- Flatten Karma's environment using "useIframe: false" and "runInParent: true"
- Remove test flag --single-run; not supported in combination with Karma's "useIframe: false" option
- Add a test boot file to force closure to use dynamic script tags instead of document.write; required with Karma's "useIframe: false" option
- Adjust screenshot tests not to assume an iframe host
- Fix compatibilty between Tizen and Karma's useIframe:false
- https://github.com/joeyparrish/karma/commit/32e87357a0ca4bf5d3de6d78d80dae2d065fd407
- https://github.com/joeyparrish/karma/commit/f2132cc2cf72f9408fbce2a20b5a21999f1e9416
Karma creates a dump() function on the context window that we can use to
log something to the console without respect for the normal
captureConsole setting. Use this for the output of probeSupport(), so we
always have it in CI logs.
When running tests with logging enabled, the logs will now always
contain a full map of media features supported on this platform.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
These changes are necessary for compatibility with Chromecast WebDriver Server v2.
- Fix a bug in Karma's flat environment support (joeyparrish/karma@9875e98)
- Add a test boot file to load CAF on Chromecast devices; required by Chromecast WebDriver Server v2's redirect mode (flat environment at that level)
- Also load this cast-boot file in support.html
- Rename/reorganize Cast-related externs, which were messy even before the addition of CAF
- Remove proxy-cast-platform.js; no longer needed as we move to flatten the test environment
- Ignore error events with "null" error; these appear on Linux Chromecasts, only since including CAF
- Ignore error events that are actually strings; these appear on Linux Chromecasts, only since including CAF
- Disable Fuchsia in the lab until autoplay issues can be resolved
A partner bug we are investigating involves content not being played at
4K when it could be. This test (which passes) helped us eliminate a
theory that our period-flattener was the cause.
The Axinom v6 test vectors we used were failing to decode on ChromecastHub. This upgrades those test segments to Axinom's latest test vectors (v10).
Box offsets and content keys have been updated accordingly.
This also adds the additional error logging that helped to identify the decoding failure.
In some rare cases, particularly on Fuchsia-based Chromecasts at the moment, I am seeing test failures where the test is waiting for a time that has already passed. It appears that the `timeupdate` events may be missed in some cases. The `currentTime` appears to be less than the target at the last `timeupdate` event, then the time progresses internally, then a buffering state is hit and no new `timeupdate` events fire. So the Waiter class should use a timer for this as it does for many other types of waits.
In some cases, Fuchsia Chromecast tests will fail with the error: "The
play() request was interrupted because video-only background media was
paused to save power."
This resolves the issue by ensuring tests run un-muted on that platform,
based on this Chrome code, which indicates the "paused to save power"
logic does not activate when sound is playing:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/media/web_media_player_impl.cc;l=3535;drc=d23075f3
This also fixes two places in our tests where the `createVideoElement()`
was bypassed. This should always be used, because it is a central place
to apply workarounds such as this.
The offline DRM tests have begun failing on Android at a rate of 80% or
more. This was eventually determined to be related to
https://crbug.com/1108158 and the timeout workaround in DrmEngine.
When close() hangs and we time out and move on, we leave sessions open
that consume hardware resources at the OEMCrypto level in Android. This
eventually leads to failures like `Failed to execute 'createMediaKeys'
on 'MediaKeySystemAccess': MediaDrmBridge creation failed`. Logs from
`adb logcat` show that 17 sessions are open when this fails, which
likely means our lab device has a limit of 16 open sessions.
Initially, delays between these offline DRM test cases were found to be
an effective workaround, but full test runs showed this to be
ineffective after all.
The only recourse, until Chrome and Widevine fix their bug, is to skip
these tests on Android.
This makes it easier to debug hardware resolution issues through the
support page, which can now show hardware resolution. To show the
support page on Chromecast devices, use chromecast-webdriver-cli.
This shim requires the latest version of the Chromecast WebDriver Server's receiver app, which can receive messages and proxy async access to `cast.__platform__`.