Add CDM allocator interface.

webkit/media/crypto/ppapi/content_decryption_module.h

Index: webkit/media/crypto/ppapi/content_decryption_module.h
diff --git a/webkit/media/crypto/ppapi/content_decryption_module.h b/webkit/media/crypto/ppapi/content_decryption_module.h
index cb21258a6fb24feb19ab45813e34f3c15fb1082d..94e83a9e64d1c302dcfb804d26c90410d3a902c9 100644
--- a/webkit/media/crypto/ppapi/content_decryption_module.h
+++ b/webkit/media/crypto/ppapi/content_decryption_module.h
@@ -19,6 +19,10 @@ namespace cdm {
 class ContentDecryptionModule;
 }
 
+namespace webkit_media {
+class CdmAllocator;
+}
+
 extern "C" {
 CDM_EXPORT cdm::ContentDecryptionModule* CreateCdmInstance();
 CDM_EXPORT void DestroyCdmInstance(cdm::ContentDecryptionModule* instance);
@@ -121,16 +125,24 @@ struct OutputBuffer {
   OutputBuffer()
       : data(NULL),
         data_size(0),
-        timestamp(0) {}
+        timestamp(0),
+        buffer_id(0) {}
 
-  const uint8_t* data;  // Pointer to the beginning of the output data.
+  uint8_t* data;  // Pointer to the beginning of the output data.
   uint32_t data_size;  // Size (in bytes) of |data|.
 
   int64_t timestamp;  // Presentation timestamp in microseconds.
+  int32_t buffer_id;  // Buffer identifier. Issued by CdmAllocator, and used by

[ddorwin, 2012/09/04 09:53:15]

A buffer object (see comment) makes comment this simpler or unnecessary.

[ddorwin, 2012/09/05 13:44:51]

This comment is related to the comment at
http://codereview.chromium.org/10900007/diff/14001/webkit/media/crypto/ppapi/...

To clarify, replace data and buffer_id with the abstract buffer object.

Depending on whether the buffer object owns the data and how you implement
things, OutputBuffer may own the new object or have a copy or pointer to it. In
either case, this should hopefully clarify ownership of the buffer (currently a
pointer).

The caller to Decrypt() could have already instantiated the buffer object (as a
member of OutputBuffer) or the callee could assign the buffer object to a
pointer in OutputBuffer.

[Tom Finegan, 2012/09/07 00:46:36]

I've added CdmBuffer, but using a simple integer here seems simpler... at least,
with a simple integer, CdmBuffer doesn't need an assignment operator or a copy
contstructor (or a CopyFrom method, if that's preferred).

Should I make cdm_buffer source files, and add the above? As it is the whole
implementation is inline.

Maybe I've approached this the wrong way. CdmBuffer is not abstract at
present...

[ddorwin, 2012/09/07 09:48:48]

Yes, you'd copy 9 bytes, but that's fine, and the copy constructor and
assignment operator are free since it only has basic types. Note that copying is
fine because you're not (currently) storing the BufferDev in the CdmBuffer.
No, we just want one header file for the "public" interface.
Yes, please make it abstract.

[Tom Finegan, 2012/09/08 01:02:47]

Done. Allocator::Allocate now returns a cdm::Buffer* that is owned by
OutputBuffer. Should I make that an auto_ptr, or just leave it as a raw pointer
w/a delete in ~OutputBuffer?

+                      // the CDM wrapper.
 };
 
 class ContentDecryptionModule {
  public:
+  // Initializes the CDM by providing the allocator interface required for

[ddorwin, 2012/09/04 09:53:15]

The real issue is related to shared object boundary. shared memory is an
optimization.

[Tom Finegan, 2012/09/07 00:46:36]

Method removed.

+  // access to shared memory that can be passed to the browser. Returns
+  // true upon successful initialization, and false when |allocator| is NULL.

[ddorwin, 2012/09/04 09:53:15]

No reason for a return value or supporting NULL.

[Tom Finegan, 2012/09/07 00:46:36]

The constructor DCHECKs the pointer.

+  virtual bool Initialize(webkit_media::CdmAllocator* allocator) = 0;

[ddorwin, 2012/09/04 09:53:15]

Does it make sense to pass this to CreateCdmInstance()?

[Tom Finegan, 2012/09/07 00:46:36]

Yes, doing that now.

+
   // Generates a |key_request| given the |init_data|.
   // Returns kSuccess if the key request was successfully generated,
   // in which case the callee should have allocated memory for the output