Define EncodedVideoSource and RtcCapturedEncodingVideoCapturer.

content/renderer/media/video_capture_impl.cc

 // 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.
 
 #include "content/renderer/media/video_capture_impl.h"
 
 #include "base/bind.h"
+#include "base/callback_helpers.h"
 #include "base/stl_util.h"
 #include "content/child/child_process.h"
+#include "content/common/media/encoded_video_capture_messages.h"
 #include "content/common/media/video_capture_messages.h"
 #include "media/base/limits.h"
 
 namespace content {
 
 struct VideoCaptureImpl::DIBBuffer {
  public:
   DIBBuffer(
       base::SharedMemory* d,
       media::VideoCapture::VideoFrameBuffer* ptr)
@@ skipping 31 matching lines @@
     base::MessageLoopProxy* capture_message_loop_proxy,
     VideoCaptureMessageFilter* filter)
     : VideoCapture(),
       message_filter_(filter),
       capture_message_loop_proxy_(capture_message_loop_proxy),
       io_message_loop_proxy_(ChildProcess::current()->io_message_loop_proxy()),
       device_id_(0),
       video_type_(media::VideoCaptureCapability::kI420),
       device_info_available_(false),
       suspended_(false),
-      state_(VIDEO_CAPTURE_STATE_STOPPED) {
+      state_(VIDEO_CAPTURE_STATE_STOPPED),
+      bitstream_buffer_size_(0) {
   DCHECK(filter);
   memset(&current_params_, 0, sizeof(current_params_));
   memset(&device_info_, 0, sizeof(device_info_));
   current_params_.session_id = id;
 }
 
 VideoCaptureImpl::~VideoCaptureImpl() {
   STLDeleteValues(&cached_dibs_);
 }
 
@@ skipping 22 matching lines @@
       base::Bind(&VideoCaptureImpl::DoStartCaptureOnCaptureThread,
                  base::Unretained(this), handler, capability));
 }
 
 void VideoCaptureImpl::StopCapture(media::VideoCapture::EventHandler* handler) {
   capture_message_loop_proxy_->PostTask(FROM_HERE,
       base::Bind(&VideoCaptureImpl::DoStopCaptureOnCaptureThread,
                  base::Unretained(this), handler));
 }
 
+void VideoCaptureImpl::RequestCapabilities(
+    const media::EncodedVideoSource::RequestCapabilitiesCallback& callback) {
+  DCHECK(callback_.is_null());
+  callback_ = callback;
+
+  // Invoke callback immediately if capabilities are already available.
+  if (!capabilities_.empty())
+    base::ResetAndReturn(&callback_).Run(capabilities_);
+}
+
+void VideoCaptureImpl::StartFetchCapabilities() {
+  Send(new EncodedVideoCaptureHostMsg_GetCapabilities(device_id_));
+}
+
+void VideoCaptureImpl::OpenBitstream(
+    media::EncodedVideoSource::Client* client,
+    const media::VideoEncodingParameters& params) {
+  DCHECK(!client_);
+  client_ = client;
+  Send(new EncodedVideoCaptureHostMsg_OpenBitstream(device_id_, params));
+}
+
+void VideoCaptureImpl::CloseBitstream() {
+  Send(new EncodedVideoCaptureHostMsg_CloseBitstream(device_id_));
+  client_ = NULL;
+}
+
+void VideoCaptureImpl::ReturnBitstreamBuffer(
+    scoped_refptr<const media::EncodedBitstreamBuffer> buffer) {
+  Send(new EncodedVideoCaptureHostMsg_BitstreamBufferConsumed(
+      device_id_, buffer->buffer_id()));
+}
+
+void VideoCaptureImpl::TrySetBitstreamConfig(
+    const media::RuntimeVideoEncodingParameters& params) {
+  Send(new EncodedVideoCaptureHostMsg_TryConfigureBitstream(
+      device_id_, params));
+}
+
+void VideoCaptureImpl::OnEncodingCapabilitiesAvailable(
+    const media::VideoEncodingCapabilities& capabilities) {
+  capabilities_ = capabilities;

[sheu, 2013/06/12 22:35:05]

This is why we do that little trampoline thing through
capture_message_loop_proxy_.

VideoCaptureMessageFilter is registered on io_message_loop_proxy_, so we get the
callback here on io_message_loop_proxy_, and set capabilities_ accordingly.

At the same time, in RequestCapabilities(), we're accessing capability_ on
another thread, possibly the capture_message_loop_proxy_ (or something else). 
We've got a data race here.

You're going to have to make sure the callback_ also gets called on the correct
thread.

[hshi1, 2013/06/13 00:25:31]

I've changed this so that we always update capabilities_ and invoke callback on
the capture thread. However I believe that for the renderer->browser IPCs such
as Open/Close Bistream and TrySetConfig, it is safe to directly post IPC to IO
thread.

+  if (!callback_.is_null())
+    base::ResetAndReturn(&callback_).Run(capabilities_);
+}
+
+void VideoCaptureImpl::OnEncodedBitstreamOpened(
+    const media::VideoEncodingParameters& params,
+    const std::vector<base::SharedMemoryHandle>& buffers,
+    int buffer_size) {
+  capture_message_loop_proxy_->PostTask(FROM_HERE,
+      base::Bind(&VideoCaptureImpl::DoNotifyBitstreamOpenedOnCaptureThread,
+                 base::Unretained(this), params, buffers, buffer_size));
+}
+
+void VideoCaptureImpl::OnEncodedBitstreamClosed() {
+  capture_message_loop_proxy_->PostTask(FROM_HERE,
+      base::Bind(&VideoCaptureImpl::DoNotifyBitstreamClosedOnCaptureThread,
+                 base::Unretained(this)));
+}
+
+void VideoCaptureImpl::OnEncodingConfigChanged(
+      const media::RuntimeVideoEncodingParameters& params) {
+  capture_message_loop_proxy_->PostTask(FROM_HERE,
+      base::Bind(
+          &VideoCaptureImpl::DoNotifyBitstreamConfigChangedOnCaptureThread,
+          base::Unretained(this), params));
+}
+
+void VideoCaptureImpl::OnEncodedBufferReady(
+    int buffer_id,
+    int size,
+    const media::BufferEncodingMetadata& metadata) {
+  capture_message_loop_proxy_->PostTask(FROM_HERE,
+      base::Bind(&VideoCaptureImpl::DoNotifyBitstreamBufferReadyOnCaptureThread,
+                 base::Unretained(this), buffer_id, size, metadata));
+}
+
 void VideoCaptureImpl::FeedBuffer(scoped_refptr<VideoFrameBuffer> buffer) {
   capture_message_loop_proxy_->PostTask(FROM_HERE,
       base::Bind(&VideoCaptureImpl::DoFeedBufferOnCaptureThread,
                  base::Unretained(this), buffer));
 }
 
 void VideoCaptureImpl::OnBufferCreated(
     base::SharedMemoryHandle handle,
     int length, int buffer_id) {
   capture_message_loop_proxy_->PostTask(FROM_HERE,
@@ skipping 185 matching lines @@
     it->first->OnBufferReady(this, buffer);
   }
   cached_dibs_[buffer_id]->references = clients_.size();
 }
 
 void VideoCaptureImpl::DoStateChangedOnCaptureThread(VideoCaptureState state) {
   DCHECK(capture_message_loop_proxy_->BelongsToCurrentThread());
 
   switch (state) {
     case VIDEO_CAPTURE_STATE_STARTED:
+      StartFetchCapabilities();
       break;
     case VIDEO_CAPTURE_STATE_STOPPED:
       state_ = VIDEO_CAPTURE_STATE_STOPPED;
       DVLOG(1) << "OnStateChanged: stopped!, device_id = " << device_id_;
       STLDeleteValues(&cached_dibs_);
       if (!clients_.empty() || !clients_pending_on_restart_.empty())
         RestartCapture();
       break;
     case VIDEO_CAPTURE_STATE_PAUSED:
       for (ClientInfo::iterator it = clients_.begin();
@@ skipping 54 matching lines @@
   }
 }
 
 void VideoCaptureImpl::DoSuspendCaptureOnCaptureThread(bool suspend) {
   DVLOG(1) << "DoSuspendCapture: suspend " << (suspend ? "yes" : "no");
   DCHECK(capture_message_loop_proxy_->BelongsToCurrentThread());
 
   suspended_ = suspend;
 }
 
+void VideoCaptureImpl::DoNotifyBitstreamOpenedOnCaptureThread(
+    const media::VideoEncodingParameters& params,
+    const std::vector<base::SharedMemoryHandle>& buffers,
+    int buffer_size) {
+  DCHECK(bitstream_buffers_.empty());
+  bitstream_buffer_size_ = buffer_size;
+  for (size_t i = 0; i < buffers.size(); ++i) {
+    base::SharedMemory* shm = new base::SharedMemory(buffers[i], true);
+    DCHECK(shm->Map(buffer_size));
+    bitstream_buffers_.push_back(shm);
+  }
+  client_->OnOpened(params);
+}
+
+void VideoCaptureImpl::DoNotifyBitstreamClosedOnCaptureThread() {
+  for (size_t i = 0; i < bitstream_buffers_.size(); ++i)
+    bitstream_buffers_[i]->Close();
+  bitstream_buffers_.clear();

[sheu, 2013/06/12 22:35:05]

I think we leak base::SharedMemory objects at this point.  The std::vector<>
does not claim ownership of its buffers and does not destroy them.

(discussion continued below)

[hshi1, 2013/06/13 00:25:31]

Done.

+  client_->OnClosed();
+}
+
+void VideoCaptureImpl::DoNotifyBitstreamConfigChangedOnCaptureThread(
+    const media::RuntimeVideoEncodingParameters& params) {
+  client_->OnConfigChanged(params);
+}
+
+void VideoCaptureImpl::DoNotifyBitstreamBufferReadyOnCaptureThread(
+    int buffer_id,
+    int size,
+    const media::BufferEncodingMetadata& metadata) {
+  if (buffer_id >= 0 && buffer_id < (int)bitstream_buffers_.size()) {
+    base::SharedMemory* shm = bitstream_buffers_[buffer_id];
+    scoped_refptr<media::EncodedBitstreamBuffer> buffer =
+        new media::EncodedBitstreamBuffer(
+            buffer_id, (uint8*)shm->memory(), size, metadata);

[sheu, 2013/06/12 22:35:05]

What are the lifetime semantics of the shared memory backing the
EncodedBitstreamBuffer?

The way EVS was spec-ed, the EncodedBitstreamBuffer represented one invariant
piece of the encoded bitstream held by a refcounted object.  Clients of EVS
would get EncodedBitstreamBuffers for to use, and the refcounting would take
care of notifying the EVS when the EBB was destroyed, without having to
explicitly return the EBB to the EVS.  In our particular case, when the last
reference is dropped, then the internal shared memory buffer can be recycled,
and the empty buffer can be returned to the browser.

The way EVS and EBB are implemented here, it's possible for some observer's view
of an EBB's underlying memory contents to change, if the EBB is passed returned
back to the EVS while there are still outstanding references elsewhere on the
EBB.  I think this is a little bit outside the spirit of the fact that EBB is a
refcounted object.

[hshi1, 2013/06/13 00:25:31]

The EBB object is passed linearly from one point to another and never has a
refcount greater than 1. It is first created here to be and then passed to the
client (RtcEncodingVideoCapturer::EncodedVideoSourceClient::OnBufferReady()),
where the raw pointer to the mapped buffer is passed to webrtc via the
synchronous Encoded callback. Webrtc copies (with necesssary packetiziation) the
buffer content and no longer needs the buffer when the callback returns, so the
client calls evs->ReturnBitstreamBuffer at the end of OnBufferReady(). The EBB
will be released at the end of VideoCaptureImpl::ReturnBitstreamBuffer where its
refcount is back to 0.

[sheu, 2013/06/13 05:36:51]

I'm confident that you've got the lifetime nailed down so we don't have problems
with this use model.  My concern is only that it doesn't seem to be as robust as
the initial design for EVS.

Though since our use of EVS is pretty dirty here anyways, I suppose we can let
this slide.

+    client_->OnBufferReady(buffer);
+  }
+}
+
 void VideoCaptureImpl::StopDevice() {
   DCHECK(capture_message_loop_proxy_->BelongsToCurrentThread());
 
   device_info_available_ = false;
   if (state_ == VIDEO_CAPTURE_STATE_STARTED) {
     state_ = VIDEO_CAPTURE_STATE_STOPPING;
     Send(new VideoCaptureHostMsg_Stop(device_id_));
     current_params_.width = current_params_.height = 0;
   }
 }
@@ skipping 68 matching lines @@
   if (it != clients->end()) {
     handler->OnStopped(this);
     handler->OnRemoved(this);
     clients->erase(it);
     found = true;
   }
   return found;
 }
 
 }  // namespace content