Add PPAPI CDM video decoder initialization.

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 110 matching lines @@
   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 {

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

can probably drop this (see comment below).

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

We'll need both when we support H.264-- I think we should keep both structs. We
need both to initialize a H.264 decoder, right?

   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.
  */
@@ skipping 111 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;
 };
+
+/**
+ * <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;
+};