Add accelerated video decoder interface, VP8 and H.264 implementations and hook up to V4L2SVDA.

content/common/gpu/media/accelerated_video_decoder.h

+// Copyright 2015 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 CONTENT_COMMON_GPU_MEDIA_ACCELERATED_VIDEO_DECODER_
+#define CONTENT_COMMON_GPU_MEDIA_ACCELERATED_VIDEO_DECODER_
+
+#include "base/callback_forward.h"
+#include "base/callback_helpers.h"
+#include "base/memory/ref_counted.h"
+#include "content/common/content_export.h"
+#include "ui/gfx/geometry/size.h"
+
+namespace content {
+
+// An AcceleratedVideoDecoder is a video decoder that requires support from an
+// external accelerator (typically a hardware accelerator) to partially offload
+// the decode process after parsing stream headers, and performing reference
+// frame and state management.
+class CONTENT_EXPORT AcceleratedVideoDecoder {

[Owen Lin, 2015/01/09 09:56:14]

I didn't see how the decoded frames be returned in this class. After reading the
other parts, I realize the frame ares actually output by different Accelerators.
This sounds wired. I think it would be nice if we can have an interface here. By
doing so, the client of this class don't need to deal with different so called
Accelerators.

My proposal is adding:

  bool GetDecodedPicture(Picture* picture);

to this class, and change the OutputPicture of those Accelerators to actually to
export from the internal format to media::Picture.

e.g., bool Vp8Accelerator::OutputPicture(Vp8Picture in, media::Picture* out);

But this is just a rough thought.

[Pawel Osciak, 2015/01/09 13:50:31]

I'm also not happy with this detail, I agree. I was considering a solution like
this, but I wasn't exactly happy with it either.

I know it's weird to output from Accelerator, but it's a simplification,
otherwise we'd need to like you say use something abstract, like Picture. That
would have been fine and I'd like that, but the reality is that I need to get
the underlying surface from Picture anyway to be able to output, because I need
to wait for it to finish decoding and also I need to keep reference to it while
it's in the client. And conversion from Picture to surface would require an
additional map, which I wanted to avoid.

I still want to do something about this, but it's more complicated than it
looks. I want to take another look at the design a bit later once we have a good
idea how to solve this.

+ public:
+  AcceleratedVideoDecoder() {}
+  virtual ~AcceleratedVideoDecoder() {}
+
+  virtual void SetStream(const uint8* ptr, size_t size) = 0;
+
+  // Have the decoder flush its state and trigger output of all previously
+  // decoded surfaces. Return false on failure.
+  virtual bool Flush() WARN_UNUSED_RESULT = 0;
+
+  // To be called during decoding.
+  // Stop (pause) decoding, discarding all remaining inputs and outputs,
+  // but do not flush decoder state, so that the playback can be resumed later,
+  // possibly from a different location.
+  virtual void Reset() = 0;
+
+  // Decode result codes.
+  enum DecResult {
+    kDecodeError,  // Error while decoding.
+    // TODO posciak: unsupported streams are currently treated as error
+    // in decoding; in future it could perhaps be possible to fall back
+    // to software decoding instead.
+    // kStreamError,  // Error in stream.
+    kAllocateNewSurfaces,  // Need a new set of surfaces to be allocated.
+    kRanOutOfStreamData,   // Need more stream data to proceed.
+    kRanOutOfSurfaces,     // Waiting for the client to free up output surfaces.
+  };
+
+  // Try to decode more of the stream, returning decoded frames asynchronously.
+  // Return when more stream is needed, when we run out of free surfaces, when
+  // we need a new set of them, or when an error occurs.
+  virtual DecResult Decode() WARN_UNUSED_RESULT = 0;
+
+  // Return dimensions/required number of output surfaces that client should
+  // be ready to provide for the decoder to function properly.
+  // To be used after Decode() returns kNeedNewSurfaces.
+  virtual gfx::Size GetPicSize() = 0;

[Owen Lin, 2015/01/09 09:56:14]

Would it be better to move into those Accelerator?

class Vp8Accelerator {
  int SetRequiredNumOfPicturesAndSize(
      int num_pictures, Size& picture_size)
};

By doing so, we don't need the "kAllocateNewSurfaces" return code.

[Pawel Osciak, 2015/01/09 13:50:31]

We still need to return from Decode(), because we cannot continue decoding with
old surfaces. So with that, the accelerator would have to know that something
called SetRequiredNumOfPicturesAndSize before this returned. Of course that
would have been fine, but there is another complication that accelerator would
have to store the result of SetRequiredNumOfPicturesAndSize until next time
Decode returned and would have to check whether that happened every time Decode
returned, even if it didn't.

With a return, it's easier to know what's going on, and we need to return from
Decode() anyway, and can actually pull the information when we decide to change
surface set, and not have it forced onto us.

+  virtual size_t GetRequiredNumOfPictures() = 0;
+
+  DISALLOW_COPY_AND_ASSIGN(AcceleratedVideoDecoder);
+};
+
+}  //  namespace content
+
+#endif  // CONTENT_COMMON_GPU_MEDIA_ACCELERATED_VIDEO_DECODER_