diff options
author | xhwang@chromium.org <xhwang@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-10-18 20:05:42 +0000 |
---|---|---|
committer | xhwang@chromium.org <xhwang@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-10-18 20:05:42 +0000 |
commit | a1608f162b6cc3927dd10f5cf20b6a2037ba0cb9 (patch) | |
tree | c6cb71c586dcecf01b81679a054c02ab7d9dd3ec /webkit/media/crypto/ppapi/clear_key_cdm.cc | |
parent | 368ae3a1e123dbf8b5658d135132a549a0180e57 (diff) | |
download | chromium_src-a1608f162b6cc3927dd10f5cf20b6a2037ba0cb9.zip chromium_src-a1608f162b6cc3927dd10f5cf20b6a2037ba0cb9.tar.gz chromium_src-a1608f162b6cc3927dd10f5cf20b6a2037ba0cb9.tar.bz2 |
Update Decryptor interface to support audio decoding.
We were discussing the use of
decryptor_->DeinitializeDecoder(Decryptor::kVideo);
- vs -
decryptor_->DeinitializeVideoDecoder();
I choose to use parameterized methods so that we have less code (duplication). The non-parameterized methods are cleaner for callers. But I feel the former is slightly better in general.
Later on we'll have two Decryptors (ProxyDecryptor will not be a Decryptor anymore):
1) AesDecryptor, which doesn't care the stream type at all, not even for CancelDecrypt().
2) PpapiDecryptor, which merely passes similar calls to the PluginInstance which then make similar PPP calls. It seems to me that for passing calls it's slightly cleaner to use parameterized methods. Also we have parameterized PPP calls already for the same reason (less functions through multiple layers).
So in both cases, using parameterized methods results in less code.
It's unfortunate that InitializeXXXDecoder and DecryptAndDecodeXXX are exceptions, due to different types they take/return.
BUG=123421
TEST=media_unittest, content_unittest
Review URL: https://chromiumcodereview.appspot.com/11144036
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@162768 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'webkit/media/crypto/ppapi/clear_key_cdm.cc')
-rw-r--r-- | webkit/media/crypto/ppapi/clear_key_cdm.cc | 11 |
1 files changed, 7 insertions, 4 deletions
diff --git a/webkit/media/crypto/ppapi/clear_key_cdm.cc b/webkit/media/crypto/ppapi/clear_key_cdm.cc index af526c9..b007e94 100644 --- a/webkit/media/crypto/ppapi/clear_key_cdm.cc +++ b/webkit/media/crypto/ppapi/clear_key_cdm.cc @@ -213,7 +213,9 @@ cdm::Status ClearKeyCdm::Decrypt( // Callback is called synchronously, so we can use variables on the stack. media::Decryptor::Status status; scoped_refptr<media::DecoderBuffer> buffer; - decryptor_.Decrypt(decoder_buffer, + // We don't care what stream type it is here. So just pick video. + decryptor_.Decrypt(media::Decryptor::kVideo, + decoder_buffer, base::Bind(&CopyDecryptResults, &status, &buffer)); if (status == media::Decryptor::kError) @@ -267,7 +269,8 @@ cdm::Status ClearKeyCdm::DecryptAndDecodeFrame( // Callback is called synchronously, so we can use variables on the stack. media::Decryptor::Status status; scoped_refptr<media::DecoderBuffer> buffer; - decryptor_.Decrypt(decoder_buffer, + decryptor_.Decrypt(media::Decryptor::kVideo, + decoder_buffer, base::Bind(&CopyDecryptResults, &status, &buffer)); if (status == media::Decryptor::kError) @@ -295,8 +298,8 @@ void ClearKeyCdm::GenerateFakeVideoFrame(base::TimeDelta timestamp, int width = video_size_.width; int height = video_size_.height; - DCHECK(width % 2 == 0); - DCHECK(height % 2 == 0); + DCHECK_EQ(width % 2, 0); + DCHECK_EQ(height % 2, 0); int y_stride = (width + kAlignment - 1) / kAlignment * kAlignment + kPadding; int uv_stride = |