Generalize Pepper CDM API decrypt and decode.

ppapi/api/private/pp_content_decryptor.idl

 /* Copyright (c) 2012 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.
  */
 
 /**
  * The <code>PP_DecryptTrackingInfo</code> struct contains necessary information
  * that can be used to associate the decrypted block with a decrypt request
  * and/or an input block.
  */
@@ skipping 96 matching lines @@
   uint32_t iv_size;
 
   /**
    * Subsample information of the block to be decrypted.
    */
   PP_DecryptSubsampleDescription[16] subsamples;
   uint32_t num_subsamples;
 };
 
 /**
+ * <code>PP_StreamType</code> contains stream type constants.
+ */
+[assert_size(4)]
+enum PP_StreamType {
+  PP_STREAMTYPE_UNKNOWN = 0,

[Ami GONE FROM CHROMIUM, 2012/10/10 07:30:26]

why does it make sense to have UNKNOWN?

[Tom Finegan, 2012/10/10 08:26:06]

I was thinking of metadata and text streams, and that all our other enums have
UNKNOWN values. Remove?

[Ami GONE FROM CHROMIUM, 2012/10/10 18:06:45]

yes, remove until needed.

[Tom Finegan, 2012/10/10 20:02:51]

Done.

+  PP_STREAMTYPE_AUDIO = 1,
+  PP_STREAMTYPE_VIDEO = 2
+};
+
+/**
+ * <code>PP_EncryptedMediaInfo</code> contains the information required to

[Ami GONE FROM CHROMIUM, 2012/10/10 07:30:26]

Does this type justify its existence, as opposed to just passing a StreamType
along w/ the EncryptedBlockInfo to DecryptAndDecode ?

[Tom Finegan, 2012/10/10 08:26:06]

We have to pass a resource around with the info, and I thought it was cleaner to
wrap everything else up in a struct since passing PP_Resources around in a
struct is a bad idea.

Not sure if that justifies the type, or not. :)

[Ami GONE FROM CHROMIUM, 2012/10/10 18:06:45]

I don't understand; my proposal is that APIs that in your CL take a
PP_EncryptedMediaInfo should instead take both a PP_EncryptedBlockInfo and a
PP_StreamType.  Are you saying that doesn't work or is clunky for some reason?

[Tom Finegan, 2012/10/10 20:02:51]

I just thought it was nicer to keep the PP_StreamType and PP_EncryptedBlockInfo
together, but thinking about it some more I've changed my mind and removed
PP_EncryptedMediaInfo. Encryption and decoding are separate actions, and moving
decoder information in a unit with encryption information doesn't make as much
sense to me now as it did last night. I will drink more coffee tonight. :)

+ * decrypt and decode media data.
+ */
+[assert_size(248)]
+struct PP_EncryptedMediaInfo {
+  /**
+   * Media type of the encrypted data.
+   */
+  PP_StreamType media_type;
+
+  /**
+   * 4-byte padding to make the size of <code>PP_EncryptedMediaInfo</code>
+   * a multiple of 8 bytes and make sure |encryption_info| starts on an 8-byte
+   * boundary. The value of this field should not be used.

[Ami GONE FROM CHROMIUM, 2012/10/10 07:30:26]

Why does alignment matter?
(also, what makes you think the base will be 8-byte aligned on a 4-byte-word
arch?)

[Tom Finegan, 2012/10/10 08:26:06]

Fair point on alignment. I copied the comment from PP_DecryptedBlockInfo. The
main thing is that size is a multiple of 8 bytes so that PP_EncryptedMediaInfo
is the same size on all targets.

Fixed comment in both places. The padding is in the middle because we end up
with a 256 byte struct in MSVC when it's at the end.

+   */
+  uint32_t padding;
+
+  /**
+   * Information required to decrypt the media.
+   */
+   PP_EncryptedBlockInfo encryption_info;
+};
+
+/**
  * <code>PP_DecryptedFrameFormat</code> contains video frame formats.
  */
 [assert_size(4)]
 enum PP_DecryptedFrameFormat {
   PP_DECRYPTEDFRAMEFORMAT_UNKNOWN = 0,
   PP_DECRYPTEDFRAMEFORMAT_EMPTY = 1,
   PP_DECRYPTEDFRAMEFORMAT_YV12 = 2,
   PP_DECRYPTEDFRAMEFORMAT_I420 = 3
 };
 
 /**
  * <code>PP_VideoCodec</code> contains video codec type constants.
  */
 [assert_size(4)]
 enum PP_VideoCodec {
   PP_VIDEOCODEC_UNKNOWN = 0,
   PP_VIDEOCODEC_VP8 = 1
 };
 
 /**
- * <code>PP_EncryptedVideoFrameInfo</code> contains the information required
- * to decrypt and decode a video frame.
- * TODO(tomfinegan): Revisit necessity of including format information in this
- * struct once we decide how to implement video decoder initialization.
- */
-[assert_size(256)]
-struct PP_EncryptedVideoFrameInfo {
-  /**
-   * The decoded video frame format.
-   */
-  PP_DecryptedFrameFormat format;
-
-  /**
-   * The video frame codec type.
-   */
-  PP_VideoCodec codec;
-
-  /**
-   * Video frame width in pixels.
-   */
-  int32_t width;
-
-  /**
-   * Video frame height in pixels.
-   */
-  int32_t height;
-
-  /**
-   * Information required to decrypt the frame.
-   */
-  PP_EncryptedBlockInfo encryption_info;
-};
-
-/**
  * The <code>PP_DecryptResult</code> enum contains decryption and decoding
  * result constants.
  */
 [assert_size(4)]
 enum PP_DecryptResult {
   /** The decryption (and/or decoding) operation finished successfully. */
   PP_DECRYPTRESULT_SUCCESS = 0,
   /** The decryptor did not have the necessary decryption key. */
   PP_DECRYPTRESULT_DECRYPT_NOKEY = 1,
   /** An unexpected error happened during decryption. */
@@ skipping 72 matching lines @@
   /**
    * Height of the video frame, in pixels.
    */
   int32_t height;
 
   /**
    * Information needed by the client to track the decrypted frame.
    */
   PP_DecryptTrackingInfo tracking_info;
 };