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
In live streams, we can evict segments outside the availability window
faster than they disappear from the manifest. If that happens, we used
to evict them several times (add them back in and then evict again).
This caused the eviction counter to increase beyond what it should be
and we had trouble finding segments afterwards.
Closes#3139.
Change-Id: Iafebfaf8e1e9ebb09a64cdf7e09a882115fd8eb6
When a multi-period DASH manifest contains periods which are in the
future (described in the manifest, but with all segments past the
current end time of the segment availability window), the segments
generated for SegmentTemplate were invalid. Not all DASH multi-period
content describes unavailable future periods, so many providers using
DASH would not see this issue. This bug affected v3.0.0 - v3.0.7.
To fix this, we change the "next position" calculation for updates to
clamp to the minimum valid position. This avoids creating segment
references with negative position numbers for these future periods.
When the segment availability window moves to include this period, we
will then start generating segments for it (starting at position 0 or
whatever the startNumber attribute is for this period).
However, the contract for updateEvery() in SegmentIndex was such that
the timer would stop if the list of references was every empty. This
was meant to handle the case in which all segments were evicted, but
it could be triggered instantly on these "future" periods, for which
no segments exist yet in the availability window. To resolve this,
the contract was changed so that the updateEvery() callback must
explicitly signal a stop by returning null instead of an array of
segment references.
Bug: 179025415
Change-Id: I56a2826fd3aea3f69da7b8bf4fa7629562d63506
Previously, on manifest updates, embedded captions would vanish in
single-period live DASH streams. The problem was based on the
specific point in the load order that we added dummy text streams
to indicate the presence of embedded captions.
This modifies the PlayerInterface for manifest parsers to add a
new method passed in, makeTextStreamsForClosedCaptions, which
must be called by manifest parsers for new video streams.
This also completes an unfinished feature, where new video streams
which add new closed captions would not get corresponding
text streams.
Closes#2811
Change-Id: Iee7499ec950b363cf6839765cc2bd2d01743467d
We have decided to bump the major version number instead of the minor
number, based primarily on the fact that this release breaks
compatibility with our previous manifest structure.
Change-Id: I67e4c8267c6e103cfc7278e09daac186ae5cbbc6
Period-flattening will concatenate Stream objects, so this information
should be available per-Stream instead of at the Variant level.
Issue #1339
Change-Id: I96195fea48cab1e4a349b2ab0b16064a443e928a
As part of Period-flattening, I'm trying to remove our dependence on
the "position" field of SegmentReference. With that eliminated, we
can more easily concatenate Arrays of SegmentReferences without
modifying them.
- Make SegmentIndex iterable
- Add specialized seek() and current() methods to SegmentIterator
- Remove position from SegmentReference
- Make positions in SegmentIndex API stable without field in
reference
- Remove brittle hard-coded positions in tests (except SegmentIndex
tests, where they would be hard to avoid in testing methods
separately)
- Use SegmentIterator in StreamingEngine to track the next segment
between switches
Issue #892 (refactor StreamingEngine)
Issue #1339 (period flattening)
Change-Id: I666cc21249c34ee6cbc138a59109d9f1159fa127
This is a step along the way to flattening periods, and also
simplifies a few small things in StreamingEngine and tests.
Issue #1339 (flatten periods)
Issue #892 (refactor StreamingEngine)
Change-Id: Ie17cd5e15ed6ec9290a918c3a69c05c74581e0fc
SegmentReference used to have presentationTimeOffset, which,
subtracted from the period start time, was then _added_ to the
timestamps in the segment by MediaSource.
Now, SegmentReference has a timestampOffset field, which is exactly
what MediaSource's timestampOffset field is set to on the SourceBuffer
before this segment is appended. For DASH, this is periodStart minus
presentationTimeOffset.
This also adds append window start & end times to the
SegmentReference. Now segments can be appended to SourceBuffers
without reference to the period.
Note that start & end times of the SegmentReference in each segment
index are still relative to the period. This will change in a
follow-up.
Issue #1339 (flatten periods)
Issue #892 (refactor StreamingEngine)
Change-Id: I9d54eb2b529ec643c9475b8e9d218c3e2e826a26
To prepare for flattening out the manifest structure to remove
periods, this change moves initSegmentReference and
presentationTimeOffset fields into the SegmentReference object. This
way, the segments on either side of a period transition or HLS
discontinuity can have different offsets or init segments, eventually
allowing us to create a single array of SegmentReferences for
multi-period content.
Issue #1339
Change-Id: Ic7eff0483789644881247ecf8044c5fb6a48f0e6
This replaces find/get callbacks in Stream with a SegmentIndex. With
the exception of DASH's SegmentTemplate+duration, all manifests were
already backed by SegmentIndex. Now, all manifests are backed by
SegmentIndex. This will simplify Period-flattening, in which all
tracks will be represented by a list of segments, some of which come
from different Periods.
The SegmentIndex in Stream will not be created until
createSegmentIndex is called. Prior to this change, the find/get
callbacks could be invoked without createSegmentIndex() in some cases
(excluding DASH's SegmentBase), which some lazy tests took advantage
of. Now that find/get are methods on SegmentIndex, createSegmentIndex
must be called in all cases. The tests have been updated accordingly.
Making SegmentIndex generation async in all cases exposed some issues
with the parser context being modified in-place between one
Representation and the next. So the parser now makes a shallow copy
of the context before it is bound into an async callback.
To facilitate updating the SegmentIndex for SegmentTemplate+duration
content, SegmentIndex now has a method to update its list on a timer.
Once per segment duration, the index will be updated to add and remove
SegmentReferences.
The initial expansion of SegmentTemplate+duration will be limited to a
relatively small number of segments, to avoid excessive CPU or memory
consumption. This defaults to 1000 segments, but is configurable.
Issue #1339
Change-Id: I99c007b1096c3b396d04a729750cd7b743cb899d
According to @beaufortfrancois, we should no longer be using protocol-
relative URIs. He quotes this passage from Paul Irish:
> Now that SSL is encouraged for everyone and doesn’t have performance
> concerns, this technique is now an anti-pattern. If the asset you
> need is available on SSL, then always use the https:// asset.
> Allowing the snippet to request over HTTP opens the door for attacks
> like the recent Github Man-on-the-side attack. It’s always safe to
> request HTTPS assets even if your site is on HTTP, however the
> reverse is not true.
Source: https://www.paulirish.com/2010/the-protocol-relative-url/
This change was begun with the following command:
git grep -l "'//" | xargs sed -i "s@'//@'https://@g"
Some changes made by that command were false-positives, which I then
reverted manually. Others required additional cleanup to meet style
rules.
I've also just discovered that the "max-len" rule in eslint's Google
style config exempts URIs, so there's no need to disable the max-len
rule on URIs in the assets list. These have been removed in the asset
list where unnecessary.
Finally, testing these updated URIs led to the discovery that two of
our third-party demo assets are no longer available. One URI needed
to be updated. The other had no obvious replacement, so it was
removed.
Closes#1390
Change-Id: I2fe23faec04f1904c1741236b364d5089900092a
This uses AbortableOperation in all networking, from the scheme
plugins all the way to the request interface.
This also updates all default scheme plugins, docs, and sample code.
Backward compatibility is provided for scheme plugins and the
request API in NetworkingEngine. This compatibility will be
removed in v2.5.
Two cancelation-related tests have been disabled in
player_integration until the new abort interface has been adopted
in the manifest parsers.
Issue #829
Change-Id: I91c8e6efe97798d111e8ddca5655cddc1f6bcbf3
This reverts commit 478fb1a473
("Detect and attempt to correct timeline sync issues") and commit
4334b6ea90 ("Add mediaSegmentReferences
to shakaExtern.Stream").
Timeline correction only addresses one class of broken live content,
while actually making it more difficult to diagnose other classes of
broken live content.
Issue #933
Change-Id: Ie71b8a45600ed0994626f53268fb90e336c3c62b
This will allow us, in many cases, to detect time sync issues in
content by comparing the media segment references to the presentation
timeline. If the references are outside the timeline, it may indicate
a common form of bad content, and we may be able to attempt to correct
it.
In some cases, the references are not available upfront. We can't
detect time sync issues in DASH with SegmentTemplate+duration, because
the references are not explicitly described by the manifest. We can't
detect time sync issues in DASH with SegmentBase, because the segment
index requires additional fetching and parsing. (SegmentBase is not
used with live content, so this should be a non-issue.)
This only introduces the new data, but does not use it for detection
or correction yet.
Issue #933
Change-Id: If70b1bdbd3b08a7c8b7ae296da209737492dfe17
Álvaro Velad Galván
ismena
Joey Parrish
Theodore Abshire
태재영
mohrash92
Jacob Trimble