Add PPAPI CDM video decoder initialization.

ppapi/api/private/pp_content_decryptor.idl

Index: ppapi/api/private/pp_content_decryptor.idl
diff --git a/ppapi/api/private/pp_content_decryptor.idl b/ppapi/api/private/pp_content_decryptor.idl
index 248b7356b2d29946e6c7b48f062ae3064d0d44f1..fc0cf85f5da753d6e82d6834130d12a9a9eb56fa 100644
--- a/ppapi/api/private/pp_content_decryptor.idl
+++ b/ppapi/api/private/pp_content_decryptor.idl
@@ -260,3 +260,55 @@ struct PP_DecryptedFrameInfo {
    */
   PP_DecryptTrackingInfo tracking_info;
 };
+
+/**
+ * <code>PP_VideoCodecProfile</code> contains video codec profile type
+ * constants required for video decoder configuration.
+ *.
+ */
+[assert_size(4)]
+enum PP_VideoCodecProfile {
+  PP_VIDEOCODECPROFILE_UNKNOWN = 0,

[Ami GONE FROM CHROMIUM, 2012/10/08 18:35:16]

Any reason not to use PP_VideoDecoder_Profile?

[Tom Finegan, 2012/10/08 23:23:27]

These types are based on those defined in media/video_decoder_config.h. I took
the names from their and stuck pepper prefixes on them. PP_VideoCodec and
PP_VideoCodecProfile seem to fit together, but if we only need a
PP_VideoDecoderProfile I would be fine w/that name and dropping the other type.

[Ami GONE FROM CHROMIUM, 2012/10/09 07:21:12]

So is the enum I pointed at (well, they grew together, but they're in sync).
We don't need the codec as a separate enum here for the same reason we don't
need it in HW-decode: the profile implies the codec.

+  PP_VIDEOCODECPROFILE_VP8_MAIN = 1
+};
+
+/**
+ * <code>PP_VideoDecoderConfig</code> contains video decoder configuration
+ * information required to initialize video decoders, and a request ID
+ * that allows clients to associate a decoder intialization request with a

[Ami GONE FROM CHROMIUM, 2012/10/08 18:35:16]

typo: intialization
(here and a surprising number of other times ;))

[Tom Finegan, 2012/10/08 23:23:27]

Thanks, fixed.

+ * status response.

[xhwang, 2012/10/08 17:16:13]

Add a comment here that the extra data is sent separately as a resource.

[Tom Finegan, 2012/10/08 23:23:27]

Done.

+ */
+[assert_size(24)]
+struct PP_VideoDecoderConfig {
+  /**
+   * The video codec to initialize.
+   */
+  PP_VideoCodec codec;
+
+  /**
+   * Profile to use when intializing the video codec.
+   */
+  PP_VideoCodecProfile profile;
+
+  /**
+   * Output video format.
+   */
+  PP_DecryptedFrameFormat format;
+
+  /**
+   * Width of decoded video frames, in pixels.
+   */
+  int32_t width;
+
+  /**
+   * Height of decoded video frames, in pixels.
+   */
+  int32_t height;
+
+  /**
+   * Client-specified identifier for the associated video decoder intialization

[Ami GONE FROM CHROMIUM, 2012/10/08 18:35:16]

I don't follow why this needs an extra id, over returning a resource ID and
making an async callback.
(like the way the reverse works in the PPB_VideoDecoder_Dev case)

[xhwang, 2012/10/08 19:00:35]

Originally request ID was added in Decrypt()/DeliverBlock() to support tracking
concurrent decrypt() calls (e.g. from video and audio streams). That reason
doesn't apply to this struct so I understand why you ask this question. By
acknowledging the fact that we only support at most one video and one audio
stream we can even remove the request ID for the Decrypt()/DeliverBlock() case.

However, I'd like to keep the request ID for all content decryption related
callbacks (including this one) if the operation needs to be cancelable.

In current media pipeline, when we reset/stop the video decoder and if there are
callbacks outstanding, the video decoder will try to cancel the operation and
wait for the callback to return before reset/stop can be finished. For example,
if the video decoder initialization is pending at the plugin, the video decoder
will call CancelDecryptAndDecodeVideo() trying to cancel the initialization.

I feel it'd be better to make the requests cancellable at the PluginInstance
than having to wait for the plugin or CDM to respond. It'll be unfortunate if
the mediapipeline tearing-down halts due to a malfunctioning/bad CDM
implementation (what if the plugin never returns our callback?). To make the
callbacks cancellable in PluginInstance, we need to keep track all callbacks we
sent out, and the request id serves this purpose.

+   * request. By using this value, the client can associate a decoder
+   * initialization status response with an intialization request.
+   */
+  uint32_t request_id;
+};