PR #8603 refactored the conditions for being "buffered to the end". Two
of these conditions from Player didn't fit in the new location
(Playhead). One (this.isEnded()) was moved, and the other
(this.mediaSourceEngine_.ended()) was dropped by accident. This restores
the dropped condition next to isEnded().
Verified in the Cast Application Framework.
Removes duplicated logic around timestamp offset checks - now check is
only in `resync()` method. It should stay there, because it ensures it
will be executed only in sequence mode and also avoids otherwise
unnecessary `abort()` call.
Increases threshold to 150 ms as it was the originally proposed value
and gives better experience.
Now timestamp offset change won't be applied in sequence mode if it's
less than 150ms from buffer end, regardless of manifest type.
# 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>
For DASH segment templates, MpdUtils.fillUriTemplate() is used for
substitution of tokens in the fetch URL, like $RepresentationID$. When
supplemental codecs are used, the incorrect RepresentationID will be
substituted for media segments. The initialisation segment is correctly
substituted.
The symptom is that fetches for media segments will fail with 404
response codes.