- Polyfill navigator.languages, which is missing on IE
- Add missing handler for uncaught exceptions (doesn't work on IE,
but is a good idea to have for debugging the demo app)
- Avoid offline setup if it's not supported (as on IE)
- Fix bad reference to uncompiled link (wrong ID)
- Log any caught errors to the console
- Wrap the init functions to catch and log any errors during init
Fixes b/131863587
Fixes#1911 (similar storage error on iOS)
Change-Id: Ib2a53392d5632c71825af17dd3e955cd54279e98
When the audio and text languages differ, we should display the captions
by default. This also happens if the app calls setTextTrackVisibility
before calling load. What happened is the text media state was being
created, but an update wasn't being scheduled. This meant the text
segments never got appended. This changes when the update gets
schedules. This also removes an unnecessary call to set the initial
state during startup.
Issue #1696Closes#1879
Change-Id: If3a1b9e2889fc0e487da0e7276ca837636bf2e54
The wrong loop index was used, which caused us to create bogus and
non-unique keys for a map, which in turn caused us to skip certain
variants that should have been created.
Fixes#1908
Change-Id: I6475acad16cd76acb81cd562ef033724c7c4ebaf
If the application developer specifies license servers, only those
should be used. Before this, a manifest-specified license server
for a certain key system could still be used if the application didn't
provide one.
Now, if there are _any_ license servers specified by the app, _no_
license servers will be used from the manifest. This is important
because it allows the application a clear way to indicate which DRM
systems should be used on platforms with multiple DRM systems.
The new order of preference for drmInfo:
1. Clear Key config, used for debugging, should override everything else.
(The application can still specify a clearkey license server.)
2. Application-configured servers, if any are present, should override
anything from the manifest. Nuance: if key system A is in the manifest
and key system B is in the player config, only B will be used, not A.
3. Manifest-provided license servers are only used if nothing else is
specified.
Introduced in #1644 to solve #484
Internal issue b/131264101
Closes#1905
Change-Id: I1a36a70044dc7bcc22681e3e4246d0a43d58e413
When the network becomes slow, we check if stopping the current request
and download the content with lower resolution is faster. If so, abort
the current request and start a new one.
Issue #1051
Change-Id: I588e524469432e362361d1cfbde6cd45c2009959
This is a complete replacement for the old demo page, made to be more
modern-looking and easier to maintain. It contains new features such as
remembering the URIs you provide for custom assets, and searching through
the default assets by feature.
This demo page is not quite ready for release yet, but it's getting close.
Change-Id: Iad01d1fc02c3cd238d73b9b9e02dbb4301cb6f2a
Range headers should not be sent when requesting the entire resource.
This fixes compatibility with Microsoft IIS web server.
Introduced in work on issue #1788
Change-Id: I151a2f15d4f5e95531e16d5372ee9a051135f12f
The unprefixed EME launched with macOS 10.14 (Mojave) rejects requests
for the key system IDs we know how to use. So until the bug we filed
against Apple is resolved, prefer the prefixed API.
Issue #382
Change-Id: I71313be2102af2da66a6389a9e9afdebd8ae033d
This adds a polyfill for Apple's prefixed EME implementation. This
will be used on all macOS versions prior to 10.14 (Mojave) and on
Safari versions prior to 12.1.
This also adds support for FairPlay license protocol eccentricities
in DrmEngine, so that the proper formatting is used for requests and
responses.
Issue #382
Change-Id: If1274d2f018a475f56c09df97645694f13acbde9
Track methods are now implemented for native HLS and other src=
playbacks. This will allow the UI to select text and audio languages.
This change adds best-effort methods to get track information for src=
playbacks, including native HLS on Safari. In many cases, it relies
on the audioTracks and videoTracks members of HTMLVideoElement which
are only implemented on Safari. They are in the spec, though, so
there's no harm in using them when they exist.
This is fully parallel to the manifest-based paradigm for MSE-based
playbacks. Each of these top-level methods in Player has an "if" to
decide which way to supply the requested info, except for the language
methods, which now delegate to the track methods.
With this, Safari's native HLS can supply audio and text language
information to the UI/app, and the UI/app can have some control over
those things through the tracks API. I believe this is important to
the success of our new iOS support.
Issue #997
Issue #382
Change-Id: Icc44a932927fafedda1b62a9d4c6e2ed3dc7db30
This fixes the definition of load() to wait for a frame before
resolving the load() Promise for src= playbacks. Now methods like
isAudioOnly can be trusted as soon as load() resolves.
This also allows load() to fail for src= playbacks if an error event
fires from the media element.
Issue #816
Issue #997
Change-Id: I0f6120d1334bbebcb78efdbbca65c7981f3ef265
This is a generic implementation that doesn't rely on the audioTracks
and videoTracks members currently only available on Safari.
Issue #997
Change-Id: I849845513efb2ee51205dcdca8568c889f1f7cdb
When listening to the same event on the same object from two places,
it's important that both listeners get called back.
This fixes EventManager's listenOnce() so that the unlisten() call
within listenOnce() doesn't remove both listeners at once. Now each
listener will be called before it is removed.
This bug is over two years old!
Change-Id: Id99f3a8e5ab80819921b30e28aa66d8a08b29e86
This event was added just for the sake of the UI tests, but the video
element's canplaythrough event works in its place.
Change-Id: I6774fdfdfbd2b197cc93eae743829510b61bb0fa
Allow indirect access to members (such as DRM engine, manifest, etc)
from Player methods as soon as they become available, instead of
waiting until the very end of the load process.
This fixes application access to several methods during the
"manifestparsed" event. The point of the "manifestparsed" event was
to allow early access to manifest and other metadata before streaming
begins.
This also lays the foundations for improvements in native HLS support
in those same methods, including the ability to get track information.
Issue #382
Issue #997
Fixes b/131604508
Change-Id: Ifee7b06fc2ccdcf5bcdf1c44f2f851d1d7e67fa1
In HLS, the CODECS attribute may contain duplicate of the same codec
with different profiles.
Closes#1817
Change-Id: I0d59c1ade6c8387a2e6b3ca00c0287e15c943ea3
Add a new function called getLoadMode that returns the current load mode
The possible responses are:
DESTROYED, NOT_LOADED, MEDIA_SOURCE and SRC_EQUALS
This function is necessary for #1003 because AirPlay only works with SRC_EQUALS mode,
and the AirPlay events fire even in MEDIA_SOURCE mode.
By fixing the definitions of isLive and seekRange for native HLS and
other src= playbacks, the UI for live streams with native HLS is now
working correctly on Safari.
Issue #382
Issue #997
Change-Id: I3d4f49ebe31a543c75f8607e7a194095ef198c0a
Based on experimental evidence, this fudge factor has been increased
from 50ms to 100ms. This is based on playback of the Art of Motion
HLS clip from Bitcodin, where the 50ms fudge was insufficient.
Without this, it goes into a buffering state at the end of the
content.
Issue #997
Change-Id: I7479705fd9e9359e70ab6ed3f24fd29dfdd7631e
Add event to notify listeners when abr is being enabled/disabled.
The resolutions menu is listening for variantchanged events to
update itself. It's possible, however, that just enabled abr
will pick the same variant that's currently being played, in
which case, there'll be no variantchanged event. The resolution,
though, still needs to update to reflect the fact that 'Auto'
resolution is selected now and not a specific one.
Adding an event for when the abr state changes helps solve
this.
Fixes b/131099397
Change-Id: I63b218d7423cd0d389dd540c5ed05966e00b861c
There is no reason to hard-code a value of 2 for this when we could
use a configurable value that the application will expect to have an
effect.
This has been tested with native HLS in desktop Safari.
Change-Id: I3833f2324cdd1419b1b6e9f93809e9239995c505
Commit 1284dd48, Change-Id: I8cad9bfde3309de7c2b8301b90aa8c40b6e4d247
introduced a change to the buffering logic. Instead of going into a
buffering state when less than 0.5 seconds of content was buffered,
the thredhold changed to one half of the configured rebufferingGoal.
Now the rule is one half of the rebufferingGoal or 0.5 seconds,
whichever is smaller. This accounts for unusually small
rebufferingGoal settings, while keeping a saner default behavior.
This change in behavior was one part of the test flake described
in internal bug report b/128923302. The other component to the test
flake was issue #1206, which still has a separate fix.
Issue #1206
Fixes b/128923302
Change-Id: I5f133959acac6fd4ebe7fed37d2df88892e6399e
Currently we check encrypt key tags after we parse the segment, so
playing an AES-128 encrypted content results in error message
'MANIFEST.HLS_COULD_NOT_PARSE_SEGMENT_START_TIME'. We should check the
encrypt key before, and give a more clear error message.
Filtering out the contents encrypted with AES-128, and if there's no
valid content left, we'll show 'CONTENT_UNSUPPORTED_BY_BROWSER'.
Closes#1838
Change-Id: I893f57a939e45f2787144dfe311b779aed26ac34
PlayRateController could get stuck in a state in which playbackRate
would be stuck at 0. It had to do with the order of modifiers
BUFFERING and ZERO_RATE. If they occurred in that order (BUFFERING
because of underflow, followed by ZERO_RATE because of a ratechange
event), then ZERO_RATE would stick.
In some cases (~10%) we would see this as a test failure in "Player
plays while changing languages with short Periods". In the demo app,
it could be easily reproduced by changing resolutions through the UI.
The solution is to remove ZERO_RATE, which doesn't seem to be useful.
Based on the comments in the code, this was to handle seeking in Edge,
where the browser sets playbackRate to 0 during a seek, then restores
it afterward. If that's the case, just ignore the ratechange event
to 0, and let the browser restore it afterwards. No need to track
that as far as I can tell.
With ZERO_RATE removed, it doesn't make sense to keep a BUFFERING
constant, so the whole set has been replaced with a boolean.
Broken in Change-Id: Id462cda2c5eb82c3713237341424b91891bd38ea
This bug did not affect any release or beta versions.
Closes#1886
b/130758100
Change-Id: I8c6455c3cdd7c9f353740425fb9337733908b2c9
We support these older ones and warn about the deprecation, so do not
also leave the older configs and trigger an error from configure.
Change-Id: I49e25e43ce556ff54ad3c1f1408699ff36c31833
In one test, we got into a situation where StreamingEngine was still
setting up a text stream when Player was destroyed. Because Player
destroyed Playhead before StreamingEngine, StreamingEngine tried to
reference it through a callback on PlayerInterface after it was null,
but before StreamingEngine was itself destroyed.
This fixes the order of destruction in Player so that Playhead exists
longer than StreamingEngine.
b/130554111
Change-Id: I5d944e939d79de5adf6b4be3b87a254e2a4ee233
Use a fudge factor to fix infinite buffering at the end of a native
HLS playback. This could go away once we stop managing buffering
state above the browser using playbackRate=0.
Issue #997
Change-Id: Ib4a6fd5aa10dd84f9cfa4972d57db2cc63d7668d
Instead of triggering src= based on 'video/mp4' MIME types, ask the
browser what it can support using video.canPlayType().
Querying canPlayType() also allows us to detect src= support for
native HLS in Safari.
The original version of this change also added a complete fallback
system to detect MIME types based on common file extensions and
fetch MIME types via HEAD request when necessary, but the load graph
system does not yet allow us to make async decisions about destination
node. So this async MIME detection is commented out for now.
Closes#816 (src= single file playback)
Issue #997 (native HLS in Safari)
Change-Id: If1930ca4fd5710481a925d63fb312d9a5b15fec8
Now iOS is supported for HLS through src=, so isBrowserSupported
needs to reflect that. This makes MediaSource optional for any
browser with src= playback of HLS.
This also fixes probeSupport() to reflect the capabilities of non-MSE
platforms such as iOS, which is critical for our demo app to be able
to show the correct set of playable assets.
Issue #997Closes#1857
Change-Id: Ic6e18587db90fff2b097a2038c16cc928e2b9438
This change moves the trick play logic out of the video wrapper so that
it will be more available to the src= code. By doing this, I hope that
we can make it clearer how we are working with the playback rate and
ensure a tighter integration with it.
Issue #816
Issue #997
Change-Id: Id462cda2c5eb82c3713237341424b91891bd38ea
Create the src= load branches for the remaining public methods. This
should ensure that it is now safe to call the public methods when
playing src= content and expect to get the intended return values.
The tests to verify this are in a follow-up CL.
Issue #816
Issue #997
Change-Id: I088b6bbd2489b3960457030846debae07fd86d16
Because of the lack of tests (tests are coming) we did not see that the
buffering system was failing to find media source to check if it had
buffered to the end of the presentation.
This change adds the logic needed to know if it has buffered to the end
for each type of loaded content.
Issue #816
Issue #997
Change-Id: Ief9d4bdc94f3121f889a0efa24a8b3d78377bb9f
This change adds support for images via SMPTE-TT by adding background image support to the TTML text parser. This required changing region parsing to respect global extends.
Issue #840
Two changes around src= went in around the same time and they merged
poorly, resulting in a broken build. This change corrects that.
Issue #816
Issue #997
Change-Id: I1c84e56c06de0b80c11933144b453907f3e75786
Add the idea of load modes. These are low resolution state flags that
allow us to know what state we are in. These flags work with the load
graph, being set strategically during the load progress to enable and
disable public method behaviour.
In the grand-scheme of things, this solution is meant to be revisited,
but is meant to unblock the work for src=.
Issue #816
Issue #997
Change-Id: I28660d5d5ef2d746d63988b488f5d15a10ee75a4
This CL creates the "loaded with src=" node and its initial
implementation. Adding this node required some changed to the routing
logic as a new destination was created.
We will use src= when given mp4 content or media source is unavailable.
We detect mp4 content via the mimeType in |load| and/or the file
extension. When media source is not available on a platform, we fall
back to using src=. To do this, we check if media source is available
whenever |load| is called, and will route to the src= branch if media
source is not found.
To avoid pre-initializing media source (when it is not available) we
modify the |initializeMediaSource| flag in |attach| and |unload| when
media source is not available.
Doing this showed that we had inconsistent behaviour between |attach|
and |unload|. |attach| would default to initializing media source
whereas |unload| would not. This has been fixed.
Issue #816
Issue #997
Change-Id: I00599832b49c9079e273e65a4b827fee736479cc
To make the getBufferedInfo method simpler for when we have three
different ways of responding (not loaded, loaded with media source, and
loaded with src=), this changes media source to fill-in a buffered info
object rather than return one.
Issue #816
Issue #997
Change-Id: If9e4558ca324808a1b94e3c235f4bfb42a5df8ce
Joey Parrish
Álvaro Velad Galván
Jacob Trimble
Michelle Zhuo
Theodore Abshire
Sandra Lokshina
Aaron Vaage