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

media/base/eme_constants.h

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef MEDIA_BASE_EME_CONSTANTS_H_
 #define MEDIA_BASE_EME_CONSTANTS_H_
 
 #include <stdint.h>
 
 namespace media {
@@ skipping 111 matching lines @@
   // The configuration option is supported, but the user experience may be
   // improved if a distinctive identifier is available.
   IDENTIFIER_RECOMMENDED,
   // The configuration option prevents use of persistent state.
   PERSISTENCE_NOT_ALLOWED,
   // The configuration option is supported if persistent state is available.
   PERSISTENCE_REQUIRED,
   // 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,
 };
 
 }  // namespace media
 
 #endif  // MEDIA_BASE_EME_CONSTANTS_H_