Don't require VDAs to return all PictureBuffers at once.

media/video/video_decode_accelerator.h

Index: media/video/video_decode_accelerator.h
diff --git a/media/video/video_decode_accelerator.h b/media/video/video_decode_accelerator.h
index da184ee2d46247169282e08793638e64aa18cc81..5ab81c364d8374e702c6cb16a696a5c9fa1966fe 100644
--- a/media/video/video_decode_accelerator.h
+++ b/media/video/video_decode_accelerator.h
@@ -34,6 +34,29 @@ class MEDIA_EXPORT VideoDecodeAccelerator {
   };
   using SupportedProfiles = std::vector<SupportedProfile>;
 
+  struct MEDIA_EXPORT Capabilities {
+    Capabilities();
+    ~Capabilities();
+    // Flags that can be associated with a VDA.
+    enum Flags {
+      NO_FLAGS = 0,
+
+      // Normally, the VDA is required to be able to provide all PictureBuffers
+      // to the client via PictureReady(), even if the client does not return
+      // any of them via ReusePictureBuffer().  The client is only required to
+      // return PictureBuffers when it holds all of them, if it wants to get
+      // more decoded output.  See VideoDecoder::CanReadWithoutStalling for
+      // more context.
+      // If this flag is set, then the VDA does not make this guarantee.  The
+      // client must return PictureBuffers to be sure that new frames will be
+      // provided via PictureReady.

[Ken Russell (switch to Gerrit), 2015/12/07 22:06:11]

I don't know this code, but this semantic seems like it'd be valid for the VDA
to allow only one outstanding PictureBuffer. I can't imagine Chrome's rendering
pipeline working well if this were the case since usually there's at least one
pending frame in the pipeline. Would it be beneficial to change the semantic to
say that a certain small number of PictureBuffers are allowed to be outstanding?
Do VDAs typically define this number?

[liberato (no reviews please), 2015/12/08 15:55:57]

unfortunately, we don't get to choose how many picture buffers can be
outstanding in some cases.  android's MediaCodec doesn't guarantee that more
than one decoded frame will be delivered to the client (us) before we return one
to it.  often, we'll get 3+ decoded frames at once.

this change lets us get ahead when MediaCodec allows it, but not make any
guarantees about it.  in practice, this means that we usually have 3 or 4 frames
in the renderer, but things don't deadlock when we don't.

+      CAN_STALL_ANY_TIME = 1 << 0,
+    };
+
+    SupportedProfiles supported_profiles;
+    Flags flags;
+  };
+
   // Enumeration of potential errors generated by the API.
   // Note: Keep these in sync with PP_VideoDecodeError_Dev. Also do not
   // rearrange, reuse or remove values as they are used for gathering UMA