After #7617, we stopped using the polling mechanism and playback rate to
control the buffering state, but the old behavior of checking the buffer
was still in place. Moreover, since buffer thresholds were set based on
the rebuffering goal value, when that value was 0, the underlying logic
tended to underreport buffering.
Now, when the goal is 0, Shaka will rely solely on media element events
for buffering reporting.
This pull request introduces comprehensive support for the CMCDv2
"event" mode in Shaka Player. This new functionality allows the player
to send real-time Common Media Client Data (CMCD) based on various
player and media events
- CMCDv2 Event Mode Implementation: Partial support for CMCDv2's "event"
mode has been implemented, enabling real-time event data reporting from
the player.
- Configurable Event Reporting: Configuration options have been
introduced to specify which CMCD keys and player events (e.g., play
state, mute/unmute, fullscreen, background mode) are included in the
reports.
- Periodic Time Interval Events: A timeInterval configuration option has
been added for periodic CMCD event reports, with a default of 10 seconds
and the ability to disable by setting it to 0.
- Unit Testing: Extensive unit tests have been added to validate the new
CMCDv2 event mode functionality across various scenarios, including
event filtering, header usage, and handling of multiple targets.
Shaka Player config for testing event mode:
```js
const cmcdConfig = {
enabled: false,
version: 2,
contentId: 'id',
useHeaders: false,
targets: [{
mode: 'response',
enabled: false,
useHeaders: false,
url: 'http://localhost:3003/response-mode',
},{
mode: 'event',
useHeaders: false,
url: 'http://localhost:3003/event-mode',
includeKeys: [],
enabled: true,
}]
}
player.configure('cmcd', cmcdConfig);
```
---------
Co-authored-by: Constanza Dibueno <121617928+cotid-qualabs@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
Use PSSH string to cache init data in order to avoid creating duplicated
init data buffers. On streams with many periods due to ad insertion it
can make a difference - i.e. on stream with 50 periods this change
reduces used memory by init data buffers from 40 KB to 1 KB.
In DASH, PSSH can often be a duplicated data between protected periods
and/or adaptation sets.
Since `RegionTimeline` is used for storing EMSG events, used memory
significantly grew when content extensively uses EMSG.
When creating EMSG region, we’re creating `message_data` by using method
`readBytes()` from `DataViewReader`. Internally, it calls
`BufferUtils.toUint8(buffer)` which creates new `Uint8Array` on shared
`ArrayBuffer`. We need to make a copy with data needed only to not store
whole segments in memory.
Some HLS streams have the same originalAudioId for multiple tracks, so
to avoid filtering out the tracks we want, we add the language, label,
channelsCount, and spatialAudio to get a more accurate ID.
`Headers` class and `XMLHttpRequest.setRequestHeader` throw an error if
added header is not a valid byte string, so we should take an advantage
of it instead of throwing an incompatible error.
Add a new element for inline SVG icons that is supposed
to be a replacement for the current icon fonts.
I use filled Material Symbols Rounded icons as default.
Intended to support a future transition away from icon fonts.
Related to https://github.com/shaka-project/shaka-player/issues/2467
If the manifest has no PDT or PST it will currently result in calling
`new Date(null * 1000)`, equivalent to `new Date(0)`, which results in
an unexpected start time date. I believe a better behaviour in this
scenario is to simply return null, since I believe startTime resolving
to null here should be considered a valid case that shouldn't need to be
asserted against.
A manifest does not necessarily have a PDT or PST if it is a basic live
or VOD manifest. The caller of the function may not know this before
calling `getPresentationStartTimeAsDate`.
There is no good way of checking ahead of calling
`player.getPresentationStartTimeAsDate` if calling the method is valid
or not.
`startTime` being `null` here seems like a valid scenario to me. It
should not result in a erroneous call to `new Date` with `null` and
instead just return `null` and log a warning.
- Bump to Java 21 to support the new compiler.
- Removes externs now included in the compiler.
- Removes compiler flag no longer supported.
- Adds onkeystatuseschange to MediaKeySession polyfills (now in compiler
externs).
- This new compiler now triggers a warning in the Closure Library, which
will get fixed in a follow-up to update the library.
Use `buffered` property directly, as there is no need for us to create
ranges from SourceBuffers. Also, just take start and end from frist and
last range, respectively, looping is unnecessary.
Álvaro Velad Galván
Wojciech Tyczyński
Juan Manuel Gonzalez
Phyo Wai Lin
Agajan J.
Martin Stark
Joey Parrish