Add content decryptor related structs and update PP{P|B}_ContentDecryptor_Private.

ppapi/api/private/pp_decrypt_config.idl

Index: ppapi/api/private/pp_decrypt_config.idl
diff --git a/ppapi/api/private/pp_decrypt_config.idl b/ppapi/api/private/pp_decrypt_config.idl
new file mode 100644
index 0000000000000000000000000000000000000000..d61f80136a602e3f845d05f07c574a0fb8a70294
--- /dev/null
+++ b/ppapi/api/private/pp_decrypt_config.idl
@@ -0,0 +1,117 @@
+/* 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 data with a decrypt request
+ * and/or an input buffer.
+ */
+[assert_size(16)]
+struct PP_DecryptTrackingInfo {
+  /**
+   * Client-specified identifier for the associated decrypt request. By using
+   * this value, the client can associate the decrypted data with a decryption
+   * request.
+   */
+  uint64_t request_id;

[ddorwin, 2012/08/16 23:56:05]

This is only used for decrypt (no decode), right? If so, couldn't we just use
timestamp in all cases? All blocks have a timestamp, right?
The fact that I had to write "and not in response to the request_id they were
provided with" below makes me question again the use of a request_id instead of
an enum. Fine for now I guess.

[xhwang, 2012/08/17 01:00:35]

Even with decode, we still need to find the right callback to fire. I'll think
about enum more but I'd land this first.

+
+  /**
+   * Timestamp in microseconds of the associated buffer. By using this value,
+   * the client can associate the decrypted (and decoded) data with an input
+   * buffer. This is needed because the decoded buffers can be out of the input

[ddorwin, 2012/08/16 23:56:05]

... buffers may be delivered out of order and not in response to the request_id
they were provided with.

[xhwang, 2012/08/17 01:00:35]

Done.

+   * order.
+   */
+  int64_t timestamp;
+};
+
+/**
+ * The <code>PP_DecryptSubsampleDescription</code> struct contains information
+ * to support subsample decryption.
+ *
+ * An input buffer can be split into several continuous subsamples.
+ * A <code>PP_DecryptSubsampleEntry</code> specifies the number of clear and
+ * cipher bytes in each subsample. For example, the following buffer has three
+ * subsamples:
+ *
+ * |<----- subsample1 ----->|<----- subsample2 ----->|<----- subsample3 ----->|
+ * |   clear1   |  cipher1  |  clear2  |   cipher2   | clear3 |    cipher3    |
+ *
+ * For decryption, all of the cipher bytes in a buffer should be treated as a
+ * continuous (in the subsample order) logical stream. The clear bytes should

[dmichael (off chromium), 2012/08/16 22:26:51]

continuous->contiguous?

[xhwang, 2012/08/17 01:00:35]

Done.

+ * not be considered as part of decryption.
+ *
+ * Logical stream to decrypt:   |  cipher1  |   cipher2   |    cipher3    |
+ * Decrypted stream:            | decrypted1|  decrypted2 |   decrypted3  |
+ *
+ * After decryption, the decrypted bytes should be copied over the position
+ * of the corresponding cipher bytes in the original buffer to form the output
+ * buffer. Following the above example, the decrypted buffer should be:
+ *
+ * |<----- subsample1 ----->|<----- subsample2 ----->|<----- subsample3 ----->|
+ * |   clear1   | decrypted1|  clear2  |  decrypted2 | clear3 |   decrypted3  |
+ */
+[assert_size(8)]
+struct PP_DecryptSubsampleDescription {
+  /**
+   * Size in bytes of clear data in a subsample entry.
+   */
+  uint32_t clear_bytes;
+
+  /**
+   * Size in bytes of encrypted data in a subsample entry.
+   */
+  uint32_t cipher_bytes;
+};
+
+/**
+ * The <code>PP_DecryptConfig</code> struct contains all information needed to
+ * decrypt an encrypted buffer.
+ */
+[assert_size(256)]
+struct PP_DecryptConfig {
+  /**
+   * Information needed by the client to track the buffer to be decrypted.
+   *
+   * TODO(xhwang): Consider moving this out of <code>PP_DecryptConfig</code>
+   * since strictly speaking it's not a part of the decrypt config. Keep it
+   * here for now because there is a limit of 5 parameters in the IPC message
+   * so we don't want to pass too many parameters in the Decrypt() calls.
+   */
+  PP_DecryptTrackingInfo tracking_info;
+
+  /**
+   * Size in bytes of data to be discarded before applying the decryption.
+   */
+  uint32_t data_offset;
+
+  /**
+   * Key ID of the buffer to be decrypted.
+   *
+   * TODO(xhwang): For WebM the key ID can be as large as 2048 bytes in theory.
+   * But it's not used in current implementations. If we really need to support
+   * it, we should move key ID out as a separate parameter, e.g. as PP_Var, or
+   * make the whole PP_DecryptConfig as a PP_Resource.
+   */
+  uint8_t[64] key_id;
+  uint32_t key_id_size;
+
+  /**
+   * Initialization vector of the buffer to be decrypted.
+   */
+  uint8_t[16] iv;
+  uint32_t iv_size;
+
+  /**
+   * Checksum of the buffer to be decrypted.
+   */
+  uint8_t[12] checksum;
+  uint32_t checksum_size;
+
+  /**
+   * Subsample information of the buffer to be decrypted.
+   */
+  PP_DecryptSubsampleDescription[16] subsamples;
+  uint32_t num_subsamples;
+};