Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2445433003:
media: Enable encrypted media content browsertests when MojoCdm is used (Closed)
|
Created:
4 years, 2 months ago by xhwang Modified:
4 years, 1 month ago CC:
chromium-reviews, darin-cc_chromium.org, eme-reviews_chromium.org, feature-media-reviews_chromium.org, jam, jochen+watch_chromium.org, mlamouri+watch-content_chromium.org, Peter Beverloo Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
Descriptionmedia: Enable encrypted media content browsertests when MojoCdm is used
Previously on Android (that uses MojoCdm by default), we enabled
External Clear Key support and used it in encrypted media content
browsertests.
This CL extends the coverage such that on all platforms that uses
MojoCdm, these tests will be enabled. For example, on cast_shell, both
MojoCdm and MojoRenderer are used.
Note that an AesDecryptor is running in the remote process (Gpu or
Browser). On Android, the Decryptor on the CDM is wrapped into a
MojoDecryptor, which is used by the DecryptingDemuxerStream in the
render process. On CastShell, the Decryptor on the CDM is used directly
by the Renderer running in the remote process.
TBR=mkwst@chromium.org,peter@chromium.org
BUG=641559
TEST=This CL enables existing tests on more platforms.
Committed: https://crrev.com/41f1d0e9e7bfab2aca601b12599e124ccc2def1e
Cr-Commit-Position: refs/heads/master@{#431523}
Patch Set 1 #Patch Set 2 : media: Enable encrypted media content browsertests when MojoCdm is used #
Total comments: 27
Patch Set 3 : comments #Patch Set 4 : comments addressed #Patch Set 5 : rebase only #
Messages
Total messages: 47 (28 generated)
The CQ bit was checked by xhwang@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by xhwang@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
xhwang@chromium.org changed reviewers: + alokp@chromium.org, ddorwin@chromium.org
PTAL
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
kindly ping :)
On 2016/10/25 21:07:43, xhwang wrote: > kindly ping :) ddorwin: kindly ping :) alokp: FYI
Description was changed from ========== media: Enable encrypted media content browsertests when MojoCdm is used Previously on Android (that uses MojoCdm by default), we enabled External Clear Key support and used it in encrypted media content browsertests. This CL extends the coverage such that on all platforms that uses MojoCdm, these tests will be enabled. For example, on cast_shell, both MojoCdm and MojoRenderer are used. Note that an AesDecryptor is running in the remote process (Gpu or Browser). On Android, the Decryptor on the CDM is wrapped into a MojoDecryptor, which is used by the DecryptingDemuxerStream in the render process. On CastShell, the Decryptor on the CDM is used directly by the Renderer running in the remote process. BUG=641559 TEST=This CL enables existing tests on more platforms. ========== to ========== media: Enable encrypted media content browsertests when MojoCdm is used Previously on Android (that uses MojoCdm by default), we enabled External Clear Key support and used it in encrypted media content browsertests. This CL extends the coverage such that on all platforms that uses MojoCdm, these tests will be enabled. For example, on cast_shell, both MojoCdm and MojoRenderer are used. Note that an AesDecryptor is running in the remote process (Gpu or Browser). On Android, the Decryptor on the CDM is wrapped into a MojoDecryptor, which is used by the DecryptingDemuxerStream in the render process. On CastShell, the Decryptor on the CDM is used directly by the Renderer running in the remote process. BUG=641559 TEST=This CL enables existing tests on more platforms. ==========
xhwang@chromium.org changed required reviewers: + ddorwin@chromium.org
https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... File content/browser/media/encrypted_media_browsertest.cc (right): https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... content/browser/media/encrypted_media_browsertest.cc:23: #define SUPPORTS_CLEAR_KEY These implementations don't support CK at all? https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... content/browser/media/encrypted_media_browsertest.cc:32: #define SUPPORTS_EXTERNAL_CLEAR_KEY ..._VIA_MOJO? Desktop supports ECK but doesn't need the switch. https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... content/browser/media/encrypted_media_browsertest.cc:152: #if defined(SUPPORTS_CLEAR_KEY) Should we expect failures instead of just not running them? https://codereview.chromium.org/2445433003/diff/20001/content/shell/renderer/... File content/shell/renderer/shell_content_renderer_client.cc (right): https://codereview.chromium.org/2445433003/diff/20001/content/shell/renderer/... content/shell/renderer/shell_content_renderer_client.cc:29: #if defined(ENABLE_MOJO_CDM) These should be converted to build features (separate CL). https://codereview.chromium.org/2445433003/diff/20001/content/shell/renderer/... content/shell/renderer/shell_content_renderer_client.cc:143: #if defined(ENABLE_MOJO_CDM) This isn't going to be correct for desktop. https://codereview.chromium.org/2445433003/diff/20001/media/base/key_systems.cc File media/base/key_systems.cc (right): https://codereview.chromium.org/2445433003/diff/20001/media/base/key_systems.... media/base/key_systems.cc:417: if (base::FeatureList::IsEnabled(media::kExternalClearKeyForTesting) && Does this work with ENABLE_PEPPER_CDMS? Do we expect it to be used for Pepper ECK? I guess use of this flag would cause us to say it is blockable. But we must still register it as ALWAYS_ENABLED? https://codereview.chromium.org/2445433003/diff/20001/media/cdm/default_cdm_f... File media/cdm/default_cdm_factory.cc (right): https://codereview.chromium.org/2445433003/diff/20001/media/cdm/default_cdm_f... media/cdm/default_cdm_factory.cc:26: static bool ShouldUseAesDecryptor(const std::string& key_system) { s/Use/Create/? https://codereview.chromium.org/2445433003/diff/20001/media/cdm/default_cdm_f... media/cdm/default_cdm_factory.cc:30: // Create AesDecryptor here to support External Clear Key key system. nit: This comment is a bit odd ("Create... here"). Maybe "should create" or similar.
The CQ bit was checked by xhwang@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... File content/browser/media/encrypted_media_browsertest.cc (right): https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... content/browser/media/encrypted_media_browsertest.cc:23: #define SUPPORTS_CLEAR_KEY On 2016/10/28 19:03:47, ddorwin wrote: > These implementations don't support CK at all? When mojo CDM and mojo Renderer are both used, currently ClearKey isn't supported in the content shell. Other content embedders (e.g. cast) could choose to support Clear Key in their implementation. I have some idea to fix this. But I'd like to do that in a separate CL. https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... content/browser/media/encrypted_media_browsertest.cc:32: #define SUPPORTS_EXTERNAL_CLEAR_KEY On 2016/10/28 19:03:47, ddorwin wrote: > ..._VIA_MOJO? > > Desktop supports ECK but doesn't need the switch. In content_browsertests we don't have pepper ECK. So IMHO this isn't necessary. https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... content/browser/media/encrypted_media_browsertest.cc:152: #if defined(SUPPORTS_CLEAR_KEY) On 2016/10/28 19:03:47, ddorwin wrote: > Should we expect failures instead of just not running them? I'll fix this in the next CL. https://codereview.chromium.org/2445433003/diff/20001/content/shell/renderer/... File content/shell/renderer/shell_content_renderer_client.cc (right): https://codereview.chromium.org/2445433003/diff/20001/content/shell/renderer/... content/shell/renderer/shell_content_renderer_client.cc:29: #if defined(ENABLE_MOJO_CDM) On 2016/10/28 19:03:47, ddorwin wrote: > These should be converted to build features (separate CL). Acknowledged. https://codereview.chromium.org/2445433003/diff/20001/content/shell/renderer/... content/shell/renderer/shell_content_renderer_client.cc:143: #if defined(ENABLE_MOJO_CDM) On 2016/10/28 19:03:47, ddorwin wrote: > This isn't going to be correct for desktop. This shell is the content embedder only used for content_browsertests. For browser_tests, "chrome" is the content embedder, we have pepper ECK registered there. https://codereview.chromium.org/2445433003/diff/20001/media/base/key_systems.cc File media/base/key_systems.cc (right): https://codereview.chromium.org/2445433003/diff/20001/media/base/key_systems.... media/base/key_systems.cc:417: if (base::FeatureList::IsEnabled(media::kExternalClearKeyForTesting) && On 2016/10/28 19:03:47, ddorwin wrote: > Does this work with ENABLE_PEPPER_CDMS? Do we expect it to be used for Pepper > ECK? In browser_tests we do set kExternalClearKeyForTesting so this check will be true when we run ECK tests. So for ECK can_block is always true because: - For pepper ECK, all pepper-based key system "can block", see line 404 and 415. - For mojo ECK, it's implemented using AesDecryptor, so it also "can block", see line 408. The tricky part is that pepper ECK will also execute this line, which I feel okay. I can put this in a defined(ENABLE_MOJO_CDM) block if you like. > I guess use of this flag would cause us to say it is blockable. But we must > still register it as ALWAYS_ENABLED? https://codereview.chromium.org/2445433003/diff/20001/media/cdm/default_cdm_f... File media/cdm/default_cdm_factory.cc (right): https://codereview.chromium.org/2445433003/diff/20001/media/cdm/default_cdm_f... media/cdm/default_cdm_factory.cc:20: DefaultCdmFactory::DefaultCdmFactory() { This class is only used for testing. I'd like to rename it to TestCdmFactory or CdmFactoryForTesting in a separate CL. WDYT? https://codereview.chromium.org/2445433003/diff/20001/media/cdm/default_cdm_f... media/cdm/default_cdm_factory.cc:26: static bool ShouldUseAesDecryptor(const std::string& key_system) { On 2016/10/28 19:03:47, ddorwin wrote: > s/Use/Create/? Done. https://codereview.chromium.org/2445433003/diff/20001/media/cdm/default_cdm_f... media/cdm/default_cdm_factory.cc:30: // Create AesDecryptor here to support External Clear Key key system. On 2016/10/28 19:03:48, ddorwin wrote: > nit: This comment is a bit odd ("Create... here"). Maybe "should create" or > similar. Done.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
ddorwin: kindly ping :)
PS3 changes LG. All of my comments are in PS2, mostly in reply to existing discussion but there is at least one new one. https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... File content/browser/media/encrypted_media_browsertest.cc (right): https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... content/browser/media/encrypted_media_browsertest.cc:23: #define SUPPORTS_CLEAR_KEY On 2016/11/03 07:14:44, xhwang_OOO_11_07 wrote: > On 2016/10/28 19:03:47, ddorwin wrote: > > These implementations don't support CK at all? > > When mojo CDM and mojo Renderer are both used, currently ClearKey isn't > supported in the content shell. Other content embedders (e.g. cast) could choose > to support Clear Key in their implementation. > > I have some idea to fix this. But I'd like to do that in a separate CL. I think the name is too broad and could be confusing where it is used and/or eventually conflict with a more global define. Should we add ..._IN_CONTENT ? Since this is the exception, should it be DOES_NOT_...? https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... content/browser/media/encrypted_media_browsertest.cc:32: #define SUPPORTS_EXTERNAL_CLEAR_KEY On 2016/11/03 07:14:44, xhwang_OOO_11_07 wrote: > On 2016/10/28 19:03:47, ddorwin wrote: > > ..._VIA_MOJO? > > > > Desktop supports ECK but doesn't need the switch. > > In content_browsertests we don't have pepper ECK. So IMHO this isn't necessary. Add _IN_CONTENT similar to above? https://codereview.chromium.org/2445433003/diff/20001/content/shell/renderer/... File content/shell/renderer/shell_content_renderer_client.cc (right): https://codereview.chromium.org/2445433003/diff/20001/content/shell/renderer/... content/shell/renderer/shell_content_renderer_client.cc:143: #if defined(ENABLE_MOJO_CDM) On 2016/11/03 07:14:44, xhwang_OOO_11_07 wrote: > On 2016/10/28 19:03:47, ddorwin wrote: > > This isn't going to be correct for desktop. > > This shell is the content embedder only used for content_browsertests. For > browser_tests, "chrome" is the content embedder, we have pepper ECK registered > there. I meant when SoDo is enabled. https://codereview.chromium.org/2445433003/diff/20001/media/base/key_systems.cc File media/base/key_systems.cc (right): https://codereview.chromium.org/2445433003/diff/20001/media/base/key_systems.... media/base/key_systems.cc:403: // Distinctive identifiers and persistent state can only be reliably blocked I wonder if we should move this to a CanBlock() helper function so we can just return a bool at each point, possibly synchronized with the comment (rather than as one comment at the top) and to make it clear that this code is only dealing with determining can_block. https://codereview.chromium.org/2445433003/diff/20001/media/base/key_systems.... media/base/key_systems.cc:417: if (base::FeatureList::IsEnabled(media::kExternalClearKeyForTesting) && On 2016/11/03 07:14:44, xhwang wrote: > On 2016/10/28 19:03:47, ddorwin wrote: > > Does this work with ENABLE_PEPPER_CDMS? Do we expect it to be used for Pepper > > ECK? > > In browser_tests we do set kExternalClearKeyForTesting so this check will be > true when we run ECK tests. So for ECK can_block is always true because: > - For pepper ECK, all pepper-based key system "can block", see line 404 and 415. > - For mojo ECK, it's implemented using AesDecryptor, so it also "can block", see > line 408. > > The tricky part is that pepper ECK will also execute this line, which I feel > okay. I can put this in a defined(ENABLE_MOJO_CDM) block if you like. > > > I guess use of this flag would cause us to say it is blockable. But we must > > still register it as ALWAYS_ENABLED? > The code is inconsistent with the comment, which says this is limited to MojoCdm. They should probably be consistent. (Refactoring this and/or the comments, as suggested above, would also hep us avoid introducing such inconsistencies.)
comments addressed
The CQ bit was checked by xhwang@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Thanks for the comments. PTAL again! https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... File content/browser/media/encrypted_media_browsertest.cc (right): https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... content/browser/media/encrypted_media_browsertest.cc:23: #define SUPPORTS_CLEAR_KEY On 2016/11/10 01:24:29, ddorwin wrote: > On 2016/11/03 07:14:44, xhwang_OOO_11_07 wrote: > > On 2016/10/28 19:03:47, ddorwin wrote: > > > These implementations don't support CK at all? > > > > When mojo CDM and mojo Renderer are both used, currently ClearKey isn't > > supported in the content shell. Other content embedders (e.g. cast) could > choose > > to support Clear Key in their implementation. > > > > I have some idea to fix this. But I'd like to do that in a separate CL. > > I think the name is too broad and could be confusing where it is used and/or > eventually conflict with a more global define. > > Should we add ..._IN_CONTENT ? Done with ..._IN_CONTENT_SEHLL. > Since this is the exception, should it be DOES_NOT_...? I don't like double negative :) https://codereview.chromium.org/2445433003/diff/20001/content/browser/media/e... content/browser/media/encrypted_media_browsertest.cc:32: #define SUPPORTS_EXTERNAL_CLEAR_KEY On 2016/11/10 01:24:29, ddorwin wrote: > On 2016/11/03 07:14:44, xhwang_OOO_11_07 wrote: > > On 2016/10/28 19:03:47, ddorwin wrote: > > > ..._VIA_MOJO? > > > > > > Desktop supports ECK but doesn't need the switch. > > > > In content_browsertests we don't have pepper ECK. So IMHO this isn't > necessary. > > Add _IN_CONTENT similar to above? Done. https://codereview.chromium.org/2445433003/diff/20001/content/shell/renderer/... File content/shell/renderer/shell_content_renderer_client.cc (right): https://codereview.chromium.org/2445433003/diff/20001/content/shell/renderer/... content/shell/renderer/shell_content_renderer_client.cc:143: #if defined(ENABLE_MOJO_CDM) On 2016/11/10 01:24:29, ddorwin wrote: > On 2016/11/03 07:14:44, xhwang_OOO_11_07 wrote: > > On 2016/10/28 19:03:47, ddorwin wrote: > > > This isn't going to be correct for desktop. > > > > This shell is the content embedder only used for content_browsertests. For > > browser_tests, "chrome" is the content embedder, we have pepper ECK registered > > there. > > I meant when SoDo is enabled. My original plan was that when SoDo is enabled, we'll keep using a ClearKeyCdm based ECK in "chrome". In content shell, we'll keep using a AesDecryptor based ECK (as registered here). https://codereview.chromium.org/2445433003/diff/20001/media/base/key_systems.cc File media/base/key_systems.cc (right): https://codereview.chromium.org/2445433003/diff/20001/media/base/key_systems.... media/base/key_systems.cc:403: // Distinctive identifiers and persistent state can only be reliably blocked On 2016/11/10 01:24:29, ddorwin wrote: > I wonder if we should move this to a CanBlock() helper function so we can just > return a bool at each point, possibly synchronized with the comment (rather than > as one comment at the top) and to make it clear that this code is only dealing > with determining can_block. Good point. I like it. Done. https://codereview.chromium.org/2445433003/diff/20001/media/base/key_systems.... media/base/key_systems.cc:417: if (base::FeatureList::IsEnabled(media::kExternalClearKeyForTesting) && On 2016/11/10 01:24:29, ddorwin wrote: > On 2016/11/03 07:14:44, xhwang wrote: > > On 2016/10/28 19:03:47, ddorwin wrote: > > > Does this work with ENABLE_PEPPER_CDMS? Do we expect it to be used for > Pepper > > > ECK? > > > > In browser_tests we do set kExternalClearKeyForTesting so this check will be > > true when we run ECK tests. So for ECK can_block is always true because: > > - For pepper ECK, all pepper-based key system "can block", see line 404 and > 415. > > - For mojo ECK, it's implemented using AesDecryptor, so it also "can block", > see > > line 408. > > > > The tricky part is that pepper ECK will also execute this line, which I feel > > okay. I can put this in a defined(ENABLE_MOJO_CDM) block if you like. > > > > > I guess use of this flag would cause us to say it is blockable. But we must > > > still register it as ALWAYS_ENABLED? > > > > The code is inconsistent with the comment, which says this is limited to > MojoCdm. They should probably be consistent. (Refactoring this and/or the > comments, as suggested above, would also hep us avoid introducing such > inconsistencies.) Done.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
LGTM. Thank you.
xhwang@chromium.org changed reviewers: + mkwst@chromium.org, peter@chromium.org
mkwst@ and peter@: Could any of you OWNERS-review the trivial changes in content/shell/*?
TRBing mkwst@ and peter@ on trivial changes in content/shell/*
Description was changed from ========== media: Enable encrypted media content browsertests when MojoCdm is used Previously on Android (that uses MojoCdm by default), we enabled External Clear Key support and used it in encrypted media content browsertests. This CL extends the coverage such that on all platforms that uses MojoCdm, these tests will be enabled. For example, on cast_shell, both MojoCdm and MojoRenderer are used. Note that an AesDecryptor is running in the remote process (Gpu or Browser). On Android, the Decryptor on the CDM is wrapped into a MojoDecryptor, which is used by the DecryptingDemuxerStream in the render process. On CastShell, the Decryptor on the CDM is used directly by the Renderer running in the remote process. BUG=641559 TEST=This CL enables existing tests on more platforms. ========== to ========== media: Enable encrypted media content browsertests when MojoCdm is used Previously on Android (that uses MojoCdm by default), we enabled External Clear Key support and used it in encrypted media content browsertests. This CL extends the coverage such that on all platforms that uses MojoCdm, these tests will be enabled. For example, on cast_shell, both MojoCdm and MojoRenderer are used. Note that an AesDecryptor is running in the remote process (Gpu or Browser). On Android, the Decryptor on the CDM is wrapped into a MojoDecryptor, which is used by the DecryptingDemuxerStream in the render process. On CastShell, the Decryptor on the CDM is used directly by the Renderer running in the remote process. TBR=mkwst@chromium.org,peter@chromium.org BUG=641559 TEST=This CL enables existing tests on more platforms. ==========
The CQ bit was checked by xhwang@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Failed to apply patch for content/shell/BUILD.gn:
While running git apply --index -p1;
error: patch failed: content/shell/BUILD.gn:203
error: content/shell/BUILD.gn: patch does not apply
Patch: content/shell/BUILD.gn
Index: content/shell/BUILD.gn
diff --git a/content/shell/BUILD.gn b/content/shell/BUILD.gn
index
94ff3cb32bbc41805329559e29d1a3d568bd6eca..8b2092f81763e4af2d9cc16b684969d0753739fe
100644
--- a/content/shell/BUILD.gn
+++ b/content/shell/BUILD.gn
@@ -203,6 +203,10 @@ static_library("content_shell_lib") {
"//third_party/WebKit/public:debug_devtools",
]
+ if (enable_mojo_media) {
+ configs += [ "//media/mojo/services:mojo_media_config" ]
+ }
+
defines = [ "CONTENT_SHELL_VERSION=\"$content_shell_version\"" ]
public_deps = [
rebase only
The CQ bit was checked by xhwang@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by xhwang@chromium.org
The CQ bit was checked by xhwang@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from ddorwin@chromium.org Link to the patchset: https://codereview.chromium.org/2445433003/#ps80001 (title: "rebase only")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
//content/shell LGTM.
Message was sent while issue was closed.
Description was changed from ========== media: Enable encrypted media content browsertests when MojoCdm is used Previously on Android (that uses MojoCdm by default), we enabled External Clear Key support and used it in encrypted media content browsertests. This CL extends the coverage such that on all platforms that uses MojoCdm, these tests will be enabled. For example, on cast_shell, both MojoCdm and MojoRenderer are used. Note that an AesDecryptor is running in the remote process (Gpu or Browser). On Android, the Decryptor on the CDM is wrapped into a MojoDecryptor, which is used by the DecryptingDemuxerStream in the render process. On CastShell, the Decryptor on the CDM is used directly by the Renderer running in the remote process. TBR=mkwst@chromium.org,peter@chromium.org BUG=641559 TEST=This CL enables existing tests on more platforms. ========== to ========== media: Enable encrypted media content browsertests when MojoCdm is used Previously on Android (that uses MojoCdm by default), we enabled External Clear Key support and used it in encrypted media content browsertests. This CL extends the coverage such that on all platforms that uses MojoCdm, these tests will be enabled. For example, on cast_shell, both MojoCdm and MojoRenderer are used. Note that an AesDecryptor is running in the remote process (Gpu or Browser). On Android, the Decryptor on the CDM is wrapped into a MojoDecryptor, which is used by the DecryptingDemuxerStream in the render process. On CastShell, the Decryptor on the CDM is used directly by the Renderer running in the remote process. TBR=mkwst@chromium.org,peter@chromium.org BUG=641559 TEST=This CL enables existing tests on more platforms. ==========
Message was sent while issue was closed.
Committed patchset #5 (id:80001)
Message was sent while issue was closed.
Description was changed from ========== media: Enable encrypted media content browsertests when MojoCdm is used Previously on Android (that uses MojoCdm by default), we enabled External Clear Key support and used it in encrypted media content browsertests. This CL extends the coverage such that on all platforms that uses MojoCdm, these tests will be enabled. For example, on cast_shell, both MojoCdm and MojoRenderer are used. Note that an AesDecryptor is running in the remote process (Gpu or Browser). On Android, the Decryptor on the CDM is wrapped into a MojoDecryptor, which is used by the DecryptingDemuxerStream in the render process. On CastShell, the Decryptor on the CDM is used directly by the Renderer running in the remote process. TBR=mkwst@chromium.org,peter@chromium.org BUG=641559 TEST=This CL enables existing tests on more platforms. ========== to ========== media: Enable encrypted media content browsertests when MojoCdm is used Previously on Android (that uses MojoCdm by default), we enabled External Clear Key support and used it in encrypted media content browsertests. This CL extends the coverage such that on all platforms that uses MojoCdm, these tests will be enabled. For example, on cast_shell, both MojoCdm and MojoRenderer are used. Note that an AesDecryptor is running in the remote process (Gpu or Browser). On Android, the Decryptor on the CDM is wrapped into a MojoDecryptor, which is used by the DecryptingDemuxerStream in the render process. On CastShell, the Decryptor on the CDM is used directly by the Renderer running in the remote process. TBR=mkwst@chromium.org,peter@chromium.org BUG=641559 TEST=This CL enables existing tests on more platforms. Committed: https://crrev.com/41f1d0e9e7bfab2aca601b12599e124ccc2def1e Cr-Commit-Position: refs/heads/master@{#431523} ==========
Message was sent while issue was closed.
Patchset 5 (id:??) landed as https://crrev.com/41f1d0e9e7bfab2aca601b12599e124ccc2def1e Cr-Commit-Position: refs/heads/master@{#431523} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
