Restrict use of hardware-secure codecs based on the RendererPreference.

media/base/eme_constants.h

Index: media/base/eme_constants.h
diff --git a/media/base/eme_constants.h b/media/base/eme_constants.h
index 6d6399d60174ce060c331e2353a5f10bd9055488..53543e03faf3f8ab5d94565f6bc93b623859c8c4 100644
--- a/media/base/eme_constants.h
+++ b/media/base/eme_constants.h
@@ -129,15 +129,13 @@ enum class EmeConfigRule {
   // The configuration option is supported if both a distinctive identifier and
   // persistent state are available.
   IDENTIFIER_AND_PERSISTENCE_REQUIRED,
-#if defined(OS_ANDROID)
-  // The configuration option is supported if no hardware-secure codecs are used
-  // (as they would be for video if secure surfaces are enabled).
-  SECURE_CODECS_NOT_ALLOWED,
-  // The configuration option is supported if only hardware-secure codecs are
-  // used. This implies that secure surfaces (hole-punching) are required for
-  // video.
-  SECURE_CODECS_REQUIRED,
-#endif  // defined(OS_ANDROID)
+  // The configuration option prevents requiring the use of secure surfaces.

[ddorwin, 2015/05/08 03:18:31]

This really (will in the next CL) affects the security level. Surfaces are the
current implementation, but that may change in the future.

If you think this is clearer for now, we can leave this, but we'll probably have
to change it later.

[sandersd (OOO until July 31), 2015/05/08 18:04:45]

Things get murky here, because there is an implicit relation between secure
codecs/secure surfaces/security level. I changed to using surfaces in this CL
because that seems to be the key issue to solve. In the future (especially one
with secure textures) we may want to take a different approach, but I don't see
this changing in the next CL.

+  // (This could mean that secure surfaces are not available at all, or just
+  // that they are not guaranteed to be available together with this
+  // configuration option.)
+  SECURE_SURFACES_NOT_REQUIRABLE,

[ddorwin, 2015/05/08 03:18:31]

Why "REQUIRABLE" instead of "ALLOWED"?

[sandersd (OOO until July 31), 2015/05/08 18:04:45]

The actual use of secure surfaces is independent of this rule; secure codecs
require them, but regular codecs don't block them.

The key is that some codecs may not have a secure variant, and if we add them to
the config, then we know we can't request L1. Without L1 we can't guarantee that
secure surfaces are used; therefore the rule must be incompatible with requiring
secure surfaces.

The opposite value, NOT_ALLOWED, isn't accurate because secure surfaces may
actually still be used.

+  // The configuration option is supported if secure surfaces are used.
+  SECURE_SURFACES_REQUIRED,
   // The configuration option is supported without conditions.
   SUPPORTED,
 };