This doesn't produce any output right now, but this allow to the forks
to create custom configurations for ads, and also allow future
configurations to be added.
This adds an optional parameter to request and response filters, of a
new enum called AdvancedRequestType.
This enum describes request types that are subtypes of the basic types.
For example, INIT_SEGMENT is a type of SEGMENT.
This gives users more information about the type of the request, while
maintaining backwards compatibility.
Closes#4966
Bad linebreaks will now cause cues to be skipped (with a warning),
rather than throwing an error.
Closes#2358
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
Adds color support for SimpleTextDisplayer and WebVttGenerator (only one
place to fix both now thanks to #4941).
It's limited to the [8 colors
classes](https://w3c.github.io/webvtt/#default-text-color) supported by
the WebVTT specification, and also works with their 3 or 6-digit hex
variants (if the stream has TTML subtitles).
It does not support rgb, rgba or any colors other than these 8.
Fixes#4545
---------
Co-authored-by: Alvaro Velad Galvan <ladvan91@hotmail.com>
When the VTT size setting is used, the horizontal positioning was wrong
in both native and UI display.
The native display is wrong on Chrome and Edge because of a layout bug
in Chrome, where the shadow DOM for the cue box has conflicting
(redundant) styles. For example, these VTT settings:
`line: 85% position: 50% size: 63%`
result in these styles in the shadow DOM:
`top: 85%; left: 18.5%; transform: translate(-18.5%, -85%)`.
The `translate` style is what breaks the positioning. Unfortunately,
there is no way to fix that in JavaScript.
The UI display, however, was buggy for different reasons and is fixable.
The styles `left: 0; top: 0;` were applied by default, and then `top:
85%;` and `width: 63%;` were set based on the cue settings. The default
of `left: 0` was what broke the positioning. Removing this leaves `left`
set implicitly to `auto`, which is correct.
No other test cases were broken (or fixed) by this change.
This also adds a filter parameter to the lab workflow to run a subset of
tests for quicker results. This is useful for updating screenshots.
Closes b/259121343
This adds extra context to 3015 (MEDIA_SOURCE_OPERATION_THREW) errors, by attaching
the error on the media element. This is helpful because, in some situations, media source operations
can have very unhelpful exception strings like:
`Error: Failed to execute 'appendBuffer' on 'SourceBuffer': The HTMLMediaElement.error attribute is not null`
Many of these are rendered incorrectly in some way.
This PR contains only the tests, but not the screenshots, to make the
tests easier to review. The screenshots will appear in a separate PR.
Related to work on PR #4767
Many of these are rendered incorrectly in some way.
This PR contains only the screenshots, to make the tests easier to
review in a separate PR.
Related to work on PR #4767
Now screenshots are grouped by test for easy comparison across
platforms, and have an optional line break element between each set of
tests.
Related to work on PR #4767
This rewritten screenshot review tool is more dynamic and better
organized.
It is now easier to add additional test suites, and filtering can be
done dynamically by any attribute (platform, suite, or test).
Related to work on PR #4767
There is currently only one suite, but that is about to change. This
renames all screenshots to include the name of the suite, and updates
the review page with a temporary hard-coded suite name.
Related to work on PR #4767
Also fixes a compiler error that comes up for some reason when renaming
the other tests. The compiler will accept an assignment to nestedCues,
but not pushing to it. I was unable to fix the missing type information
for this.
Related to work on PR #4767
This test started failing on Tizen after PR #4858, which updates codecs
in manifest metadata any time they are rewritten. Since ac-3 is
rewritten as ec-3 on Tizen, that caused this test case covering ac-3 to
start failing (because the codec says ec-3 by the end of the test).
Make SegmentIndex robust against rounding errors so that we don't end up
with duplicate segments on merge. In sequence mode, this would cause a
massive AV sync issue of 1 segment duration.
Issue #4589
Discontinuity tracking was broken and test coverage was insufficient to
catch this. This fixes the parsing and counting of discontinuities, and
replaces two outdated and useless tests with a new one that covers the
counting properly.
One of the old tests was checking that a timestamp offset was set for
each discontinuity, but this had become irrelevant since the test was
written. Discontinuities do not have anything to do with timestamp
offsets in current versions of Shaka Player.
The other old test was checking that after a discontinuity, we didn't
fetch a segment to parse out the timestamp, but we stopped doing that
entirely in v4.
The new test checks that the initial discontinuity sequence number is
honored, and that after a discontinuity, the number goes up. It also
checks that the correct number is extracted after an update. This test
fails without the fix, and passes with it.
This bug affected v4.2.6 and v4.3.2 only.
Issue #4589
Some of the EMSG tests were redundant, and repeated for different
timestamps. Instead, run all EMSG tests with a non-zero timestamp
offset, since 0 is just a degenerate case.
This also consolidates all of the test vectors so that the tests are
easier to read.
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
Captions split over stream segment boundaries are repeated over more
than one segment.
Regions in which they sit maybe described the same but allocated
different ids and vice versa.
Proposal to treat internal region ids uniqely by encoding the dimensions
in the id.
fixes#4839
If server-side ad segments aren't aligned, AV could get out of sync by
accumulating errors in the timestampOffset of the SourceBuffers.
This improves the issue by tracking discontinuity boundaries and
resetting timestampOffset to theoretical segment start times when a
boundary is crossed.
Issue #4589
For some unknown reason, using precise durations for these audio
segments on Tizen creates gaps that can't be survived. I don't know why
that creates a 150ms gap, and I don't know why we can't seem to jump
over it. It feels very much like a bug in Tizen itself.
Experimentally, I found that rounding these durations to 10s even
removes the gap completely. I tried many other things, but this is the
only reasonable thing I have found that works.
More details on my investigations can be found in the issue on GitHub.
This change in durations exposed some brittle tests in Player which had
to be adjusted to be more robust.
Closes#4806
Unhandled global exceptions already generate test failures, but this
adds specific useful information, like stack traces, to those failures.
See issue #4813
Reinstate previously removed region elements when next caption finds it
is not there: Detect the absence and ensure `updateDOM` is true so its
reinstated and the next caption can be shown.
Closes#4680
Co-authored-by: Joey Parrish <joeyparrish@users.noreply.github.com>
Caches the results of MediaSource.isTypeSupported, which is slow on some platforms, to reduce the
number of calls needed. This is especially helpful on manifests with many similar variants (multiple languages, etc).
Data collected from 2 months of practical testing shows that this helps reduce the start lag by 40% on Chromecast, 15% on WebOS, and 12% on Tizen.
See https://github.com/shaka-project/shaka-player/issues/4726 for more
context.
This allows Cast devices to properly filter stream variants with a
resolution surpassing that of the device's capabilities.
We place the fix in the `MediaCapabilities` polyfill since it's intended
to be the right way to check for anything related to platform support.
HDR support checks will require `eotf=smpte2048`, as indicated in
https://github.com/shaka-project/shaka-player/issues/2813#issue-684874730.
Specifically, a `{hev|hvc}1.2` profile is only an *indication* of an HDR
transfer function, but *may* be a non-HDR 10-bit color stream.
In Cast, the platform can distinguish between the two by explicitly
providing the transfer function; it uses `smpte2048` (`"PQ"`) because
this is the "basis of HDR video formats..."
(https://en.wikipedia.org/wiki/Perceptual_quantizer).