Add Mojo CDM Service.

media/mojo/interfaces/decryptor.mojom

+// Copyright 2014 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.
+
+module mojo;
+
+import "media/mojo/interfaces/demuxer_stream.mojom";
+import "media/mojo/interfaces/media_types.mojom";
+
+// TODO(xhwang): Add mojo types for AudioBuffer and VideoFrame.
+struct AudioBuffer {};
+struct VideoFrame {};
+
+// Interface for decrypting (and decoding) encrypted streams.
+// See media/base/decryptor.h for details.
+// TODO(xhwang): Canceling/resetting is messy. Clean this up later. For now,
+// make this interface as close as media::Decryptor.

[ddorwin, 2014/12/08 23:46:48]

nit: missing words

[xhwang, 2014/12/10 04:59:16]

Dropped. We may want to clean up decryptor.h at some point.

+[Client=DecryptorClient]
+interface Decryptor {
+  // Status of a decrypt or a decrypt-and-decode operation. The returned

[ddorwin, 2014/12/08 23:46:48]

nit: drop second "a"

[xhwang, 2014/12/10 04:59:16]

Done.

+  // buffer/frame of such an operation is NOT null iff the status is SUCCESS.
+  enum Status {
+    SUCCESS,  // Successfully completed. Decrypted buffer ready.
+    NO_KEY,  // No key is available to decrypt.
+    NEED_MORE_DATA,  // Decoder needs more data to produce an output.
+    ERROR  // Key is available but an error occurred during decryption.

[ddorwin, 2014/12/08 23:46:49]

OOC, this always results in DECODE_ERROR, right?

[xhwang, 2014/12/10 04:59:16]

Yes.

+  };
+
+  // Decrypts the |encrypted| buffer and returns the decrypt |status| and
+  // decrypted |buffer|.
+  // At most one decrypt call is allowed at any time for a |stream_type|.

[ddorwin, 2014/12/08 23:46:48]

We should replace stream_type with IDs before this interface becomes "stable."

[xhwang, 2014/12/10 04:59:16]

Hmm, but the calls are different on different stream types.

[ddorwin, 2014/12/12 19:25:13]

Decrypt callbacks aren't, right?

What I'm really saying is that we should not assume there is only a single
stream of each type before we expose this to apps other than Chromium. That's
one thing we know _could_ change in the future.

[xhwang, 2014/12/12 23:15:44]

I see. Let's iterate on this later. We can update the C++ and mojo interfaces
together.

+  Decrypt(DemuxerStream.Type stream_type, MediaDecoderBuffer encrypted)
+      => (Status status, MediaDecoderBuffer? buffer);
+
+  // Cancels any pending decrypt for |stream_type| with SUCCESS.
+  CancelDecrypt(DemuxerStream.Type stream_type);
+
+  // Initializes a decoder with the given |config|. Returns whether the
+  // initialization succeeded.
+  InitializeAudioDecoder(AudioDecoderConfig config) => (bool success);
+  InitializeVideoDecoder(VideoDecoderConfig config) => (bool success);
+
+  // Decrypts and decodes the |encrypted| buffer and returns the |status| and
+  // the decrypted |audio_buffers| or |video_frame|.
+  // At end-of-stream, this method should be called repeatedly with
+  // end-of-stream |encrypted| until no buffer/frame can be produced.
+  // These methods can only be called after the corresponding decoder has
+  // been successfully initialized.
+  // At most one decrypt-and-decode call is allowed at any time for a

[ddorwin, 2014/12/08 23:46:49]

Are D and D&D calls also mutually-exclusive?

[xhwang, 2014/12/10 04:59:16]

That's a grey area. We never do it in our code. But in theory, I don't see why a
CDM can't support D and D&D calls at the same time.

[ddorwin, 2014/12/12 19:25:12]

Perhaps per stream ID (if we supported multiple). In that case, I think we'd
also need to pass an ID here.

[xhwang, 2014/12/12 23:15:44]

Acknowledged.

+  // |stream_type|.
+  DecryptAndDecodeAudio(MediaDecoderBuffer encrypted)
+      => (Status status, array<AudioBuffer>? audio_buffers);
+  DecryptAndDecodeVideo(
+      MediaDecoderBuffer encrypted) => (Status status, VideoFrame? video_frame);
+
+  // Resets the decoder for |stream_type| to a clean initialized state, cancels

[ddorwin, 2014/12/08 23:46:48]

nit: s/,/and/

[xhwang, 2014/12/10 04:59:16]

Done.

+  // any pending decrypt-and-decode operations immediately with ERROR.
+  // This method can only be called after the corresponding decoder has been
+  // successfully initialized.
+  ResetDecoder(DemuxerStream.Type stream_type);
+
+  // Releases decoder resources, deinitializes the decoder, aborts any pending
+  // initialization (with false) or decrypt-and-decode (with ERROR) for
+  // |stream_type| immediately.
+  // This method can be called any time after Initialize{Audio|Video}Decoder()
+  // has been called (with the correct stream type).
+  // After this operation, the decoder is set to an uninitialized state.
+  // The decoder can be reinitialized after it is deinitialized.
+  DeinitializeDecoder(DemuxerStream.Type stream_type);

[ddorwin, 2014/12/08 23:46:48]

Do we want this to be sync? Same for ResetDecoder.

[xhwang, 2014/12/10 04:59:16]

This is how things work now. Non of our CDM/decoders need an async
Reset/Deinitialize.

+};
+
+interface DecryptorClient {
+  // Indicates that a new usable key is available in the CDM associated with the

[ddorwin, 2014/12/08 23:46:48]

I don't think we need this (and it seems like the wrong direction).

[xhwang, 2014/12/10 04:59:16]

The client needs a way to retry. This is the replacement of the
Decryptor::NewKeyCB.

+  // Decryptor.
+  OnNewUsableKey();
+};