This change fixes tests on Chromecast by loading tests later in the process. Test scripts are now dynamically inserted by boot.js, rather than loaded by Karma. The bootstrapping code then awaits the completion of that before starting the Karma frameworks (Jasmine) to run the tests.
This also removes the use of goog.provide/goog.require in tests and test utils. We don't need to load test utils or library sources dynamically in each test, and this gives us more explicit control over script loading and ordering.
Closes#4094
This corrects/normalizes license headers in misc. files, such as
config files, docs, build tools, tests, and externs. This does not
affect the compiled output, and is only done for consistency.
Issue #2638
Change-Id: I9d8da2de55243b08d7df2b743aac73c6f15e858a
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
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
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
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
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
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
Joey Parrish
michellezhuo
Joey Parrish