This is a helper to aid in iterating over items. This returns a list
of objects that contain:
- "item": The current value.
- "prev": The previous value in the list.
- "next": The next value in the list.
- "i": The zero-based index in the list.
Issue #1518
Change-Id: Id18ab977e3ae45dfbfd2b4137a1bffb6e53c6bce
This is a fully automated change. The linter will fail because the
extra indentation caused line-length errors. These won't be fixed
automatically. They are fixed in a follow-up to make this one fully
automated.
Change-Id: I4d8cf9c998985add2bcd24a81c8d65495668c4f3
With the new style rule, we cannot have two statements on the same line.
So we can no longer have an "if" on a single line and we cannot have
an arrow function with a body on the same line as when it is used.
This is mostly a manual change.
Change-Id: I2285202dd5ecbad764308bc725e6d317ff2ee7f0
This is an automated change to convert use of "function" functions
to arrow functions. This doesn't change all uses of bind() that
could be converted. This also doesn't remove all "function" functions.
Change-Id: I40ac7d086bcef947a1be083359c8fd1d4499a9c3
A coming update to the Google eslint config will require using "const"
over "let". This makes that one change to isolate the big changes.
Change-Id: I7d0974c3ae15c53cc45a6b07bf9f6586e2d34aca
Before, segment timestamps were used in PresentationTimeline without
regard for the period start. This means they were not truly relative
to the presentation, but to the period.
The "isFirstPeriod" argument was also broken. It was meant to be true
for segments from the first period *ever*, but was passed true for the
first period *in the latest manifest update*. So data calculated from
that was bogus for live streams.
Now, notifySegments() is supplied with a period start time, so that
segment references can be combined with the period start to give
presentation timestamps. This fixes a major issue with the original
fix for #999.
Closes#999
Change-Id: Id0fe450f3ce4f90a2387d7103c75eb88f0c69c72
When we try to merge two SegmentIndex objects, we check to make sure
that they are sequential. Then, after merging the various SegmentIndexes,
they are fit.
This causes problems when trying to merge two identical periods together,
an operation that could potentially happen in a live stream.
SegmentIndex.merge was comparing the post-fit version of one SegmentIndex
with the pre-fit version of another, causing it to believe that the two
SegmentIndex had different end times when really they were identical.
This change causes SegmentTemplate.createStream to perform an extra fit
operation before merging, to avoid that problem.
Closes#1448
Change-Id: If2e9a9a91de344b7ab8cd9004da0553b324cb599
Google style guide requires adding curly braces to all block statements
even if it is only has one line. This fixes it by using eslint's
--fix flag followed by running clang-format to reformat the change.
Change-Id: Idc086c2aa8c02df5ef8b2140a11bfb9128eeb4bd
Rather than using the availability window, Playhead should use the
seek range to restrict the playhead's position.
Closes#1224
Change-Id: I8612bfafb53bbb214e32aae2d71af52d748a3aee
This is part of a change to convert all usages of 'var' with either
'let' or 'const'. This takes a conservative approach for 'const' where
it will only be used for aliases and storing the "original" values in
tests.
Change-Id: Iebba756b5d0e68c41292ecabda89503682d8d434
We incorrectly added the presentationTimeOffset to the segment times as
a fix for #1164. The correct fix is to use the include the PTO in the
time structure passed to the text parsers. This is a partial revert
of 207505.
Issue #1164Closes#1232
Change-Id: I1f2805e0dbdc44be71e2160b3d37a73732c97a4f
When calculating segment references, the end time should be capped at
the period's end, except when the period has no end.
Closes#1204
Change-Id: Ia608452706bbc3fd847a645197e8a0cb57d7aaec
We were not previously applying presentationTimeOffset in
SegmentTemplate w/ the duration attribute. This fixes the DASH parser
to correctly apply the offset in this case.
This also fixes an issue in which segment times could stretch past the
end of the period or even past the end of the presentation, causing
StreamingEngine to fail period transitions afterward.
Closes#1164Closes#1163 (PR to address 1164)
Change-Id: Ib16fc2b65117557a4ad9a05adc4a07f8bc90fd3c
In DASH SegmentBase, we were not dividing presentationTimeOffset by
the timescale. In all other instances of presentationTimeOffset in
DASH, we were handling it correctly.
This bug was present in all v2 releases until now.
The solution is not only to divide by timescale, but to rename all
internal uses of presentationTimeOffset to either unscaled or scaled,
to differentiate between those in timescale units and those in
seconds. I believe inconsistent naming and units were a contributing
factor to the creation of the bug.
Closes#1099
Change-Id: Id561f8eb1f5bc011c606e1925c12f0d8183fd51a
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
The bulk of the logic for gap jumping is handled in Playhead. It
tracks the current buffered ranges and jumps over any gaps that appear.
It listens for a special browser event ('waiting') for when the video
element runs out of playable frames.
This change also removes the logic for jumping gaps at the beginning
of the timeline. This is handled by the more general gap jumping
logic and works cross-browser.
Finally, this updates the buffering logic to only count the amount of
content buffered (i.e. ignoring the gaps). This fixes some bugs where
gaps in the content can result in StreamingEngine buffering forever
since it thinks only a little is buffered.
This includes full implementation of the logic, but this doesn't close
the issue since there aren't any integration tests yet. Those will
be added next.
Issue #555
Change-Id: Id99eb9fe469e8cf2c7464a3d70c3733791e806e0
This adds a severity field to Error objects. This can be used to
detect whether an error is recoverable. All the same errors are still
reported so the field can be ignored.
There are two possible values:
* RECOVERABLE means that the Player will try to recover from the error
* CRITICAL means the Player will be unable to continue and must call
load() again
Closes#564
Change-Id: Ie2c5468340c13e7a288b99690ab65b7ecc0a6b29
This fixes an infinite loop when storing SegmentTemplate-based VOD
content. In shaka.offline.Storage.prototype.createStream_, we loop
over all segment references to feed the download manager. Those
references should stop at the period duration.
Closes#739
Change-Id: Ia16e89968b3bd8fc554b71ac857f8d9ae890cde1
We usually fit segment references to the Period for VOD content. This
ensures that a gap in the manifest at the end of the Period doesn't
cause problems. We don't do this for live because we may get more
segments. However, for multi-Period live, we should still fit the
references for all Periods except the last one.
This also removes the error about duplicate Representation IDs for
VOD content since the problem only occurs for live.
Issue #694
b/35849085
Change-Id: Ib195dc51982ca58b8d5613b37817216980b8d366
Fix incorrect timeReplacement when large timescale
The current code essentially does this
timeReplacement =
(startTime / timescale + presentationTimeOffset) * timescale
When timescale is large enough (e.g. 10 MHz in order to support MS
Smooth Streaming as well), "startTime / timescale * timescale" may not
always be exactly "startTime" because of floating point precision,
which could produce incorrect segment URLs.
Keep startTime and presentationTimeOffset unchanged in the timeline
just to avoid the multiply/divide dance.
Closes#690
Both DASH and HLS parsers will be using resolveUris() and possibly
other methods in the future.
Create a ManifestParserUtil for the shared methods.
Issue #279.
Change-Id: Iaa5e32ec543a390341a54752563a9f27251f0832
Behavior for IPR streams:
* offline storage disallowed
* segment references will not be stretched to the period
* seek range starts at 0
* seek range end is calculated like the live edge
* seek bar is from 0 to duration, not the seek range
Closes#477
Change-Id: Ia36874bb7208c2473c79cb817395ce03925b8c95
presentationTimeline.getSegmentAvailabilityStart() yields a start time
relative to the AST, but all of the reference start/end times are relative
to their PTO. We need to normalize the start time to the period before
we evict any segments.
These patches and IPR support in general will be revisited when we
have a better model for how this should work.
Closes#463
Change-Id: I2c5fe372986a9af232b052c67f8e5c3ba6585cee
Instead of filling the URI templates when parsing the manifest,
wait until the request is made to fill it. This reduces the time
it takes to parse the manifest.
This was tested using a stream with a 24-hour timeShiftBufferDepth.
Using a Chromebook pixel running Chrome 51. The average manifest
parse time was about 1 second before, now it is about 200ms.
Issue #405
Change-Id: I89f36085441f6c6b7d6281b24b671dc668f23fe5
* Permit non-zero presentation start times for VOD: some
presentations have segments which start too far from 0 to
allow the video element to begin playback; now the player will
start VOD presentations from the start of the first segment.
However, segments of the 2nd, 3rd, 4th, etc., Period of a
multi-Period presentation must still start close to 0 (the
player will not jump any gaps in the presentation).
* Prohibit seeking to regions at the beginning of the segment
availability window if segment information is missing from
that region: sometimes live manifests do not contain all the
segments in the segment availability window; now the player
will prohibit seeking to these regions.
* Update definition of live in DashParser to match Player and
Playhead.
* Simplify PresentationTimeline's constructor by just using setter
functions.
Issue #341Closes#348
Issue #357
Change-Id: I96c22774448476bea89ff4014f03b87bdb51ba07
Without @namespace annotations, static classes do not show up in the
generated API docs. Although I stumbled over one instance while
writing tutorials, the rest were discovered programmatically by:
for x in $(find lib/ -name '*.js'); do
grep -Eq '@(constructor|interface|namespace)' $x || echo $x
done
Change-Id: I97dd2bb4bf3faad5ac8d952a28837fa1f594deb9
The live-edge calculation in PresentationTimeline needs to take into
account the duration of the current segment since the current segment
is not available until it has ended.
To do this we use MPD@maxSegmentDuration when available, and compute our
own maxSegmentDuration when it's not (as specified by the DASH spec).
Change-Id: Ic5b8478dbbff8eac93cf123a00a8b02db140cf15
When updating a DASH manifest, we can key off of Period and
Representation only. The spec says that Representation IDs are unique
within the Period, and that Period IDs are unique within the
presentation. Therefore we do not need an AdaptationSet ID to merge
on update.
Relates to #310
Change-Id: I12b9f83c2bfda958a14e9ee31d459c04da8722e6
This ensures that small gaps from the start of the Period or from the
end of the Period are not interpreted as missing SegmentReferences.
Change-Id: I7492faef8e44067494e3daf3ff73742fa914d1e3
Our new interpretation of whether a stream is live is if there is
no duration. This removes the old check for type='dynamic' from
the Dash parser.
Change-Id: I58aa1a785c7e949be7b48ab5b3b409cbf8e828a6
Using goog.asserts will work with the compiler. So rather than
simply casting a nullable value when passing to a method, we can use
an assert which will correct the type and print a log if it somehow
is null.
This is not the same goog.asserts found in closure library, this
simply calls console.assert, but it is not required to do anything
for the compiler help.
Change-Id: I2548e39e772f0aa7ec41437cf9f5a2be383e0fbd
Fixes the following issues:
=====
lib/player.js:106: ERROR - Property id never defined on TextTrack
lib/util/xml_utils.js:42: ERROR - inconsistent return type
found : (Node|null)
required: (Element|null)
lib/dash/content_protection.js:256: ERROR - Parameter must have JSDoc.
function(element) {
lib/dash/content_protection.js:284: ERROR - Parameter must have JSDoc.
function(elem) {
lib/media/drm_engine.js:47: ERROR - Private property configuration_ is never read
lib/polyfill/patchedmediakeys_20140218.js:269: ERROR - Private property keySystem_ is never read
lib/polyfill/patchedmediakeys_20140218.js:389: ERROR - Private property type_ is never read
lib/util/language_utils.js:84: ERROR - The value 0.0 is duplicated in this enum.
MIN: 0, MAX: 2
lib/util/language_utils.js:84: ERROR - The value 2.0 is duplicated in this enum.
MIN: 0, MAX: 2
demo/assets.js:171: ERROR - Value assigned to local variable headers is never read
lib/dash/content_protection.js:188: ERROR - Value assigned to local variable repUnknown is never read
lib/dash/dash_parser.js:400: ERROR - Value assigned to local variable suggestedDelay is never read
lib/dash/segment_base.js:41: ERROR - Value assigned to local variable SegmentBase is never read
lib/dash/segment_template.js:291: ERROR - Value assigned to local variable periodStart is never read
lib/media/drm_engine.js:172: ERROR - Value assigned to local variable onEncrypted is never read
test/dash_parser_live_unit.js:358: ERROR - Value assigned to local variable manifest is never read
test/drm_engine_unit.js:383: ERROR - Value assigned to local variable cert1 is never read
test/drm_engine_unit.js:384: ERROR - Value assigned to local variable cert2 is never read
test/media_source_engine_unit.js:24: ERROR - Value assigned to local variable dummyData is never read
test/media_source_engine_unit.js:504: ERROR - Value assigned to local variable p2 is never read
test/media_source_engine_unit.js:505: ERROR - Value assigned to local variable p3 is never read
test/media_source_engine_unit.js:506: ERROR - Value assigned to local variable p4 is never read
test/media_source_engine_unit.js:535: ERROR - Value assigned to local variable p2 is never read
test/media_source_engine_unit.js:601: ERROR - Value assigned to local variable p2 is never read
test/media_source_engine_unit.js:602: ERROR - Value assigned to local variable p3 is never read
test/media_source_engine_unit.js:603: ERROR - Value assigned to local variable p4 is never read
test/media_source_engine_unit.js:632: ERROR - Value assigned to local variable p2 is never read
test/mpd_utils_unit.js:20: ERROR - Value assigned to local variable HUGE_NUMBER_STRING is never read
test/streaming_engine_integration.js:55: ERROR - Value assigned to local variable onSeek is never read
test/streaming_engine_unit.js:1263: ERROR - Value assigned to local variable reportedContentType is never read
test/streaming_engine_unit.js:1264: ERROR - Value assigned to local variable reportedPeriodIndex is never read
test/streaming_engine_unit.js:1540: ERROR - Value assigned to local variable size is never read
test/util/dash_parser_util.js:77: ERROR - Value assigned to local variable retry is never read
test/util/dash_parser_util.js💯 ERROR - Value assigned to local variable retry is never read
test/vtt_text_parser_unit.js:272: ERROR - Value assigned to local variable result is never read
Change-Id: I707700250541e04ccbfe81d7298b3f0c5a82dcdc
The use of strings as indexers in the DASH manifest parser would
not work when the library is compiled. This fixes it as well as
adding type-safety to those parts.
Change-Id: Id07068bc0eefdab4730dadc114e66b661cd4bb3e
This fails on Chrome:
var fn = Promise.resolve;
fn();
But this does not:
var fn = Promise.resolve.bind(Promise);
fn();
It seems that the native implementation of function "Promise.resolve"
needs the context of "Promise" as "this" to execute.
Change-Id: I4e06e6a85f966ef0af2f630da50cbfc60f12ed50
Jacob Trimble
Sandra Lokshina
Joey Parrish
Theodore Abshire
Torbjörn Einarsson
baconz
Seth Madison
Andy Hochhaus
Timothy Drews
Costel G
Costel Madalin Grecu