Add CDM video decoder.

webkit/media/crypto/ppapi/ffmpeg_video_decoder.h

Index: webkit/media/crypto/ppapi/ffmpeg_video_decoder.h
diff --git a/webkit/media/crypto/ppapi/ffmpeg_video_decoder.h b/webkit/media/crypto/ppapi/ffmpeg_video_decoder.h
new file mode 100644
index 0000000000000000000000000000000000000000..0ea21db460eb36318209f3e79648ce96679fb419
--- /dev/null
+++ b/webkit/media/crypto/ppapi/ffmpeg_video_decoder.h
@@ -0,0 +1,64 @@
+// 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 WEBKIT_MEDIA_CRYPTO_PPAPI_FFMPEG_VIDEO_DECODER_H_
+#define WEBKIT_MEDIA_CRYPTO_PPAPI_FFMPEG_VIDEO_DECODER_H_
+
+#include "base/basictypes.h"
+#include "base/compiler_specific.h"
+#include "base/memory/ref_counted.h"
+#include "webkit/media/crypto/ppapi/content_decryption_module.h"
+
+struct AVCodecContext;
+struct AVFrame;
+
+namespace webkit_media {
+
+static const uint32_t kBufferAlignment = 32;

[ddorwin, 2012/10/13 03:54:42]

media/base has constants for these.

[Tom Finegan, 2012/10/13 23:47:26]

The only ones I can find are in .cc files. Should I move these to the file where
they are used?

+static const uint32_t kBufferPadBytes = kBufferAlignment - 1;
+static const int kDecodeThreads = 2;
+
+bool IsValidConfig(cdm::VideoFormat format, const cdm::Size& data_size);
+
+class FFmpegVideoDecoder {

[ddorwin, 2012/10/13 03:54:42]

I worry about having identically named classes and files. It may lead to
confusion when searching for code, etc.

[Tom Finegan, 2012/10/13 23:47:26]

Yeah, I use cs.chromium.org a lot... I can see that being a serious annoyance.
How about:

Rename classes to CdmFfmpegVideoDecoder and CdmVideoFrame
Rename files to cdm_ffmpeg_video_decoder and cdm_video_frame

Not sure if those are unique enough, and CdmVideoFrame might be confusing
because of cdm::VideoFrame.

+ public:
+  FFmpegVideoDecoder(cdm::Allocator* allocator);
+  ~FFmpegVideoDecoder();
+  bool Initialize(const cdm::VideoDecoderConfig& config);
+  void Deinitialize();
+  void Reset();
+
+

[ddorwin, 2012/10/13 03:54:42]

remove line

[Tom Finegan, 2012/10/13 23:47:26]

Done.

+  // Decodes |compressed_frame|, and stores decompressed frame in
+  //|decompressed_frame| when an output frame is available. Returns true when

[ddorwin, 2012/10/13 03:54:42]

param name does not match

[Tom Finegan, 2012/10/13 23:47:26]

Done.

+  // when successful.
+  // Note: This method can return true without providing an output frame. This

[ddorwin, 2012/10/13 03:54:42]

with a null |decoded_frame|.

[Tom Finegan, 2012/10/13 23:47:26]

Done.

+  // occurs when the decoder needs more data to produce an output video frame.
+  // Returns false upon failure.
+  bool DecodeFrame(const uint8_t* compressed_frame,
+                   int32_t frame_length,

[ddorwin, 2012/10/13 03:54:42]

compressed_frame_size?

[Tom Finegan, 2012/10/13 23:47:26]

Done.

+                   int64_t timestamp,
+                   cdm::VideoFrame* decoded_frame);

[ddorwin, 2012/10/13 03:54:42]

I think this CL shows we have a fundamental problem. VideoFrames are supposed to
always be allocated by the wrapper, BUT FFmpeg can provide data at any point. As
a result, we have an internal VideoFrame structure that stores a cdm::VideoFrame
(not allocated right now) that must be copied to this parameter.

Part of the problem is that FFmpeg is apparently multithreaded and we assumed
CDMs would not (need to) be. I guess we should support it, but that may mean
interface changes (unless we can use FFmpeg single-threaded).

I think a better solution might be to have Allocator return VideoFrames and make
this a double pointer. The only issue is that you'll need to keep track of all
the allocated frames, which you probably need to do in the current design.

[Tom Finegan, 2012/10/13 23:47:26]

The video frame memory is allocated using the allocator in GetVideoBuffer() (via
VideoFrame::Create()). We may need a lock in allocator (I think using the ppapi
lock util will break in process, though), or we can pass threads = 1 to ffmpeg.
That's going to hurt decode speed, but maybe it doesn't matter since this is
mainly for testing.

[Tom Finegan, 2012/10/14 00:41:11]

Actually, thinking about this some more, maybe this isn't going to work with the
calls to the allocator coming from a different thread. I'm not sure if that's
going to work. Maybe we have to run ffmpeg single threaded. 

+
+  // Callback called from within FFmpeg to allocate a buffer based on
+  // the dimensions of |codec_context|. See AVCodecContext.get_buffer
+  // documentation inside FFmpeg.
+  int GetVideoBuffer(AVCodecContext *codec_context, AVFrame* frame);

[ddorwin, 2012/10/13 03:54:42]

*<space>

[Tom Finegan, 2012/10/13 23:47:26]

Done.

+
+ private:
+  void ReleaseFFmpegResources();
+
+  // FFmpeg structures owned by this object.
+  AVCodecContext* codec_context_;
+  AVFrame* av_frame_;
+
+  cdm::Allocator* const allocator_;
+  cdm::VideoDecoderConfig config_;
+
+  DISALLOW_COPY_AND_ASSIGN(FFmpegVideoDecoder);
+};
+
+}  // namespace webkit_media
+
+#endif  // WEBKIT_MEDIA_CRYPTO_PPAPI_FFMPEG_VIDEO_DECODER_H_