[PPAPI] Implement an IOStreamResource for data transmission between plugin and renderer.

ppapi/proxy/io_stream_resource.cc

+// Copyright (c) 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.
+
+#include "ppapi/proxy/io_stream_resource.h"
+
+#include "base/bind.h"
+#include "ppapi/proxy/ppapi_messages.h"
+
+namespace ppapi {
+namespace proxy {
+
+IOStreamResource::IOStreamResource(Connection connection,
+                                   PP_Instance instance,
+                                   bool is_input)
+    : PluginResource(connection, instance),
+      IOStreamShared(is_input),
+      weak_factory_(this) {
+}
+
+IOStreamResource::IOStreamResource(Connection connection,
+                                   PP_Instance instance,
+                                   int pending_renderer_id,
+                                   bool is_input)
+    : PluginResource(connection, instance),
+      IOStreamShared(is_input),
+      weak_factory_(this) {
+  AttachToPendingHost(RENDERER, pending_renderer_id);
+}
+
+IOStreamResource::~IOStreamResource() {
+}
+
+int32_t IOStreamResource::Init(uint32_t size,
+                               scoped_refptr<TrackedCallback> callback) {
+  if (!size)
+    return PP_ERROR_BADARGUMENT;
+  Call<PpapiPluginMsg_IOStream_InitReply>(
+      RENDERER, PpapiHostMsg_IOStream_Init(size),
+      base::Bind(
+          &IOStreamResource::OnPluginMsgInitReply,
+          weak_factory_.GetWeakPtr(), size, callback));

[yzshen1, 2014/01/03 21:51:41]

You don't need this weak_factory_. You could use base::Unretained(). it is safe
because the callback won't be run if this object goes away.

+
+  return PP_OK_COMPLETIONPENDING;
+}
+
+void IOStreamResource::MovePeerLimit(uint32_t offset) {
+  Post(RENDERER, PpapiHostMsg_IOStream_MoveLimit(offset));
+}
+
+void IOStreamResource::OnReplyReceived(
+    const proxy::ResourceMessageReplyParams& params, const IPC::Message& msg) {

[yzshen1, 2014/01/03 21:51:41]

proxy:: is not needed.

+  IPC_BEGIN_MESSAGE_MAP(IOStreamResource, msg)
+    PPAPI_DISPATCH_PLUGIN_RESOURCE_CALL(
+        PpapiPluginMsg_IOStream_Init,
+        OnPluginMsgInit)
+    PPAPI_DISPATCH_PLUGIN_RESOURCE_CALL(
+        PpapiPluginMsg_IOStream_MoveLimit,
+        OnPluginMsgMoveLimit)
+    PPAPI_DISPATCH_PLUGIN_RESOURCE_CALL_UNHANDLED(
+        PluginResource::OnReplyReceived(params, msg))
+  IPC_END_MESSAGE_MAP()
+}
+
+void IOStreamResource::OnPluginMsgInit(
+    const ResourceMessageReplyParams& params, uint32_t size) {

[dmichael (off chromium), 2014/01/03 18:05:29]

Why is this "ResourceMessageReplyParams" instead of just
"ResourceMessageParams"? Same question for OnPluginMsgMoveLimit.

[yzshen1, 2014/01/03 21:51:41]

I thought we always use ResourceMessageReplyParams for handling reply messages?

+  base::SharedMemoryHandle shm_handle = base::SharedMemory::NULLHandle();
+  params.TakeSharedMemoryHandleAtIndex(0, &shm_handle);
+  SetBuffer(scoped_ptr<base::SharedMemory>(

[dmichael (off chromium), 2014/01/03 18:05:29]

Note I think this is only ever changing from an empty buffer to a real one. I
think you can get away with having an unitialized IOStreamBuffer that can get
initialized only once, and omit the shm_new_ and circular_buffer_new_ stuff.

[Peng, 2014/01/03 21:01:49]

Actually this function can be used more than once. Probably it is better to
rename it to SetBufferSize().

We support changing buffer size because two reasons:
1. In w3c spec, the track can be reconfigured by track.applyConstraints() (For
example: change the video size). But chrome does not support applyConstraints()
right now. Not sure if it will be supported in future.

2. In current implementation, when track host gets the first frame, it will
allocate the shared buffer with a default size (max_buffered_frames *
size_of_one_frame). But we have an API Configure() which can be used to change
|max_buffered_frames| later.
BTW, I am thinking if it is necessary to have an API to change the
max_buffered_frames. Probably using a fixed number 2 should be good enough. For
a live stream, if the plugin's speed is slow, I think having more buffered
frames does help anything. It will only delay the happening of frame dropping,
but it can not avoid frame dropping.

I noticed the private video API does not support configure the buffer size.
The dev video capture API supports it. But it is for multiple frames processing,
not for handling the not match speed issue. See
https://code.google.com/p/chromium/codesearch#chromium/src/ppapi/api/dev/ppb_...

 

+          new base::SharedMemory(shm_handle, is_input())), size);

[yzshen1, 2014/01/03 21:51:41]

wrong indent

+}
+
+void IOStreamResource::OnPluginMsgMoveLimit(
+    const ResourceMessageReplyParams& params, uint32_t offset) {
+  MoveLimit(offset);
+}
+
+void IOStreamResource::OnPluginMsgInitReply(

[dmichael (off chromium), 2014/01/03 18:05:29]

Am I understanding correctly that there are two distinct ways a client could
initialize the IOStreamResource? Either by calling Init, or because the host
sent a PpapiPluginMsg_IOStream_Init?

Can we cut it down to just 1 way to do it?

[Peng, 2014/01/03 21:01:49]

There are different requirements for Track & Producer.

For track, plugin does not know the frame information (size, format, etc) until
the host gets the first frame. So it is easier to let host allocate the buffer.

For producer, plugin knows the frame informations, so it is better to let plugin
allocate the buffer.

+    uint32_t size,
+    scoped_refptr<TrackedCallback> callback,
+    const ResourceMessageReplyParams& params) {
+  int32_t result = params.result();
+  if (result == PP_OK)
+    OnPluginMsgInit(params, size);
+  callback->Run(result);;

[dmichael (off chromium), 2014/01/03 18:05:29]

nit: extra semicolon

+}
+
+}  // namespace proxy
+}  // namespace ppapi