forked from shaka-project/shaka-player
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Screenshots (optional)
Type of change
not work as expected)
Checklist:
./build/all.py
and the build passes./build/test.py
and all tests pass