The Player ratechange event is a filtered version of the video
ratechange event. This is necessary because we manipulate
playbackRate as part of our buffering state management.
The UI uses this Player ratechange event to drive the playback rate UI
menu, but the event was not firing for src= playbacks (native HLS or
plain MP4s).
This fixes the ratechange event for src= playbacks, and also fixes a
small mistake in the MediaSource setup that could have resulted in the
ratechange event being triggered before playRateController_ was
created.
Closes#2488
Change-Id: If85e489d681cfbb1ae6141b490d82264e1d932bd
After evicting segments from a SegmentIndex, SegmentIterator should no
longer start at 0. So instead of starting at 0, start at the earliest
position, which is returned by find(0).
Change-Id: I512ffb10a7f09f52930c5afbd783db063e9ebd66
A regex in the TTML parser was looking for "word" characters (\w),
which is short-hand for non-whitespace ASCII characters, and excludes
Unicode characters and symbols from non-English languages.
There is a better option in Regex in some browsers, which is /\p{L}/u.
This is not supported universally yet, and defining an equivalent
regex constant using character codes is over 4kB of extra code.
It seems that the original author of that code meant "word" (\w) in
the sense of "non-whitespace" (\S), so we can just use \S instead.
This change also adds a regression test that doesn't depend on the
specifics of the regular expression used.
Closes#2478
Change-Id: I794258a797ba5d26a7bd8fc0a5244adc70c8a1ef
This could help test failures on Windows since the video doesn't start
playing after the 5 seconds. If it fails, we'll also get more
debug information for it.
Bug: 146050219
Change-Id: I1be5156350a591762022664feb05975470bbf92d
SegmentIndex has had a destroy() method for a long time, but it has
never been called. Now that SegmentIndex has a timer which adds new
references for DASH SegmentTemplate live streams, it is more important
than ever to properly stop this active part of SegmentIndex.
This change replaces async destroy() with synchronous release() and
calls it from Player when the manifest is being disposed of. This
will ensure that SegmentIndexes don't grow out of control after
content is unloaded.
This would not have affected v2.5, since we didn't have this
timer-driven growth of DASH SegmentTemplate live streams in that
release branch.
Related to #1339 (fixes issues introduced for period flattening)
Change-Id: I419a06a62eaa507d92132e20d4cc2d6e45c83ff2
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 reverts commit 235e4e11ad.
The effort to remove SegmentReference's position field will be handled
in a different way.
Issue #892 (refactor StreamingEngine)
Issue #1339 (period flattening)
Change-Id: I62b115137abc89f498b30467e574b0401dcad05d
This removes the tests added by #2412 since they didn't test what
was wanted. This also fixes our existing tests to ensure they work
with autoCorrectDrift. Lastly this adds a new test to ensure the
UTCTiming is ignored when autoCorrectDrift is true.
Change-Id: If511fca5d3f360cdf373229961b2a01fdbda31bb
While fixing cherry-picks for v2.5.x, I found that the test for
parsing very large MPDs would fail on that branch because it referred
to segments that do not exist locally. This changes the MPD to refer
to local segments which can be loaded, which is important on v2.5.x
where the load() call can fail if the first segment fails.
This tweak makes the test work universally on both branches.
Change-Id: I97284aa964034bf5768abdb97f06b2a1e371d865
This configuration, which is true by default, lets a user optionally
disable the "go fullscreen on double-click" functionality.
This allows a developer to fully disable fullscreen mode, if they so
wish, or to retain the fullscreen button but disable other methods of
entering fullscreen.
Issue #2459
Change-Id: I196602fc9843e0fd799c78703de60f864e906841
In the code for supportsChunkSize, we test to see if a given chunk
size is supported by array to string conversion by trying to perform an
operation on a Uint8Array of that size without throwing an error.
However, the result of that operation was only ever referenced inside an
assert. Because asserts are compiled out in release builds, the
result of that operation was not being used... and thus, the entire
call was being compiled out.
This changes the return value of the function to use the result of the
operation, thus preventing it from being compiled out.
This also adds a unit test that will detect this problem in the future.
Closes#2433
Change-Id: If3048531afc460beb16de0dda7f7fcbd5499fdaf
As part of Period-flattening, I'm trying to reduce our dependence on
the "position" field of SegmentReference. If it can be eliminated, we
can more easily concatenate Arrays of SegmentReferences without
modifying them.
SegmentIndex can now track the last reference you asked for and
iterate through the list of references. This means we don't need the
"position" field of SegmentReference, which means we don't need to
know positions in advance or globally. StreamingEngine will no longer
use position to request segments.
The old methods find(time):position and get(position):SegmentReference
have been replaced with seek(time), current(), and next(), all of
which return a SegmentReference and maintain an internal pointer to
the "current" reference. Care has been taken to maintain that pointer
during the evict() and fit() operations. Recent changes to merge()
made sure that the pointer does not need to change during that
operation.
All test updates are related to the SegmentIndex API change, not
changing expectations or behavior.
Issue #892 (refactor StreamingEngine)
Issue #1339 (period flattening)
Change-Id: I1682dcc2dd625c6e390711538e46d31e6eb6cea8
As part of Period-flattening, I'm trying to reduce our dependence on
the "position" field of SegmentReference. If it can be eliminated, we
can more easily concatenate Arrays of SegmentReferences without
modifying them.
There has long been a comment at the top of SegmentIndex's merge
method stating that we only ever extend the references, but never
interleave them. The code, however, is structured in such a way that
it could interleave them. This could cause the offset of a given
SegmentReference in the Array to change, which would be counter to the
comment about only ever extending the list.
This change simplifies merge() so that it can only ever extend the
array of SegmentReferences. This will guarantee that their offset
within the Array will not change during the merge operation. This, in
turn, enables further SegmentIndex changes to move "next" segment
tracking out of StreamingEngine (where it is based on the "position"
field of SegmentReference) and into SegmentIndex (where it could be
based on offset into the Array of references).
It removes one test related to PR #838. This test was about our
ability to update the position of the final segment in a list. This
doesn't seem to make a lot of sense, and we're going to stop relying
on segment position anyway.
Issue #1339 (period-flattening)
Change-Id: I2067e2266cf2d02c0e6350d6b57d74f9ed1b27d3
This change creates mocks and fakes for ad testing and adds
tests for the ad container and skip button. Skip button
tests found a bug - this CL also fixes it.
Issue #2367.
Change-Id: I36cb293f9611fbc8592bdc32e156f17a7a78e010
One playlist may contain multiple EXT-X-MAP tags, and each EXT-X-MAP tag
represents the initalization information for the segments after it,
until the next EXT-X-MAP tag or the end of the playlist.
Issue #1335Closes#2397
Change-Id: Ibb0b4f5da6a48f0303d205cb6bd3abad278527fd
These tests failed an assertion because they did not respect the rules
for AbrManager. In compiled mode, this went unnoticed because asserts
are removed in the compiled bundle. But when running tests in
uncompiled mode, these would always fail the assertion and therefore
fail the test.
Change-Id: I44700d118f3f45ebcc955d9306deaca4815b902e
Player.load and Storage.store used to accept the manifest parser factory
directly. But now they should only accept the MIME type string. This
removes the deprecated functionality in preparation for v2.6.
Change-Id: I1b4c5a4a9f0b6edbea909d18111ddc87a39da331
Instead of having the "factories" use "new" to construct them, now they
will be plain functions.
Closes#1521
Change-Id: Ia6151ad679a78a5c6db128d43094c82add0af348
This fixes the argument count on the compiled versions of our default
callbacks. This makes sure we don't issue incorrect warnings about
the application's configured callbacks.
This was discovered in the compiled build of our own demo by observing
the warning logs about the wrong number of arguments in some of our
callbacks.
Change-Id: I401d54bdc706aee9a70fbf5db83fc5e7de5cb183
We fetch the previous segment in Live streams to combat differences
between the manfiest times and the segment times. Now this can be
configured so apps with correct manifests can avoid the extra segment
request.
Also, we'll update the buffering state when a segment appends so we
leave the buffering state sooner.
Issue #2291
Change-Id: Id12c8132dc11739e4c8d42cb1f08e6ae7da1a966
PR #2387 introduced a bug. It awaited the track selection callback,
but that was done in a loop, the results of which were not awaited.
This would cause storage to continue before the complete list of
tracks was available.
Closes#2383
Change-Id: I18a429cf0f40b829020c520c622ffdae8b12622e
This makes the config-rejection logs always-on in compiled mode, to
help application developers notice problems during upgrade.
Found while fixing #2383
Change-Id: I131a1bf8197da394a743e9a121348178d38e5948
The config merging code was rejecting async functions, because the
.constructor field of a function is the "Function" constructor, but
the .constructor field of an async function is the "AsyncFunction"
constructor (not exposed as a global). This led to the async function
being rejected because it was misdetected as a different type of
"object" than the default value.
The fix is to exclude functions from this constructor-based
type-checking.
Note that the compiler will turn async default values into synchronous
functions in the compiled build, so an async default will appear as a
synchronous function in the compiled build and an async function in
the uncompiled demo.
A synchronous function from the app will always be okay, even if the
library expects async, because "await" will still work. But if the
library expects a synchronous function, the app should not supply an
async function, because that will return a Promise instead of the
expected type.
This adds a test to show that it is okay to pass a synchronous
function to an async config field, which is important for backward
compatibility as we make trackSelectionCallback async (#2383).
However, because the compiler causes us to lose the native async-ness
of our default values, we can't reject async for sync fields or write
a test for that scenario.
Found while fixing #2383
Change-Id: I62891441ce75bfc887ea13c24212a2ee78f90af4
These tests were creating two UI instances in the same container. This
caused the second one to replace the first without destroying the first.
This caused test contamination since there could be extra CastProxy
instances. This wouldn't always happen since the no-longer-referenced
objects would be garbage-collected eventually; but depending on timing,
the CastSender tests might fail.
Change-Id: I7f4a008f56224ee33bee15c5e0370a225a5fc033
Since v2.5.0, we have been storing duplicate streams for multi-period
offline content. For example, instead of storing one stream per
period, a 3-period manifest would have 3 streams per period. The
segment data would also be duplicated, leading to 3x the storage used
for a 3-period manifest.
This fixes the error for future content and ensures that the correct
number of variants are still shown when this broken content is loaded.
This change also tweaks the frameRate field in the existing database
dumps, which for some reason contained the wrong value for the
existing v1-v3 dumps. This must have been a bug we fixed already. To
make the expected results consistent across dumps, the frameRate value
in the old dumps has been updated.
Closes#2389
Change-Id: Ibf7db7543f25ad23cecd12efad1eb039630e381c
This adds a test case for all offline database formats to show that
they correctly convert to the current internal manifest format.
Because the database dumps were made with a buggy version of Shaka
Player, the MIME types in the various periods were not consistent.
This corrects the MIME types and codecs in the database dumps to
video/webm and vp9.
Change-Id: I0cf7ddead8352030e87474de6fed15a3ac1bb553
Before this, we only had tests in place for loading and converting the
v1 format for offline storage. We had database dumps already for v2
and v3, but no tests exercising them. This adds some basic tests and
fixes a bug in the loading of expiration times for v2 and v3,
equivalent to what we already had for v1.
Note that here, v1, v2, and v3 do not refer to major versions of Shaka
Player. Instead, they refer to IndexedDB storage formats used in v2.x
versions of Shaka Player.
Change-Id: If32d1f1131b935eb191101463c4152317e711c5c
Since IE 11 only supports this field partially and only with deprecated
css values, do not test it for now. We'll add it back once we end
support for IE 11.
Issue #2339https://buganizer.corp.google.com/issues/146050219
Change-Id: I9458ea830027a312e5237c406de3ed2ecba62918