According to @beaufortfrancois, we should no longer be using protocol-
relative URIs. He quotes this passage from Paul Irish:
> Now that SSL is encouraged for everyone and doesn’t have performance
> concerns, this technique is now an anti-pattern. If the asset you
> need is available on SSL, then always use the https:// asset.
> Allowing the snippet to request over HTTP opens the door for attacks
> like the recent Github Man-on-the-side attack. It’s always safe to
> request HTTPS assets even if your site is on HTTP, however the
> reverse is not true.
Source: https://www.paulirish.com/2010/the-protocol-relative-url/
This change was begun with the following command:
git grep -l "'//" | xargs sed -i "s@'//@'https://@g"
Some changes made by that command were false-positives, which I then
reverted manually. Others required additional cleanup to meet style
rules.
I've also just discovered that the "max-len" rule in eslint's Google
style config exempts URIs, so there's no need to disable the max-len
rule on URIs in the assets list. These have been removed in the asset
list where unnecessary.
Finally, testing these updated URIs led to the discovery that two of
our third-party demo assets are no longer available. One URI needed
to be updated. The other had no obvious replacement, so it was
removed.
Closes#1390
Change-Id: I2fe23faec04f1904c1741236b364d5089900092a
This uses AbortableOperation in all networking, from the scheme
plugins all the way to the request interface.
This also updates all default scheme plugins, docs, and sample code.
Backward compatibility is provided for scheme plugins and the
request API in NetworkingEngine. This compatibility will be
removed in v2.5.
Two cancelation-related tests have been disabled in
player_integration until the new abort interface has been adopted
in the manifest parsers.
Issue #829
Change-Id: I91c8e6efe97798d111e8ddca5655cddc1f6bcbf3
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