Implementation for Pepper C++ Video Decoder API (wrapper on top of C API).

ppapi/cpp/dev/video_decoder_dev.h

Index: ppapi/cpp/dev/video_decoder_dev.h
diff --git a/ppapi/cpp/dev/video_decoder_dev.h b/ppapi/cpp/dev/video_decoder_dev.h
index ba29abadcd285efebd69e65036d96fc169a21696..029032bbda41444b9740108286ee6f9c294ef11d 100644
--- a/ppapi/cpp/dev/video_decoder_dev.h
+++ b/ppapi/cpp/dev/video_decoder_dev.h
@@ -57,23 +57,24 @@ class VideoDecoder : public Resource {
   //  |callback| will be called when decoder is initialized.
   //  |client| is the pointer to the client object. Ownership of the object is
   //  not transferred and it must outlive the lifetime of this class.
-  VideoDecoder(const Instance* instance, const std::vector<uint32_t>& config,
+  VideoDecoder(const Instance* instance,
+               PP_VideoConfigElement* config,

[Ami GONE FROM CHROMIUM, 2011/06/01 18:26:28]

should be const*

[Ville-Mikko Rautio, 2011/06/03 09:26:05]

Done.

                CompletionCallback callback, Client* client);
   ~VideoDecoder();
 
   // GetConfigs returns supported configurations that are subsets of given
   // |prototype_config|.
-  static std::vector<uint32_t> GetConfigs(
-      Instance* instance,
-      const std::vector<uint32_t>& prototype_config);
+  bool GetConfigs(Instance* instance,
+                  const PP_VideoConfigElement* prototype_config,
+                  PP_VideoConfigElement* matching_configs,
+                  uint32_t matching_configs_size,
+                  uint32_t* num_of_matching_configs);

[Ami GONE FROM CHROMIUM, 2011/06/01 18:26:28]

I've been confused about this API for the last 24h or so, probably because of
the pluralization of the names.

prototype_config is a single array of different config options, so they are
presumably all orthogonal to each other.

matching_configs is a plural, which makes me think that possibly more than one
matching sets of configurations will be returned.  But the type is PP_VCE*, not
PP_VCE** or some other double-array mechanism.  Is the expectation that
*matching_configs will be laid out with the different config sets back-to-back,
and *num_of_matching_configs is used to figure out whether a TERMINATOR is the
last config element or whether another configset follows?

[Ville-Mikko Rautio, 2011/06/03 09:26:05]

Yes, that is the idea.
Exactly like this.

 
   // Provides the decoder with picture buffers for video decoding.
   // AssignGLESBuffers provides texture-backed buffers, whereas
   // AssignSysmemBuffers provides system memory-backed buffers.
-  void AssignGLESBuffers(uint32_t no_of_buffers,
-                         const PP_GLESBuffer_Dev& buffers);
-  void AssignSysmemBuffers(uint32_t no_of_buffers,
-                           const PP_SysmemBuffer_Dev& buffers);
+  void AssignGLESBuffers(const std::vector<PP_GLESBuffer_Dev>& buffers);
+  void AssignSysmemBuffers(const std::vector<PP_SysmemBuffer_Dev>& buffers);
 
   // Decodes given bitstream buffer. Once decoder is done with processing
   // |bitstream_buffer| is will call |callback| with provided user data.