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

ppapi/c/private/pp_decrypt_config.h

Index: ppapi/c/private/pp_decrypt_config.h
diff --git a/ppapi/c/private/pp_decrypt_config.h b/ppapi/c/private/pp_decrypt_config.h
new file mode 100644
index 0000000000000000000000000000000000000000..66cb6e39136bbf21b0e44935767a1b4af7751ba8
--- /dev/null
+++ b/ppapi/c/private/pp_decrypt_config.h
@@ -0,0 +1,131 @@
+/* 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.
+ */
+
+/* From private/pp_decrypt_config.idl modified Thu Aug 16 13:06:53 2012. */
+
+#ifndef PPAPI_C_PRIVATE_PP_DECRYPT_CONFIG_H_
+#define PPAPI_C_PRIVATE_PP_DECRYPT_CONFIG_H_
+
+#include "ppapi/c/pp_macros.h"
+#include "ppapi/c/pp_stdint.h"
+
+/**
+ * @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.
+ */
+
+
+/**
+ * @addtogroup Structs
+ * @{
+ */
+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;
+  /**
+   * 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
+   * order.
+   */
+  int64_t timestamp;
+};
+PP_COMPILE_ASSERT_STRUCT_SIZE_IN_BYTES(PP_DecryptTrackingInfo, 16);
+
+/**
+ * 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
+ * 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  |
+ */
+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;
+};
+PP_COMPILE_ASSERT_STRUCT_SIZE_IN_BYTES(PP_DecryptSubsampleDescription, 8);
+
+/**
+ * The <code>PP_DecryptConfig</code> struct contains all information needed to
+ * decrypt an encrypted buffer.
+ */
+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.
+   */
+  struct 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 key_id[64];
+  uint32_t key_id_size;
+  /**
+   * Initialization vector of the buffer to be decrypted.
+   */
+  uint8_t iv[16];
+  uint32_t iv_size;
+  /**
+   * Checksum of the buffer to be decrypted.
+   */
+  uint8_t checksum[12];
+  uint32_t checksum_size;
+  /**
+   * Subsample information of the buffer to be decrypted.
+   */
+  struct PP_DecryptSubsampleDescription subsamples[16];
+  uint32_t num_subsamples;
+};
+PP_COMPILE_ASSERT_STRUCT_SIZE_IN_BYTES(PP_DecryptConfig, 256);
+/**
+ * @}
+ */
+
+#endif  /* PPAPI_C_PRIVATE_PP_DECRYPT_CONFIG_H_ */
+