On long videos with lots of chapters Chromium based browser were showing
the chapter markers as blury lines instead of clearly defined lines.
This solves that problem by taking advantage of the fact that CSS
supports multiple backgrounds and creates a separate one for each
chapter. It also applies the same change to the ad markers.
This PR reduces allocation pressure in MP4 segment generation by writing
mdat data directly into the final segment buffer - this avoids one full
media-payload copy per segment
In `H264.getVideoSamples()` `lastVideoSample.data` is initialized with
an empty `Uint8Array` which is always replaced before the sample is
pushed into the `videoSamples` array, so to avoid creating a new empty
placeholder `Uint8Array` for each sample, the empty `Uint8Array` can be
created once and then use to initialize all `lastVideoSample` objects in
that segment.
`TSParser.parsePES_` had a similar placeholder empty `Uint8Array` issue,
which I was able to resolve by creating the PES object in the return
statement instead of upfront, that way it can be initialized with the
final data, avoiding the placeholder.
While yes empty Uint8Arrays definitely need less memory than larger
ones, it is still better to not create 100+ unnecessary objects in rapid
succession which then need to be cleaned up by the garbage collector
later on.
This PR replaces a full-config deep-clone in Player.getBufferFullness()
with a direct read, removing a per-timeupdate allocation for playback
sessions that have liveSync configured, or `vodDynamicPlaybackRate`
This improves TS h265, TS AC-3, TS EC-3, raw AC-3 and raw EC-3 as the
transmuxer calls `parseFrame` for each frame in the payload passed to
the `transmux` method, for LOC h265 this is marginally worse as it only
calls `parseFrame` once per `transmux` call.
- Remove duplicate entry in the 5.0 list
- Rename the 5.1 list as 6.0 (named for the version in which something
is removed, with a note about the deprecation version)
- Reindent the set of related config changes
Noticed while preparing CAF for 5.0 compatibility
We recorded a h264 + opus video and audio stream with chrome
mediarecorder api.
From debug mode, I noticed that transmuxed opus chunk was 3x shorter
than video, but ffmpeg showed that they should be about the same.
It turns out the duration is not set correctly. Before the fix, repeated
seeking will eventually get stuck. After this fix, I can verify that
seeking no longer is stuck.
Co-authored-by: Claude <noreply@anthropic.com>
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
This PR reduces steady-state work during HLS live/DVR playlist refreshes
by avoiding already known segments' re-construction. Before this, on a
live playlist update, the parser would still call
createSegmentReference_() for every segment, though only the newly
appended tail was actually merged into the segment index.
Region elements were cached by an ID that omitted regionAnchorX and
regionAnchorY, causing regions that shared the same viewport anchor but
differed in region anchor to reuse a previously cached DOM element
positioned incorrectly. Include both region anchor values in the
generated ID so each unique anchor combination gets its own element.
Issue: https://github.com/shaka-project/shaka-player/issues/2583
This PR removes slice for a simpler truncation - especially good for
`merge` because we just truncate from the back. No need for allocation
for none of them anyway so this is an easy win
This PR extends work from #5061 to DASH SegmentTemplate@duration streams
by lazily creating fixed-duration segment references instead of building
the full index up front during manifest parsing
`Mp4Generator.box()` merges all arguments into one `Uint8Array`, so
arrays of `Uint8Arrays` can be spread directly into the
`Mp4Generator.box()` calls instead of doing the extra step of merging
them into a single `Uint8Array` first. I also included a drive-by change
to simplify `array.push(...[x, y])` into `array.push(x, y)` in the
`segmentData` method.