> Quote from specs:
> Valid examples include:
> • "stpp.ttml.etd1" - TTML content suitable for presentation by an
EBU-TT-D renderer
> • "stpp.ttml.etd1|im1t" or "stpp.ttml.im1t|etd1" - TTML content
suitable for presentation by an EBU-TT-D or
IMSC1 renderer
Fixes#6831
Always compute sha1 in lab and screenshot workflows in advance. A symbolic ref can change mid-workflow if the repo changes.
Co-authored-by: Aviv Keller <38299977+RedYetiDev@users.noreply.github.com>
On Firefox, in some cases after a period ends, seeking shortly after
will cause playback to fail or stall.
This occurs when the next period has small gaps and we're seeking to
after the gap. Seeking to before the gap succeeds. Even though the seek
requests the soure buffers to be fully cleared, Firefox actually keeps
around less than 1e-4s of content and won't let us forcibly remove this
content. Trying to call flush causes in infinite loop.
This leftover content makes shaka think that the buffer end in where we
used to be even though the presentation time reflects where we seeked
to. This means that playback doesn't continue. The buffer contitues
getting filled and playback will either fail when the SourcBuffer is
filled and triggers a QuotaExceededError or contiue when the buffer will
reach the presentationTime.
https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-6.2.4
```
If any Playlist contains Date Ranges, then at least one Playlist
in any playable combination of Renditions of any Variant Stream
MUST contain Date Ranges. Any Playlist with Date Ranges MUST
contain the same set of Date Ranges as the others that do. The
EXT-X-DATERANGE tags of corresponding Date Ranges MUST have the
same ID attribute value and contain the same set of attribute/
value pairs.
```
So it would not be allowed. We can omit Date Ranges from img and
subtitle Playlists in a Rendition that has Date Ranges in the Variant
Playlists (main video STREAM-INF Playlists).
For our Seek To Date feature, we need the presentation start date
directly from the manifest since all of the client’s key play times are
based directly on the `availabilityStartTime` from the manifest
directly.
On WebOS 3.0 we've noticed an issue in production, where TVs are slowly
starting to throw the following error after a user has watched at least
30+ episodes: `Code: 6006 Category: 6 Severity: 2 ["EME v0.1b key
error",{"errorCode":{"code":1,"systemCode":65535}},"0xffff"]` and can
only be resolved by clearing the app cache, or unplugging the TV.
Further investigation revealed that current workflow, where MSE is
destroyed before DRM Engine causes that old EME implementation is not
able to close session properly.
- adds optional argument to `selectAudioLanguage()` which gives us a way
to select preferred audio codec
- updates `PreferenceBasedCriteria` to reflect the change
- renders codec in shaka UI to help distinguish tracks with the same
language, role, channels, etc
- can be tested on Chrome with `Tears of Steel (multicodec, TTML)` asset
The next release of the Cast Application Framework is expected to ship
with a release from the v4.9.x branch by default, so we are no longer
maintaining v4.3.
After a previous bugfix to the preload system, we ended up with a
situation where the
overall progress in the preload was tracked by two promises:
`successPromise_`, which is resolved when the preload finishes
successfully.
`destroyPromise_`, which is rejected with an error when the preload
process trips an error condition.
These two promises were confusingly named; it sounds like destroyPromise
is related to the destroy process,
but really it has more to do with errors.
They were also completely redundant, as a single promise can be used to
carry both a resolved and
rejected state.
This PR simply combines the two promises into one.
---------
Co-authored-by: Joey Parrish <joeyparrish@google.com>
David HM Morgan
Álvaro Velad Galván
Joey Parrish
Wojciech Tyczyński
dependabot[bot]
Gary Katsevman
theodab