Add support for encrypted WebM files as defined in the RFC.

media/base/decrypt_config.h

 // 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.
 
 #ifndef MEDIA_BASE_DECRYPT_CONFIG_H_
 #define MEDIA_BASE_DECRYPT_CONFIG_H_
 
 #include "base/basictypes.h"
 #include "base/memory/scoped_ptr.h"
 #include "media/base/media_export.h"
 
 namespace media {
 
-// Contains all information that a decryptor needs to decrypt.
+// Contains all information that a decryptor needs to decrypt a frame.
 class MEDIA_EXPORT DecryptConfig {
  public:
-  explicit DecryptConfig(const uint8* key_id, int key_id_size);
+  DecryptConfig(const uint8* data_to_verify, int data_to_verify_size,

[ddorwin, 2012/07/10 01:12:20]

It's not obvious what's being passed here. I think a comment block explaining
the values would be helpful.
Also, maybe move these after key_id_size so all the "data"/offset values are
together.
It's probably worth noting that this class does not take ownership of the
pointers / copies the data. (I initially thought it did take ownership of them
based on the member types below.)

[ddorwin, 2012/07/11 01:00:27]

I now realize that offset_to_data is completely unrelated to data_to_verify, so
keeping them apart is good. However, it's clear we need to fix the naming
(offset_to_data_in_decoder_buffer is long but what it really means). SringPiece
might also help (me) avoid thinking that the former indexes into the latter.

[fgalligan1, 2012/07/11 22:06:33]

Done.

[fgalligan1, 2012/07/11 22:06:33]

I want to keep them separate wrt to the decryptor as it shouldn't think the 2
values are correlated.
What about the new names?

+                const uint8* iv, int iv_size,
+                const uint8* key_id, int key_id_size,
+                int offset_to_data);

[ddorwin, 2012/07/10 01:12:20]

offset_to_frame? encrypted_data_offset?
It's unclear what this means and how it relates to the first parameter

[fgalligan1, 2012/07/11 22:06:33]

It actually shouldn't relate to the first parameter wrt the decryptor. The first
parameter is a checksum of the encrypted buffer. The last parameter is offset
into the encrypted buffer the encrypted frame starts. wrt the decryptor it
doesn't care about any data that is skipped over (with the latest patch). I
think the latest patch makes things clearer. If not let me know.

   ~DecryptConfig();
 
+  const uint8* data_to_verify() const { return data_to_verify_.get(); }
+  int data_to_verify_size() const { return data_to_verify_size_; }
+  const uint8* iv() const { return iv_.get(); }
+  int iv_size() const { return iv_size_; }
   const uint8* key_id() const { return key_id_.get(); }
   int key_id_size() const { return key_id_size_; }
+  int offset_to_data() const { return offset_to_data_; }
 
  private:
+  // Data to be verified before decrypting the data. This may be set to NULL
+  // for some formats.
+  scoped_array<uint8> data_to_verify_;
+  int data_to_verify_size_;
+
+  // Initialization vector.
+  scoped_array<uint8> iv_;
+  int iv_size_;
+
   scoped_array<uint8> key_id_;
   int key_id_size_;
 
+  // This is is the offset in bytes to where the encrypted data starts within
+  // the input buffer.
+  int offset_to_data_;
+
   DISALLOW_COPY_AND_ASSIGN(DecryptConfig);
 };
 
 }  // namespace media
 
 #endif  // MEDIA_BASE_DECRYPT_CONFIG_H_