Apple QuickTime places a manufacturer field ('appl') immediately after
the handler type ('soun'), causing readTerminatedString() to incorrectly
read 'sounappl' instead of 'soun'. This breaks Opus fMP4 audio playback
for content packaged with Apple tools.
Replace null-terminated string parsing with fixed-length byte reading to
extract exactly 4 bytes for the handler type.
Closes#9576
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
This is the first step in a series of efforts to simplify how we handle
text tracks internally.
The purpose of `autoShowText` has always felt a bit unclear. It was
originally added because Shaka wasn't flexible enough when choosing an
initial text track. I don't think we should try to handle every possible
scenario for initial text track selection. Instead, we should respect
`config.preferredTextLanguage` and let the application decide if it
needs more granular control. Apps can already do this easily with
`getTextTracks()` and `selectTextTrack(track)`.
Ultimately, I'd like to move toward a simpler API where either a text
track is selected or none is. If nothing is selected, we shouldn't
stream any text at all.
See https://github.com/shaka-project/shaka-player/issues/9301 for extra
context.
This PR adds `isLCEVC` check to the `basicResolutionComparison` and
appends `'LCEVC'` to the label text in `getResolutionLabel_` if the
track is LCEVC. This makes it easier to tell LCEVC profiles apart and
fixes an issue we were seeing when many different Dual-Track profiles
are contained in the manifest, it might be hard to differentiate them
(e.g. base and LCEVC profile with the same 1080p resolution).
Fixes#9056
This PR fixes:
- The fact that CMCD functions were executed when the feature was
disabled in https://github.com/shaka-project/shaka-player/issues/9056
The issue was identified on response mode workflow, where data
processing was being executed even if target was disabled. Request and
Event mode were already skipping processing if disabled.
In order to fix the issue, data processing is now skipped if response
mode targets are disabled or not configured.
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.
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>
# CMCD V2 - Response Mode
## PR Description
This PR focuses on the implementation of Response Mode functionalities
for version 2 of the Common Media Client Data (CMCD v2) specification
within the Shaka Player project.
Key changes made in this pull request include:
- **Response Mode**: CMCD v2 introduces "Request Mode" "Response Mode"
and "Event Mode". Request Mode aligns with the default delivery mode in
CMCD v1. Response Mode, which this PR implements, allows clients to send
data to one or more alternative destinations after receiving either a
full response or an error to a media object request. These reports use
one of the defined data transmission modes (Query Mode or Headers Mode)
- **CmcdTarget**: A new configuration type, `shaka.extern.CmcdTarget`,
was introduced. This configuration allows specifying the transmission
strategy (mode=response) since targets can also be configured for
**event mode** (mode=event), whether it's enabled (enabled), if it uses
HTTP headers mode (`useHeaders=true`) or query parameters mode, the
destination URL (url), and specific keys to include (`includeKeys`). For
Response Mode, the mode value includes 'response'.
- **Independent Handling of Transmission Modes**: Request mode and
Response mode can be enabled and disabled independently using the
previously mentioned CmcdTarget config for response mode and the base
config for request mode.
- **Validation and Filtering of Keys**: Allowed keys for Response Mode
were added, and validation for these keys was implemented. The
capability to include (`includeKeys`) and filter specific keys for both
Request Mode and each Response Mode target was also enabled. Also, CMCD
dictionary definitions were moved to a new dedicated section to improve
structure
- **Unit Tests**: Extensive unit tests were included and unified to
validate CMCD v2 functionality in both Request Mode and Response Mode.
Config example with request mode and targets with response mode:
```js
const cmcdConfig = {
enabled: true,
version: 2,
contentId: 'content-id',
useHeaders: false,
targets: [{
mode: 'response',
useHeaders: false,
enabled: true,
url: 'http://localhost:3003/response-mode'
}]
}
```
## Keys not implemented in this PR
The following keys are defined in the CMCD v2 specification but are not
calculated or attached to requests/responses in the `cmcd_manager.js`
code:
- **Common & Request Mode Keys:**
- **`ab` (Aggregate encoded bitrate)**
- **`tbl` (Target Buffer length)**
- **`cdn` (CDN Id)**
- **`bg` (Backgrounded)**
- **`sta` (State)**
- **`ts` (Timestamp)**
- **`tpb` (Top playable bitrate)**
- **`lb` (Lowest encoded bitrate)**
- **`tab` (Top aggregated encoded bitrate)**
- **`lab` (Lowest aggregated encoded bitrate)**
- **`pt` (Playhead time)**
- **`ec` (Player Error Code)**
- **Response Mode Keys:**
- **`rc` (Response code)**
- **`ttfb` (Time to first byte)**
- **`ttfbb` (Time to first body byte)**
- **`ttlb` (Time to last byte)**
- **`url` (Request URL)**
- **`cmsdd` (CMSD Dynamic Header)**
- **`cmsds` (CMSD Static Header)**
Related to https://github.com/shaka-project/shaka-player/issues/8660
---------
Co-authored-by: Constanza Dibueno <121617928+cotid-qualabs@users.noreply.github.com>
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
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>
This PR introduces support for `ProducerReferenceTime` tags in DASH.
When finding any, it emits event, similar to inband PRFTs added in
#4389.
Additionally, calculated start date from `ProducerReferenceTime` is used
as program start date, as it's more accurate value than
`MPD#availabilityStartTime` used before.
Player errors out for Dolby contents in adaptive streaming because
correct mimetype is not identified.
This change adds ac3, ac-3, eac3, ec-3, and ac-4 mimetype support.
---------
Co-authored-by: Srikanth Peddibhotla <peddisri@amazon.com>
Previously, shaka.util.StringUtils.fromBytesAutoDetect assumed any
character between ' ' and '~' was ASCII.
This worked for many cases, but it meant that the method would be unable
to determine the encoding of a buffer if there was a newline character
near the start.
This could be a problem for parsing, for example, JSON.
Closes#8336
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.
Fixes#8052
Key ids were not used when looking for stream duplicates, so it was
possible to filter out streams without accompanying configuration. Now
we will use key ids as well for duplicates detection.
Our Apple device detection misdetects any Webkit-based STB as Apple, due
to looking only at vendor property. To mitigate it, we were excluding
another user agents, but maintenance of this is problematic.
This PR tries to change direction - an Apple device right now is a
device with Apple vendor AND with characteristics of MacOS or iOS.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
Álvaro Velad Galván
Woody Hill
Matthias Van Parijs
Constanza Dibueno
Romualdas Paskevicius
Casey Occhialini
Joey Parrish
Juan Manuel Gonzalez
Wojciech Tyczyński
Srikanth Peddibhotla
theodab
Darrin DuFord
vlazh