Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

updating my repo #1

Merged
merged 17 commits into from
May 5, 2021
Merged

Conversation

surajkumar-sk
Copy link
Owner

Description

Screenshots (optional)

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to
    not work as expected)
  • This change requires a documentation update

Checklist:

  • I have signed the Google CLA https://cla.developers.google.com
  • My code follows the style guidelines of this project
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • I have verified my change on multiple browsers on different platforms
  • I have run ./build/all.py and the build passes
  • I have run ./build/test.py and all tests pass

ismena and others added 17 commits April 28, 2021 16:00
Issue #3359

Change-Id: I9611a33591f71f4990cc8feef0974b476da70de3
When there is no session type specified by a manifest parser or the
app's DRM config, we select a session type based on context (offline
or streaming).

In the EME branches of DrmEngine, we select the ultimate session type
in the engine's DrmInfo based on the configuration that was sent to
EME.  This, in turn, influences what kinds of sessions we create
later.

However, in the MediaCapabilities branch of DrmEngine, we were
defaulting to 'temporary' sessions in the engine's DrmInfo, without
regard to the input config or the load context.

This fixes the default so that it mirrors the input config to MCap.
That MCap config is not accessible at that time, so we just re-derive
the same value based on a boolean stored in DrmEngine.

In cases where there is a session type from the manifest parser (rare)
or the app's DRM config (more common), that will be preferred
regardless of context.

Change-Id: I1f408c04eff9a3006d2eddfaf748f7ab2c93cf9b
Because our MediaCapabilities integration adds decoding info to each
variant, we need to be careful to reset this info on variants that are
cached and persist between tests and between manifest parser
instances.  This ensures that these unusual test variants will not
have persistent decoding infos from MediaCapabilities.

For encrypted content, the decoding info contains negotiated EME
information which varies based on the chosen key system and whether
the content will be streamed or stored offline.  If one test loads the
content for streaming, then another test loads the same content for
offline storage, the second test would encounter the cached decoding
info from the first test, and the negotatied key system would not be
set up for the correct session types.  This would lead to a test
failure.  This sort of failure would not be seen in real playback
(since no supported manifest parser would ever cache variants).

By resetting variant.decodingInfos when the fake manifest parser is
stopped, we ensure that each test gets a clean slate (as would happen
with a real parser), and the correct decodingInfos show up for each
part of each test case.

Change-Id: I73aea2e5144723512eb460d866ac9620937492bc
Change-Id: I0d5aaa2f4b37ce5a80880bfce653df4387980cfa
There was an alias to shaka.test.Util in a global context which was
affecting other tests.  The result was that these tests could refer to
"Util" without the namespace or their own alias, and everything would
work.

The problem with that is that when the file with the global alias was
removed or disabled, those other tests would fail because "Util" would
be undefined.

This removes the global alias and adds missing local aliases to the
test suites that were accidentally relying on the global one.

Change-Id: Ifca8c1ada0c3e46cb30a2039b5c4c2252d992d37
Issue #2339

Change-Id: I80ffa7b04f7afd943aa0f881d2a494dd35def732
Since we got some unexpected decodingInfo results from MediaCapabilities
on Chromecast, we should fall back to MediaSource.isTypeSupported() on
Chromecast.

Issue #1391

Change-Id: I4947ec78624e98c7039df64ad691e14ece2588e0
MediaCapabilities supports 'vp09...' codecs, but not 'vp9'. Translate
vp9 codec strings into 'vp09...', to allow such content to play with
mediaCapabilities enabled.

Change-Id: Iff7ddae379efb8a9f0766c89a62b85a325f81e93
Change-Id: Ifa042ca4e5e8922121d332cc790559d5bbff14ae
Change-Id: I7d82cb3dcb01be702dcbc9084df55c8db9493b58
Embedded and non-embedded captions enter the text engine through
a significantly different path. Notably, when embedded captions
are present, they are constantly being fed to the text engine even
when not turned on, as there is no extra bandwidth cost to appending
them. They are merely ignored if the correct flag is not set.
Well, it turns out that we weren't un-setting the flag when
transitioning from embedded to non-embedded captions, so the embedded
captions would continue to be displayed indefinitely in that case, on
top of the non-embedded ones.
This changes the streaming engine to clear that flag if the text media
state is detected to be non-embedded.

Issue #3199

Change-Id: Ib06d0d1628e0ce8c863ffee523db0ea4ec8c3c73
Some internal Google tools that are meant to find XSS vulnerabilities
complain about some parts of Shaka Player.  In particular:

 - Using setAttribute instead of a src property
 - Using setAttribute with a variable key
 - Using URL.createObjectURL

This resolves these internal XSS checks.  As far as I can tell, there
are no serious XSS risks from any of these, as the complaining checks
are meant to catch things that could be executed as scripts.  None of
these user-controlled inputs are treated as such, but it seems that
the compiler involved can't tell that.

This goes part of the way toward solving #3378.

Change-Id: I302b9eb56a374854c9b8525b21960ef64fd386f1
Change-Id: I376d50f099fdd3ecd3622d9ac0c4b90f14424fdb
We'll allow users to configure key system priorities through the
'drm.preferredKeySystems' configuration.

Edge now supports both Widevine and PlayReady, and users should be
able to configure the priorities of the key systems.

If no key system is preferred, or no preferred key systems is valid,
we'll fall back to the original behavior of choosing the first key
system with configured license server url in the manifest.

Example:
  player.configure('drm.preferredKeySystems', [
    'com.widevine.alpha',
    'com.microsoft.playready',
  ]);
If both Widevine and Playready have a license server and are
supported, the config sets Widevine as the first choice, and
PlayReady as the second.

Issue #3002

Change-Id: Idb881ef4921259bb3e1879cd8ec2bb6966d6580d
Though the contents are the same, I would rather use a server cert URI
that is hosted on the same license server, which we control.

This also cleans up the formatting.

Change-Id: If54e1a6560cb68c72fc6ada177eeb488f11cf68b
@surajkumar-sk surajkumar-sk merged commit 26dc16c into surajkumar-sk:master May 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants