UITextDisplayer was triggering:
"ResizeObserver loop completed with undelivered notifications"
This happened because updateCaptions_() mutates the DOM inside the
ResizeObserver callback, which can cause synchronous layout feedback
loops.
This change:
- Observes videoContainer_ instead of textContainer_
- Defers updateCaptions_() using requestAnimationFrame
- Coalesces multiple resize events using a pendingResize_ flag
- Ensures updates only run when captions are visible
This prevents layout feedback loops while preserving correct caption
re-rendering behavior.
Fixes https://github.com/shaka-project/shaka-player/issues/9721
Added polyfills for `Map.getOrInsert()` and
`Map.getOrInsertComputed()` from the TC39 upsert proposal and refactor
the codebase to use them.
These methods replace the common "check if key exists, then set default"
pattern with a single atomic operation. This improves code readability
and eliminates redundant map lookups throughout the player.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
TextEngine was storing closed captions and releasing them only on
teardown. This might be a potential memory leak for long running
sessions.
This PR addresses it by removing cached captions along with removed
segments. Furthermore, it adds some more tweaks and improvements, such
as:
- simplify CEA cache structure, from `Map<string, Map<string,
Array<Cue>>>` to `Map<string, Array<Cue>>`
- adjust TextEngine buffered ranges with cached cues values
Make cloning buffers (or not) explicit in readBytes.
When we use a range of bytes temporarily for further parsing, we pass
clone=false and get a view on the existing memory buffer. When we want
to store the range of bytes, we pass clone=true and avoid holding a
reference to an entire segment in memory.
The call for the EMSG parser in MediaSourceEngine had an explicit clone,
but now uses the new clone parameter. This is not a functional change,
though.
The only readBytes call that changed in this audit was in the UI seek
bar.
The rest all appear to be values for temporary usage, and so are not
being cloned.
The new `clone` parameter will require future callers of `readBytes()`
to think about their purpose and make a choice.
The goal is to simplify and abstract feature logic detection. Currently
lots of places depend on various calls to `shaka.util.Platform` and
mainteinance of this is hard & not easy to read.
By introducing device API ideally rest of the player logic would look
into device features instead of directly checking platform. Additionally
we can more easily cache needed values, so we won't have to parse user
agent several times anymore.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
Close https://github.com/shaka-project/shaka-player/issues/8519
Fixes https://github.com/shaka-project/shaka-player/issues/8475
Introduce `NativeTextDisplayer` as a replacement of
`SimpleTextDisplayer`. But keep them both work.
Is MSE mode, `NativeTextDisplayer` creates `<track>` elements for text
streams. And listens to change events on both ends to keep them in sync.
In SRC mode, `NativeTextDisplayer` would do nothing, the player uses
original TextTracks instead.
Advantages of `NativeTextDisplayer`:
- Allow text track selection using the browser built-in UI
- Allow text track manipulation using native APIs
- Avoid transferring and processing cues in SRC mode
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
Fixes#8278
Migrates deprecated rules from `eslint-config-google` and our rules as
well to stylistic.
Additionally removes broken `eslint-disable` python check and replaces
with eslint `reportUnusedDisableDirectives` option.
With reference to #8025, this is a partial proposal to see if this style
of extensible customisation could be favourable to the shaka-player
community:
Proposal for some accessibility options whereby an App builder can
customise subtitle/caption size, with the potential of an App offering
accessibility options for text size.
This style could be used for other text styling attributes in a similar
way, but this is just the first step.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
Fixes https://github.com/shaka-project/shaka-player/issues/8087
Implements handling of multiple samples in a MP4/ISOBMFF/DASH TTML
segment/fragment. Such segments are allowed by ISO14496-12 and
ISO23000-19. gpac creates such segments. The prior code just treated the
full MDAT as one TTML XML document and tried to parse it in whole
without accounting for sample(s). A testcase is included which was
created by taking the testdata from ttml-segment.mp4 and splitting the
subtitles into two independent TTML-XML documents, which then were put
as individual samples.
The testdata for the prior existing multiple MDAT testcase was invalid.
It was created by taking the same ttml-segment.mp4 as a source and just
duplicating the MDAT box, but without then also fixing the TRUN box. The
duplicated data was thus not referenced. The test case still worked,
because the prior code did not look at the TRUN box and the sample
specification at all and just handled any full MDAT box = 1 sample. The
testdata was replaced with a new file, which is basically the same as
for the multiple samples case, but with the two samples split into two
MDAT boxes.