- Fix bogus assertion failure in tests on Safari (#6272)
- This test should not be seeking so close to the duration (10ms) as to
cause flakiness on certain browsers. Adjusting the seek time fixes the
assertion without compromising the purpose of the test.
- Fix uncaught rejections in load graph tests (#6274)
- These tests had calls that were interrupted by the teardown process
that occurs after the test body. Waiting for the operations before
ending the test fixes the issue.
- Fix interrupted load in test on Tizen (#6274)
- This test triggers a deliberate DRM error without waiting for load().
On most platforms in the lab, the load() operation completed before the
error. Not so on Tizen. This exposed a general problem in which we
should be catching errors in this test. Only timing saved us on most
platforms.
Closes#6272Closes#6274
The state engine mechanism, designed for the player class, was
over-engineered. The structure of the class makes debugging player
errors unnecessarily annoying, by obfuscating the code-path the error
followed, and in general
has created a significant amount of technical debt.
This changes the player to use an async-await setup for the top-level
operations, laying things out much more cleanly
and linearly.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
Power-saving features on Chrome and Edge were subtly interfering with
playback tests. Timers could be throttled, and both video-only media and
media in occluded windows could be paused by the browser.
This was discovered only after awaiting play() Promises in all tests.
These Promises were being rejected with useful error messages that led
to these discoveries.
Awaiting play() requires us to disable stall detection during playback
tests. This is because on some platforms, stalls get resolved by calling
pause() and then play(), which would cause the original awaited play()
Promise to be rejected.
Finally, some Player tests created additional Player instances that were
unnecessary. Removing those allowed me to centralize most of the
configuration to disable stall detection.
The test to show that src= playbacks can log width/height data was
failing on Tizen. This is because Tizen was ignoring the SAR (sample
aspect ratio) and showing the content at 256 pixels wide, whereas
other platforms were displaying at 258 pixels wide. The point of the
test was never to check a platform's support for SAR, so the video has
been re-encoded to display consistently across platforms.
This issue began when the test was added in PR #4435.
The video file is now also much smaller than it was before (from 177kB
to 37kB).
Re-encoding was done with:
```sh
ffmpeg \
-i test/test/assets/small.mp4.orig \
-c:v h264 -vf setsar=1:1 -crf 51 \
-c:a aac -b:a 16k \
-y test/test/assets/small.mp4
```
addChaptersTrack() was already an async method, but it did not wait
for the chapter data to be loaded by the browser. The solution is to
wait for the `load` event on the `<track>` element we create.
To accomplish this, some cleanup and refactoring was done in how
tracks are managed. Summary of changes:
- The `addtrack` event, which triggered management of tracks in src=
playback, is now used for all types of playback. In src= mode, it
manages all tracks, and in MSE mode, it only manages chapters
tracks (which are added to the video element as in src= mode).
- `processChaptersTrack_()` has been renamed to
`activateChaptersTrack_()`, since its only job is to set the
track's mode field to make the browser load it.
- `activateChaptersTrack_()` is now only ever called via the
`addtrack` event.
- `activateChaptersTrack_()` no longer loops over all chapter tracks
on a timer, and instead only touches the single track it was
called for.
- `addSrcTrackElement_()` now returns the HTML `<track>` element it
creates.
- `addChaptersTrack()` now awaits a `load` or `error` event to
complete (or fail) the operation.
- Existing tests for addChaptersTrack had long delays to work around
this issue; these delays have simply been removed.
Fixes#4186
This change fixes tests on Chromecast by loading tests later in the process. Test scripts are now dynamically inserted by boot.js, rather than loaded by Karma. The bootstrapping code then awaits the completion of that before starting the Karma frameworks (Jasmine) to run the tests.
This also removes the use of goog.provide/goog.require in tests and test utils. We don't need to load test utils or library sources dynamically in each test, and this gives us more explicit control over script loading and ordering.
Closes#4094
This new method can make a HEAD request to the server to determine the MIME type. The old method (addTextTrack) is now deprecated and will be removed in v4.
Refactor the test util and relevant files for compiler upgrade.
In test files, a few files depending on each other formed a
dependency loop.
For example, test/Util has a few methods for waiting/delay that
uses Waiter, and those methods should be in Waiter.
This changes helps to break the dependency loop, and helps to
unblock the compiler upgrade.
Change-Id: Ie5ece145748bf2eafe3fa065b79cf2a81b1637e1
This corrects/normalizes license headers in misc. files, such as
config files, docs, build tools, tests, and externs. This does not
affect the compiled output, and is only done for consistency.
Issue #2638
Change-Id: I9d8da2de55243b08d7df2b743aac73c6f15e858a
One of the src= playback tests was failing on Chromecast with an
estimated rate of about 20% when the src= tests are run alone. The
timeout for playback to start was found to be too short on that
resource-limited embedded device. This increases the playback timeout
in the test.
Fixes: 157702575
Change-Id: Ib8d5a0d961bc0e99e77c16b93ca63569f3a2cc31
Changes to the load() promise resolution on iOS for #2483 accidentally
broke language preferences in src= mode, and the regression test for
this revealed subtleties in how and when tracks may be selected with
Apple's native HLS.
By waiting for a "change" event on video.textTracks, we can make sure
Apple is ready to accept our own text track selection.
This should now work correctly on all platforms.
Closes#2593
Change-Id: Iec59b89001fbec3779a0f7087ce11efe1be003ef
These issues were mostly introduced in "Don't preload data on iOS",
and were not detectable in Chrome. They came up during a full test
pass in our test lab on all browsers.
Change-Id: Ife6e157a18df84ea30b840615f6d06a22e340a44
Instead of calling video.load() and waiting for loadeddata for src=,
wait for loadedmetadata. This should be a safe event to use in most
cases, and calling video.load() causes native HLS to start preloading
an uncontrollable amount of content.
The exception is if the app sets preload='none' on the video element.
If this happens, we will detect it, log a warning, and avoid the
loadedmetadata event which may never fire. This is not a scenario we
will officially support, but at least we can prevent a hang in
player.load().
Closes#2483
Change-Id: Id64c8f23cb8fa82bb5c301abafb51f2d9d8730f7
When SimpleTextDisplayer is constructed, a TextTrack is created,
and that cannot be removed. This introduces an extra TextTrack when the
content is played in src= mode.
This is the straight-forward solution to filter the extra TextTrack out
by the label in src= mode.
Issue #2516
Change-Id: I8c417f837e4ad2f90ec779b533c8484de9e22b11
We used to alias static utility methods by assigning the method itself
to a local variable. This is not allowed by the new Closure Compiler
release that we are adopting, and for good reason.
The old compiler did not understand the use of "this" in static
methods, but the new one does. And it turns out that when we start
using "this" in static methods (see #2532), aliasing the method itself
can break everything.
When you refer to "this" in a static method, it refers to the class.
This is really useful in utility classes that have private static
methods they use to perform common tasks. However, just as it ruins
the value of "this" to alias an instance method, the same is true of
an ES6 class's static method.
The fix is to always alias the class instead of the method. The new
compiler will simply not let us get away with the old way any more, so
regressions after this are unlikely.
Issue #2528 (compiler upgrade)
Issue #2532 (static "this")
Change-Id: Id800d466e639c7cbcf4aa6fbb05114c772a2229f
This partially reverts commit ad3d4604, because that fix seems to have
caused #2523.
This also adds a regression test for #2523.
Reopens#2516Closes#2523
Change-Id: If3ed5942fff029f522e24048edcb4a04e7cc30e9
When the non-UI TextDisplayer is constructed, it creates an extra
TextTrack that can never be removed. This leads to a bogus text track
showing up in the UI when content is played in src= mode.
This changes the TextDisplayer to disable the extra TextTrack (since
there is no API to remove it) and changes the Player to ignore
disabled TextTracks when generating a track list for src= playbacks.
Closes#2516
Change-Id: I2e651f737445049da5fa46a798a2bc0751de2822
For some reason, on Edge and IE, starting this particular piece of
content at time 5 results in playback beginning at 4.9. It could be
that the number is rounded to a keyframe or something.
This changes the test to expect the start time to be within 200ms of
the requested start time.
Change-Id: I5399a1eaf8a84b57a88359db2584f043e4a11e81
This removes periods from the internal manifest structure and cleans
up code and tests accordingly. This leaves us unable to play
multi-period DASH & offline streams until the main period-flattening
algorithm is completed in shaka.util.Periods.
Three test cases have been disabled for the moment.
Multi-period playback will be restored in a smaller, more focused
follow-up commit, with disabled tests re-enabled.
Issue #1339 (flatten periods)
Issue #1698 (rapid period transitions issue)
Issue #856 (audio change causes bitrate change)
Closes#892 (refactor StreamingEngine)
Change-Id: I0cbf3b56bfdb51add15229df323b902f0b2e643a
The Player ratechange event is a filtered version of the video
ratechange event. This is necessary because we manipulate
playbackRate as part of our buffering state management.
The UI uses this Player ratechange event to drive the playback rate UI
menu, but the event was not firing for src= playbacks (native HLS or
plain MP4s).
This fixes the ratechange event for src= playbacks, and also fixes a
small mistake in the MediaSource setup that could have resulted in the
ratechange event being triggered before playRateController_ was
created.
Closes#2488
Change-Id: If85e489d681cfbb1ae6141b490d82264e1d932bd
This changes the eslint rule to enforce a strict pattern for the
argument comments. The comment must appear before the argument and
must be /* foo= */. This still ignores line comments.
Change-Id: I3afb01c65e1088eda13facb3aeeaa7595a2f5aee
This method should probably never have been in the library, since it
creates a fixed-sized, muted element.
Change-Id: I53b474305465bef34d43ce40ec5e7dedceb20a25
This reflects changes in Google's policy on JavaScript license
headers, which should be smaller to avoid increasing the size of the
binary unnecessarily.
This also updates the company name from "Google, Inc" to "Google LLC".
Change-Id: I3f8b9ed3700b6351f43173d50c94d35c333e82b4
This also removes the unused SimpleIDB type and removes the duplicate
code in Utils that appears in Waiter.
Issue #1157
Change-Id: Ib3cfc16212b9d169b360825a25a084c5ebd7b80f
This reorders the rules so they mostly are ordered the same as the
eslint documentation. The exception is the few at the top, most of
which should be removed. This also removes some rules that appear in
the recommended or the Google set. Lastly this adds some more rules:
- Require parenthesis when using "new".
- Disallow confusing regex (e.g. /=/).
- Disallow some confusing coercions (e.g. +foo).
- Disallow some Unicode characters in a regex.
- Disallow using "async" in a Promise constructor.
Change-Id: I597b472bdaee5b4cb92354f057e7ae6aeb96eefa
The test expecatations were not flexible enough to cover differences
in browser implementations.
Issue #816
Issue #997
Change-Id: I918c4d08f5b195046834ee534e84f4b8787487d5
I recently introduced two uses of the 'canplaythrough' event, but it
was pointed out to me that this implies that content is buffered
enough to avoid ever buffering again until the end. Instead, we
should simply be using the 'canplay' event, which only implies that we
could start playback.
Change-Id: I3176f8c943ea7bf3f39967a616d9deffd5a4e791
Track methods are now implemented for native HLS and other src=
playbacks. This will allow the UI to select text and audio languages.
This change adds best-effort methods to get track information for src=
playbacks, including native HLS on Safari. In many cases, it relies
on the audioTracks and videoTracks members of HTMLVideoElement which
are only implemented on Safari. They are in the spec, though, so
there's no harm in using them when they exist.
This is fully parallel to the manifest-based paradigm for MSE-based
playbacks. Each of these top-level methods in Player has an "if" to
decide which way to supply the requested info, except for the language
methods, which now delegate to the track methods.
With this, Safari's native HLS can supply audio and text language
information to the UI/app, and the UI/app can have some control over
those things through the tracks API. I believe this is important to
the success of our new iOS support.
Issue #997
Issue #382
Change-Id: Icc44a932927fafedda1b62a9d4c6e2ed3dc7db30
This test was only passing by winning a race before. Now, it waits on
the appropriate event before testing seekRange.
Fixes b/131604508
Change-Id: I1301719bbccb12895a3402af565bbcf00e88553a
Allow indirect access to members (such as DRM engine, manifest, etc)
from Player methods as soon as they become available, instead of
waiting until the very end of the load process.
This fixes application access to several methods during the
"manifestparsed" event. The point of the "manifestparsed" event was
to allow early access to manifest and other metadata before streaming
begins.
This also lays the foundations for improvements in native HLS support
in those same methods, including the ability to get track information.
Issue #382
Issue #997
Fixes b/131604508
Change-Id: Ifee7b06fc2ccdcf5bcdf1c44f2f851d1d7e67fa1
There is a workaround for a Tizen bug which appears in many of our
test suites. To avoid having to add this to yet more, this change
factors out the workaround such that it applies to all tests.
Change-Id: Ie34c81bfcac94310bf3cd021fd4f2d55905b647a
The integration tests for src= failed almost universally on Tizen, but
a few failed on other platforms, as well. The issue was the fixed
delays in those tests. This replaces those fixed delays with an
event-based utility that solved the same problem in other Player
integration tests.
Issue #816
Issue #997
Change-Id: Ib43cbb139ef77be1219e60d1fd5009aa403cc4cb
Define an initial set of tests to ensure that the public player api
behaves correctly when the player has loaded content with src=.
Issue #816
Issue #997
Change-Id: Ie40bc926d1e56d37318f0ba7711903cdf8e6aa3e
Álvaro Velad Galván
Joey Parrish
theodab
Álvaro Velad Galván
michellezhuo
Joey Parrish
Jacob Trimble
Aaron Vaage