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

media/video/video_decode_accelerator.h

 // 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.
 
 #ifndef MEDIA_VIDEO_VIDEO_DECODE_ACCELERATOR_H_
 #define MEDIA_VIDEO_VIDEO_DECODE_ACCELERATOR_H_
 
 #include <memory>
 #include <vector>
 
@@ skipping 16 matching lines @@
   // |max_resolution| and |min_resolution| are inclusive.
   struct MEDIA_EXPORT SupportedProfile {
     SupportedProfile();
     ~SupportedProfile();
     VideoCodecProfile profile;
     gfx::Size max_resolution;
     gfx::Size min_resolution;
   };
   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
   // statistics.
   enum Error {
     // An operation was attempted during an incompatible decoder state.
     ILLEGAL_STATE = 1,
     // Invalid argument was passed to an API method.
     INVALID_ARGUMENT,
     // Encoded input is unreadable.
@@ skipping 162 matching lines @@
 // Specialize std::default_delete so that scoped_ptr<VideoDecodeAccelerator>
 // uses "Destroy()" instead of trying to use the destructor.
 template <>
 struct MEDIA_EXPORT default_delete<media::VideoDecodeAccelerator> {
   void operator()(media::VideoDecodeAccelerator* vda) const;
 };
 
 }  // namespace std
 
 #endif  // MEDIA_VIDEO_VIDEO_DECODE_ACCELERATOR_H_