You can either abort downloads one at a time, using the
AbortableOperation interface, or you can implicitly abort them all at
once by destroying the storage instance.
Closes#2417Closes#1362
Issue #1301
Change-Id: I0ba102e5bf60a063f0e2f6ecd3f135445226996f
This partially reverts commit ad3d4604, because that fix seems to have
caused #2523.
This also adds a regression test for #2523.
Reopens#2516Closes#2523
Change-Id: If3ed5942fff029f522e24048edcb4a04e7cc30e9
According to the agreement with the IMA team, we will
no longer hide their UI during ads. Instead we will
incorporate their elements into our layout.
(Some of the elements they expose are legally required
or business critical for partners for certain types of
ads).
This change replaces our skip button with the IMA one
and tweaks our layout to make it fit better.
We are keeping our ad counter and the 'Ad X of Y'
element.
Our skip button will stay in the library, and we will
use it for other (non IMA) ad integrations.
Change-Id: I648c6c65a34607685a409a264c2a03d74cc4d461
Some tests in test/offline/storage_integration.js would manipulate
StorageMuxer to test what happens when storage is unsupported. The
support was overridden in beforeEach and restored in afterEach.
However, all of this was wrapped in filterDescribe, which shims
jasmine's methods to run support checks and abort those methods if the
support check fails. This meant that the test itself could be skipped
by filterShim onec beforeEach ran. In fact, the shim would check for
support again before running afterEach. So the cleanup in afterEach
was also skipped, leading to all future offline tests being skipped.
This, combined with the recently-fixed test bug where tests would run
in a random order, meant that in some cases, none of the storage tests
were actually running.
With the random ordering bug fixed, we were still skipping 25 tests on
the Linux version of Chrome, 19 of which were storage tests that
shouldn't have been skipped. With --random, we were sometimes
skipping 30-45 tests in the same environment. With the fix, we are
always skipping exactly 6, 3 of which are disabled for everyone and 3
of which require Widevine persistent licenses not currently available
on Linux.
Change-Id: I22f76d47b89ce52997278f5fe402af056c89f4c0
When running tests with --random --seed, the test order should be
stable. However, xfilterDescribe (the version of filterDescribe which
temporarily disables tests) was not actually defining the tests
inside, which led to a change in the order of the tests run.
This makes xfilterDescribe define the tests, but disable them all,
which makes the shuffled order with --seed stable again.
Change-Id: I382f1f719a5b9f846bcb23761cc63f96abf17759
When the non-UI TextDisplayer is constructed, it creates an extra
TextTrack that can never be removed. This leads to a bogus text track
showing up in the UI when content is played in src= mode.
This changes the TextDisplayer to disable the extra TextTrack (since
there is no API to remove it) and changes the Player to ignore
disabled TextTracks when generating a track list for src= playbacks.
Closes#2516
Change-Id: I2e651f737445049da5fa46a798a2bc0751de2822
The test was blocking a network request, then letting it continue.
However, another change that landed around the same time introduced a
request cache inside Storage. So the blocked request was cached and
shared between the test's two storage operations, leading to both
operations being blocked.
This was missed because the test order was accidentally randomized,
leading to an as-yet-unfound bug that caused this buggy storage test
to get skipped in some cases, and timeout or disconnect in others.
Fixed: 154522761
Change-Id: I657b0d4d4edb5142bd159f567e7bd2a80e1687f2
Jasmine 3+ defaults to random test order. Since we own our own boot
file, we have to explicitly disable this if we want a predictable
order. The unpredictable order has been uncovering some instability
and possible pollution between test suites lately, but before we can
address that, we need to stabilize our nightly test runs. Then, when
hunting down these instabilities, we can explicitly use --random and
log the seed we used to get consistent failures once the failure is
identified.
This behavior was introduced to Jasmine in
https://github.com/jasmine/jasmine/commit/e31db20e and we unknowingly
adopted it in Shaka Player in
https://github.com/google/shaka-player/commit/b042a819 .
Bug: 154522761
Change-Id: I1b8b7b7f4e3d64746d61f019b1bd1d928d489f1b
When the Cast receiver throws an Error or rejects a Promise with a
non-Shaka Error, we need to represent it to the sender in a reasonable
way. Otherwise, it can be very difficult to debug.
Related to the investigation of #2487
Change-Id: Ia58dd1e1e56ee93bea9afc9d368084d53c381db3
These tests added a container to the DOM which was never cleaned up.
There is no impact to Shaka Player, and no performance impact to the
tests, but we should clean up after ourselves.
I found this by running the Karma/Jasmine tests in a foreground
browser tab at http://localhost:9876/debug.html . After the tests
completed, I looked at the "Elements" panel in Chrome's dev tools.
Change-Id: Id81dddcb82b01eeb6445ddd701d2d3907c322a0d
In Change-Id If885e828b4761528e40abdbc601a11cf13849a1e, I fixed a
memory leak, but broke offline storage.
In Change-Id I88b86d250b4407cc0740d35eaf4a7ef3d5a67798, I fixed some
of the test failures, but not others. The tests passed on Chrome on
Linux, but later failed on other platforms. It is not clear why they
passed some of the time.
When I changed offline storage to keep the parser alive until after
the storage operation is complete, this broke some test assumptions.
For example, the tests assumed that overriding manifest parsing would
be sufficient to make the URI irrelevant. That is not true any more,
since the parser is created earlier in the process.
This changes the Storage integration tests to always invoke the fake
parser by using its registered MIME type, rather than relying on an
override of the parsing step.
The Storage integration tests are now passing on all supported
platforms.
Change-Id: I1ec0b186516d35156c761554ec2e610f784e254d
When a mobile device goes idle, the Cast connection can be terminated
without explicitly closing it. When this happens, the Cast session is
unusable and throws exceptions.
This changes CastSender to correctly detect and recover from such a
problem by disconnecting explicitly and dispatching an Error to the
application.
This also fixes the disconnection process so that playback can be
correctly resumed on the local device.
Closes#2446
Change-Id: I59f51a1e911199eee22693e7db4ab39855de0298
For some reason, on Edge and IE, starting this particular piece of
content at time 5 results in playback beginning at 4.9. It could be
that the number is rounded to a keyframe or something.
This changes the test to expect the start time to be within 200ms of
the requested start time.
Change-Id: I5399a1eaf8a84b57a88359db2584f043e4a11e81
In the process, this removes the in-progress flag, which should fix
issues where the storage instance can't be re-used after an error.
Closes#1432Closes#2432
Change-Id: I51018e170fb9ab262b5c70125a03d979c8ccfb08
In Change-Id If885e828b4761528e40abdbc601a11cf13849a1e, I fixed a
memory leak, but broke offline storage.
The fix for the memory leak was to release SegmentIndexes and
SegmentReferences when the DASH parser stops, but offline storage was
stopping the parser before making use of the parsed manifest.
This changes offline storage to keep the parser alive until after the
storage operation is complete.
This bug did not affect any release versions.
Change-Id: I88b86d250b4407cc0740d35eaf4a7ef3d5a67798
This creates a new utility used by DashParser and old offline DB
formats to combine Streams across Periods. This allows multi-Period
DASH content to be played without period-specific structures in the
manifest format, StreamingEngine, or Player. This also makes the
Tracks stable across Periods.
Closes#1339 (flatten periods)
Closes#1698 (rapid period transitions issue)
Closes#856 (audio change causes bitrate change)
Change-Id: Icb04c8e47e36eacf7ac024a5063130d85a115e54
In these tests, SegmentBase referred to init segments that did not
exist. In period-flattening, we will be fetching segment indexes in
advance during parsing, so these bogus init segments would be fetched
and cause an exception. Using SegmentTemplate avoids this for tests
are not concerned with SegmentBase specifically.
Issue #1339
Change-Id: I54990e95480dfbb59154fca72f12d277eca25701
When period-flattening combines Streams, key ID arrays would get very
long with duplicates.
This changes keyIds in the manifest and offline structures from Array
to Set.
Issue #1339
Change-Id: I003d23e567efafa771ecd2ad597900181604ad18
This brings the field name in line with the Stream objects from the
manifest types, allowing for more general processing of Stream and
StreamDB for period-flattening.
Issue #1339
Change-Id: Ic5d0e5d69a6560d475a19f5d3ecb0b1b40b8d271
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
Something weird happens on some platforms (variously Chromecast, IE,
legacy Edge, and Safari) where the playhead can go past duration. To
cope with this, don't fail on timeout. If the video never got flagged
as "ended", check for the playhead to be near or past the end.
Also, wait for playback to begin before increasing the playback rate.
This improves test reliability on slow platforms like Chromecast.
Change-Id: If7d70de95b75e602853ec77ad1c285c118875db4
This removes periods from the internal manifest structure and cleans
up code and tests accordingly. This leaves us unable to play
multi-period DASH & offline streams until the main period-flattening
algorithm is completed in shaka.util.Periods.
Three test cases have been disabled for the moment.
Multi-period playback will be restored in a smaller, more focused
follow-up commit, with disabled tests re-enabled.
Issue #1339 (flatten periods)
Issue #1698 (rapid period transitions issue)
Issue #856 (audio change causes bitrate change)
Closes#892 (refactor StreamingEngine)
Change-Id: I0cbf3b56bfdb51add15229df323b902f0b2e643a
mediaElement.buffered can never be null. If nothing is buffered,
buffered.length will be 0.
The bug has been in this file since it was created in January 2019.
This affects all v2.5.x releases up to v2.5.10.
Hopefully this will address some seeking issues on Chromecast, though
that has not yet been confirmed.
Closes#1809
Change-Id: Iccc49d299cdac9fccdafdfc2d35e5b2376cff644
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
michellezhuo
Theodore Abshire
Álvaro Velad Galván
Joey Parrish
Sandra Lokshina
Jacob Trimble