> 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
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
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>
Few bugfixes to support DT Zenterio platform:
- Zenterio seems to have a problem with the EME onKeyStatus event payload (the key statuses map), where the map key ID comes in as empty. This is not correct based on the EME spec:
https://w3c.github.io/encrypted-media/#dom-mediakeysession-keystatuses
- Add polyfills that are used to fix issues with older webkits, same as for older safari browsers
For some reason on PS4, the check `val.buffer.constructor == ArrayBuffer` returns `false` when it should be `true` which causes the object cloning to return `null` instead of the array buffer.
Modifying this to `val.buffer instanceof ArrayBuffer` now returns true which fixes the issue. This should work across devices.
Original author: @nick-michael
Co-authored-by: Nick Michael <nick-michael@users.noreply.github.com>
David HM Morgan
Álvaro Velad Galván
Wojciech Tyczyński
Gary Katsevman
theodab
Casey Occhialini