EVEA cleanup: use video utility functions in media::*

content/browser/renderer_host/media/video_capture_buffer_pool.cc

Index: content/browser/renderer_host/media/video_capture_buffer_pool.cc
diff --git a/content/browser/renderer_host/media/video_capture_buffer_pool.cc b/content/browser/renderer_host/media/video_capture_buffer_pool.cc
index 207f86a99f3df42cea42f8402ddaf3dacdd2f856..f8d3a25e5a2e03b9f66cf5e1e3911e04cf5b925d 100644
--- a/content/browser/renderer_host/media/video_capture_buffer_pool.cc
+++ b/content/browser/renderer_host/media/video_capture_buffer_pool.cc
@@ -128,8 +128,10 @@ int VideoCaptureBufferPool::RecognizeReservedBuffer(
 scoped_refptr<media::VideoFrame> VideoCaptureBufferPool::ReserveI420VideoFrame(
     const gfx::Size& size,
     int rotation) {
-  if (static_cast<size_t>(size.GetArea() * 3 / 2) != GetMemorySize())
+  if (GetMemorySize() !=
+      media::VideoFrame::AllocationSize(media::VideoFrame::I420, size)) {

[Ami GONE FROM CHROMIUM, 2013/08/26 22:00:23]

Is this a programming error and thus worthy of a DCHECK before the return NULL?

[sheu, 2013/08/27 22:05:56]

Not an error during midstream resolution changes.

[Ami GONE FROM CHROMIUM, 2013/08/27 23:57:08]

VCBP doesn't support midstream resolution changes (ncarter@ is working on that,
but it's a huge project).  Can you actually make a DCHECK here trigger?
(because if you can, then we have bigger fish to fry, and if you can't, IWBN to
avoid giving the impression that this class can handle more than it in fact can)

[sheu, 2013/08/28 00:03:59]

Done.

     return NULL;
+  }
 
   base::AutoLock lock(lock_);
 
@@ -151,6 +153,7 @@ scoped_refptr<media::VideoFrame> VideoCaptureBufferPool::ReserveI420VideoFrame(
           gfx::Rect(size),
           size,
           static_cast<uint8*>(buffer->shared_memory.memory()),
+          GetMemorySize(),
           buffer->shared_memory.handle(),
           base::TimeDelta(),
           disposal_handler);