In LCEVC dual-track implementation, both tracks share the same
originalVideoId, which causes one to be dropped when `getVideoTracks()`
returns them as a Map. This PR assigns a unique originalVideoId to each
track to ensure both appear correctly in the resolution menu
We had an issue where in SSAI content, 708 data was being split by ad
periods. Currently, when this happens, we reset the 708 decoder, which
means that captions are lost. Instead, we want to cache this decoder for
a later time. This change keeps track of continuous periods and caches
the 708 decoder when a period change happens to a discontinuous period.
This is so that it could be later restored if we go back to a continuous
period.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
Co-authored-by: Wojciech Tyczyński <tykus160@gmail.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.
There's devices out there that are not compliant with the MSE spec. Such
as halting MSE when a secondary init segment is appended (webOS 3), or
failing to transition from a plain to encrypted init segment (Tizen
2017). While we initially prefer content workarounds, it's a time
consuming and trial & error process. For some devices it might not be
worth investing time into finding a proper workaround due to low usage.
We're giving people an alternative by resetting MSE when needed
(configurable). dash.js offers somewhat similar behavior
[here](https://github.com/Dash-Industry-Forum/dash.js/blob/a656ec709e7f92f76b392bf196ee9883da7928ce/src/streaming/controllers/StreamController.js#L672),
where MSE is reset before applying an encrypted init segment.
This PR introduces `crossBoundaryStrategy` in `StreamingConfiguration`.
It can be configured as following:
- KEEP - we're keeping MSE active, this is the default and the current
behavior.
- RESET - we'll always reset MSE when it crosses a boundary.
- RESET_TO_ENCRYPTED - we reset MSE when it crosses an encrypted
boundary, and we keep MSE afterwards. Additionally, we're not going to
reset when we're crossing a plain to plain boundary.
Each initSegmentReference now holds an `encrypted` and `boundaryEnd`
value. When configured with a different value than KEEP,
`StreamingEngine` will be instructed to fetch and append segment
references up until the boundary of the currently applied init segment.
We detect whether we're at a boundary in a few ways:
- Listening to the HTML5 MediaElement's `waiting` event, this'll
indicate that we do not have enough buffer to advance. If we're pretty
close to the boundary, we assume we're at the boundary.
- Due to subtle differences in the segment alignments, waiting wasn't
reliable. When close to a boundary, a timer is fired with the assumption
that "we'll reach the boundary at soon". I've set the threshold to 1
second, when playhead is further than the threshold, we'll skip checking
whether an MSE reset is due.
The implementation relies on the added properties in the init segment
reference, and the concept of a "Period" is avoided in StreamingEngine
to ensure it's compatible with HLS too.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
Co-authored-by: Wojciech Tyczyński <tykus160@gmail.com>
Previously, if the presentation delay was not specified either by the
manifest or by configuration, we defaulted to 1.5 * minBufferTime. That
approach worked for most content, but in some cases it could cause live
streams to start out with a seekRangeEnd that was before the live edge.
This would lead to a brief pause in the beginning of the presentation,
while the live edge caught up.
This changes the DASH parser to use the segmentAvailabilityDuration if
it is lower than 1.5 * minBufferTime, which fixes that issue.
It also changes how that part of the code to be formatted, in order to
hopefully make the increasingly-complex logic for determining the
presentation delay more clear.
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 autoLowLatencyMode config is removed because it's no longer
necessary. Now lowLatencyMode only enable low latency if the stream is
low latency.
A new method is added (configurationForLowLatency) to allow configure
the Low Latency config more easily
Based on the work of @gmcgarry Thank you very much!
Currently the codec adds supplemental codecs to the list of allCodecs
and has an implicit priority order to select a codec. Support for the
codec is tested with MediaSource.isTypeSupported().
There are multiple issues with this approach:
- the priority is implicit
- MediaSource.isTypeSupported() decision is effectively overriding
platform-specific MediaCapabilities logic
- MediaSource.isTypeSupported() is frequently wrong depending on whether
the content is encrypted
This patch duplicates the variant with each supplemental codec and
defers codec priority and codec selection until after
MediaCapabilities.decodingInfo().
This fixes support for DolbyVision Profile 8, which is otherwise broken
because the chromium browsers always return false from
MediaSource.isTypeSupported(), and DolbyVision is commonly only
available in a secure hardware decode pipeline.
Note: Safari does not have this problem since it supports Dolby Vision
in clear
---------
Co-authored-by: Wojciech Tyczyński <tykus160@gmail.com>
Related to
https://github.com/shaka-project/shaka-player/issues/7602#issuecomment-2479518970
From 23009-1:
The value of the minimum buffer time does not provide any instructions
to the client on how long
to buffer the media. The value however describes how much buffer a
client should have under
ideal network conditions. As such, MBT is not describing the burstiness
or jitter in the network,
it is describing the burstiness or jitter in the content encoding.
Together with the BW value, it is
a property of the content. Using the "leaky bucket" model, it is the
size of the bucket that makes
BW true, given the way the content is encoded
The PR is solving playback error in a Multi period manifest when the
start time is not 0.
Additionally, solving the error code 3015 due to the clear of the buffer
during the playback.
Fixes https://github.com/shaka-project/shaka-player/issues/7401
v-nova-romas
Gary Katsevman
Álvaro Velad Galván
Wojciech Tyczyński
Matthias
Julian Domingo
Koen Romers
theodab
Iragne
ncocaign
Gregory McGarry