- Replace split(':') with startsWith('data:') for scheme validation
- Use indexOf(',') instead of split(',') to avoid unnecessary
allocations
- Remove window dependency from decodeURIComponent
- Normalize base64 detection using toLowerCase()
This change allows to execute request filter on every request attempt.
It can be useful i.e. to update credentials when first request fails.
New field `attempt` has been added to `shaka.extern.Request` which
informs which attempt is currently ongoing. This is needed to not do the
unnecessary work multiple times.
HTTP 401 Unauthorized and 403 Forbidden are no longer treated as
immediate critical errors, as tokens can be updated during retry
process.
`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.
# 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>
Provides the Segment Reference to the ABR Manager via the request
context. This allows the ABR manager to get information about the
specific segment being downloaded such as the start and end time (used
to calculate segment duration).
Adds a replacement for removed JSDoc checks from ESLint v9.
Additionally fixes lots of issues found in the JSDoc, such as:
- missing `@param`/`@return` annotations
- bad formatting
- params order
- param name in the same line as type definition (tried to disable it,
but it was causing other issues and we didn't have lots of places with
such formatting)
Minor fixes in code found by Closure Compiler after fixing JSDoc are
also included.
The Cast SDK currently assumes that SEGMENT response objects always have
data, however this stopped being true for HEAD requests in v4.3.6.
This PR fixes the behavior of the Fetch plugin so that HEAD requests
will at least have an empty ArrayBuffer for data, as they did in v4.3.5
and earlier.
The Cast SDK will also receive a fix to stop assuming this, fixing
compatibility with v4.3.6+ - v4.12.6.
This incompatibility between the current Cast SDK and these versions of
Shaka Player is only triggered by HLS content whose segment URLs have no
recognizable extension.
Affected Shaka Player versions:
- v4.3.6 - v4.3.16
- v4.4.x - v4.8.x
- v4.9.0 - v4.9.34
- v4.9.2-caf - v4.9.2-caf4
- v4.10.x
- v4.11.0 - v4.11.18
- v4.12.0 - v4.12.6
Affected Cast Web Receiver SDK versions:
- <= 3.0.0137
Fixes will be in:
- v4.9.35+
- v4.9.2-caf5+
- v4.11.19+
- v4.12.7+
- v4.13.0+
Closes#7600
By limiting progress events to only ones with minimal chunk size, we might end up with feeding better default ABR implementation, which should result in more accurate adaptation in case of network throttle.
Some assets might rely on networking engine filters (request and
response filters) to properly download their assets. However, the
preload manager's need to use a fresh networking engine also caused it
to not use any filters set on the player already. This changes the
process of setting up a preload manager, to make it copy over any
filters defined on the player's networking engine.
Fixes#6698
This PR makes the following request information available for ABR consideration. Allowing the ABR manager to know about the request latency from the time to first byte and knowing the order order of a packet, as well as the contentType of the request.
Álvaro Velad Galván
Julian Domingo
Wojciech Tyczyński
Joey Parrish
Juan Manuel Gonzalez
Srikanth Peddibhotla
Nick Michael
vlazh
Wojciech Tyczyński
theodab
Dave Nicholas