Introduce a client minimum picture pool size

remoting/client/plugin/pepper_video_renderer_3d.cc

Index: remoting/client/plugin/pepper_video_renderer_3d.cc
diff --git a/remoting/client/plugin/pepper_video_renderer_3d.cc b/remoting/client/plugin/pepper_video_renderer_3d.cc
index 711c2104b702cf083f78a4b4b337286fb20eb91e..8415f487136b0973c4a30c0521e29d8d0821c441 100644
--- a/remoting/client/plugin/pepper_video_renderer_3d.cc
+++ b/remoting/client/plugin/pepper_video_renderer_3d.cc
@@ -171,7 +171,7 @@ void PepperVideoRenderer3D::OnSessionConfig(
       NOTREACHED();
   }
   int32_t result = video_decoder_.Initialize(
-      graphics_, video_profile, PP_HARDWAREACCELERATION_WITHFALLBACK,
+      graphics_, video_profile, PP_HARDWAREACCELERATION_WITHFALLBACK, 0,

[Sergey Ulanov, 2015/08/11 18:17:01]

What happens when a plugin calls GetPicture() while already holding certain
number previous frame? Can GetPicture() fail in that case because there are too
many frames allocated or will it delay completion until the previous frames are
returned?
Does it matter if the frames the plugin is holding are not sequential? I.e. if
there are 3 frames allocated total and the plugin holds frames N and N+2 can it
call GetPicture() to retrieve frame N+3 or does it have to return frame N first?

In either case, this class may call GetPicture() while holding previous 2
frames, so 0 is not correct here. It should be 3, if I understand the meaning
correctly.

[lpique, 2015/08/11 19:56:10]

At present, the call to GetPictures() succeeds (PP_OK_COMPLETIONPENDING), but
the callback is not invoked until there are pictures available, which may or may
not happen.

I'm not sure returning an error immediately (or through the callback either) is
useful. The ARC (plugin) code can't force a release of pictures back to the
PPAPI, and all it would do is to retry the GetPictures() call again, and
busy-wait.

To correct that, I would add code that would force the same sort of wait in the
ARC driver, so that it only calls GetPicture() if it knows pictures are
available. But all that is doing is moving the wait.
The ARC code is written to handle decoded frames being returned in arbitrary
order.
Ok, I will happily add a local constant declaring this part of the code requires
three.

I only used zero because it introduced the least amount of change. The
implementation takes this requested minimum and effectively does
"max(requested_by_client, required_by_decoder)", so the amount required by the
decoder would still be the count allocated. For the platforms I was testing ARC
on, I observed a picture pool size of five.

Done.

       callback_factory_.NewCallback(&PepperVideoRenderer3D::OnInitialized));
   CHECK_EQ(result, PP_OK_COMPLETIONPENDING)
       << "video_decoder_.Initialize() returned " << result;