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

media/filters/pipeline_integration_test.cc

Index: media/filters/pipeline_integration_test.cc
diff --git a/media/filters/pipeline_integration_test.cc b/media/filters/pipeline_integration_test.cc
index 6817505b785b5cbbe931769d89e14a83405a86ef..cd2ec18accca38fa6cf9baa1c3cfaa77b3a32987 100644
--- a/media/filters/pipeline_integration_test.cc
+++ b/media/filters/pipeline_integration_test.cc
@@ -18,6 +18,12 @@ static const char kSourceId[] = "SourceId";
 static const char kClearKeySystem[] = "org.w3.clearkey";
 static const uint8 kInitData[] = { 0x69, 0x6e, 0x69, 0x74 };
 
+// Key used to encrypt video track in test file "bear-320x240-encrypted.webm".
+static const uint8 kKey[] = {

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

secret key or encryption key?

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

Done.

+  0x5b, 0x4e, 0xe8, 0xb6, 0xd0, 0x7e, 0x4e, 0x58, 0xea, 0x24, 0x4c, 0x40, 0x13,
+  0xfd, 0xb5, 0x2d
+};

[xhwang, 2012/07/10 06:31:25]

Here and in other unittests:
Can we have 8 or 12 numbers per line instead of 13? It's hard to know how many
bytes are there in the array. I found that in most crypto:: unit tests, they use
8 numbers per line (e.g.
http://code.google.com/searchframe#OAMlx_jo-ck/src/crypto/p224_unittest.cc&l=16).
I also see some cases with 12 numbers per line but it's rare.

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

Done.

+
 // Helper class that emulates calls made on the ChunkDemuxer by the
 // Media Source API.
 class MockMediaSource : public ChunkDemuxerClient {
@@ -96,7 +102,7 @@ class MockMediaSource : public ChunkDemuxerClient {
   virtual void DemuxerNeedKey(scoped_array<uint8> init_data,
                               int init_data_size) {
     DCHECK(init_data.get());
-    DCHECK_EQ(init_data_size, 16);
+    DCHECK_GT(init_data_size, 0);

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

For WebM, why isn't it a fixed size?

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

ContentEncKeyID is a binary element. I just didn't put a size in the WebM spec
because I didn't think it needed one. Are you thinking we should put a max size?
We can also put an explicit size, maybe that will prevent issues later.

[ddorwin, 2012/07/13 00:48:00]

Oh, this is fine then.
I don't recall whether the other code handles variable size keys. Does it? (I
know the tests use 16.) If we do support other sizes, we should have a test.

     DCHECK(decryptor_client_);
     decryptor_client_->NeedKey("", "", init_data.Pass(), init_data_size);
   }
@@ -166,9 +172,7 @@ class FakeDecryptorClient : public DecryptorClient {
 
     EXPECT_FALSE(current_key_system_.empty());
     EXPECT_FALSE(current_session_id_.empty());
-    // In test file bear-320x240-encrypted.webm, the decryption key is equal to
-    // |init_data|.
-    decryptor_.AddKey(current_key_system_, init_data.get(), init_data_length,
+    decryptor_.AddKey(current_key_system_, kKey, arraysize(kKey),
                       init_data.get(), init_data_length, current_session_id_);
   }
 
@@ -263,7 +267,9 @@ TEST_F(PipelineIntegrationTest, BasicPlaybackHashed) {
   EXPECT_EQ(GetAudioHash(), "6138555be3389e6aba4c8e6f70195d50");
 }
 
-TEST_F(PipelineIntegrationTest, EncryptedPlayback) {
+// TODO(fgalligan): Enable test when encrypted test data is updated and new
+// decryption code is landed. http://crbug.com/132801
+TEST_F(PipelineIntegrationTest, DISABLED_EncryptedPlayback) {
   MockMediaSource source("bear-320x240-encrypted.webm", 219726, true, true);
   FakeDecryptorClient encrypted_media;
   StartPipelineWithEncryptedMedia(&source, &encrypted_media);