When we changed the constructors for the V2 cells with the
introduction of V5 format, these call sites didn't get updated. This
doesn't seem to be a user-facing bug, and did not affect any releases.
This was caught by a compiler upgrade.
Issue #2528
Change-Id: I77228d17631ef44a6b85a81b88054790461617bc
This is only defined on Stream, not Variant. This bug has was
introduced in PR #2332 and the v2.5.8 release and affects v2.5.8 -
v2.5.10. The corresponding feature (frameRate restrictions) has
actually never worked.
This was caught by a compiler upgrade which is still in progress.
Change-Id: I0409d9be8d3f6eb0794775ca29f28b98208bab4f
This method (shaka.util.Uint8ArrayUtils.equal) was removed between
v2.5.0 and v2.6, but could be in use by applications. This change
adds the utility method back, with a deprecation warning.
Change-Id: Ifd780759ae389e766c1889a83545cfda8969e76b
These exports are not needed by the application. Some of them may
have been added to work around the extern generator's lack of support
for partially-exported classes.
Change-Id: Iaf142397f31bd927bf942499a79da595f77361d5
In v2.5, we had some classes which were not exported, but which had
certain individual methods which were exported. This is still true in
v2.6, except that we're using ES6 classes everywhere instead of mostly
using .prototype.
The extern generator had support for exporting individual .prototype
methods, but not for exporting individual class methods (unless the
class itself was exported already).
This adds support in the extern generator for these "partially
exported" classes, to correct missing externs in preparation for the
v2.6 launch.
Change-Id: I17ef377980ce771d74fab78afe26aa36ba3cce90
For webOS TV 2020 platform, like for Tizen, key IDs should not be
transformed to big-endian UUIDs, it causes `4012
RESTRICTIONS_CANNOT_BE_MET` error.
Closes#2512
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
The parameters for prototype methods and other function expressions
was already correct, but there was a lack of spaces between parameters
in class methods.
Change-Id: I3b77a36efc91d8a3648bf45da0f9b155d78e5da5
The setClickElement() method we've been using for this is
getting deprecated, and IMA recommends setting this through
the constuctor instead.
Change-Id: I7dd5c5e2644e2b270996be7fe2b1390e41009505
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
We were leaking one PlayRateController instance per playback, with
each one running an infinite repeating timer that fired every 250 ms.
In a single run of our tests, this bug fix gets triggered 116 times.
That means we had, by the end of a test run, 116 timers with callbacks
every 250 ms. Each would have to complete in 2.1 ms to avoid bogging
down the browser's JavaScript thread.
This bug could have had a significant performance impact in the field,
depending on usage patterns, and was part of v2.5.0 - v2.5.10.
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 hit the "pause" button in the JS debugger, and found that
this periodic timer was still running.
After the fix, pausing after the test run is complete does nothing.
There is no JavaScript executing beyond the end of the tests.
Change-Id: I87b402e733b1ccaa5e696d52d31cfe00ef12cfe0
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
The Cast receiver does not ever change the controls between our UI and
the native controls, but the demo app does. So in the demo app, we
never noticed that they do not seem to show up by default any more.
This fixes the UI library to show its own control by default, which in
turn fixes the Cast receiver app and any other app which did not use
setEnabledShakaControls().
Change-Id: I7889f1a7ec612bc7a260f5433316104d64ad4a26
This has not had an impact yet because we do not yet make use of the
encryption scheme queries that the polyfill provides. But this
polyfill has been missing from the Cast receiver in all v2.5.x
releases since it was introduced.
The omission was first noticed when loading the Cast receiver in a
debugger in desktop Chrome. This wouldn't normally be an issue with
most polyfills, but this one is outside of the Closure deps system.
Change-Id: I53685f5efe5555979993bf692d8a7cae31305ea9
This gets us a fix for a closed caption parsing issue described in
videojs/mux.js#330 and fixed in videojs/mux.js#333:
> Atypical streams containing 2+ SEI NAL payloads of type 0x04
> (CEA-708 caption content) in the sei_rbsp (specifically a DTG1
> payload preceding a GA94 payload) fail to display captions in this
> scenario, as the current logic results in parseSei() prematurely
> returning with the DTG1 payload.
>
> By checking for the user ID within parseSei, mux.js can continue
> iterating through the sei_rbsp for the GA94 payload.
Change-Id: I9d90419643279a1273187e0354b5e991cd609ba2
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 whatever reason, on iOS Safari, the 'loadeddata' and
'loadedmetadata' events don't fire until the video actually starts
to play. That is to say, until the play button is pressed or the load
method is called (or the video is set to autoplay).
This changes the src= playback to call video.load.
Closes#2483
Change-Id: I49eb119a01d88073532496b5af062bbbcfcfa9fa
When set the configuration to true, using keyboard to control playback
will be enabled, such as seek forward/backward, jump to the
beginning/end, play/pause by press the space key, etc.
Closes#2489
Change-Id: I0e46bd5853d47855aae6e6dedcc7de8798bf4298
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
This exception was thrown when we attempted to set up a
SegmentIterator on CEA tracks. Because they do not have their own
segments, this is not possible. The fix is to exclude CEA tracks from
this step.
Discovered while debugging #2395, but seems to be unrelated.
This bug does not affect any release versions.
Change-Id: I534b19139d88cc7ad2d6167611c04f400308a71b
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
Joey Parrish
michellezhuo
Álvaro Velad Galván
Dong-heun
Theodore Abshire
Sandra Lokshina
kumarashu123