vda: Rename Exynos VDA to V4L2 VDA

content/common/gpu/media/v4l2_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.
 //
 // This file contains an implementation of VideoDecoderAccelerator
 // that utilizes the hardware video decoder present on the Exynos SoC.

[Pawel Osciak, 2014/01/07 04:16:27]

There are two remaining mentions of "Exynos" in this file. Let's get rid of them
as well and update the docs.

Let's say something like:

"This file contains an implementation of VideoDecodeAccelerator
that utilizes hardware video decoders, which expose Video4Linux 2 API
(http://linuxtv.org/downloads/v4l-dvb-apis/)."

 
-#ifndef CONTENT_COMMON_GPU_MEDIA_EXYNOS_VIDEO_DECODE_ACCELERATOR_H_
-#define CONTENT_COMMON_GPU_MEDIA_EXYNOS_VIDEO_DECODE_ACCELERATOR_H_
+#ifndef CONTENT_COMMON_GPU_MEDIA_V4L2_VIDEO_DECODE_ACCELERATOR_H_
+#define CONTENT_COMMON_GPU_MEDIA_V4L2_VIDEO_DECODE_ACCELERATOR_H_
 
 #include <queue>
 #include <vector>
 
 #include "base/callback_forward.h"
 #include "base/memory/linked_ptr.h"
 #include "base/memory/scoped_ptr.h"
 #include "base/threading/thread.h"
 #include "content/common/content_export.h"
 #include "content/common/gpu/media/video_decode_accelerator_impl.h"
 #include "media/base/limits.h"
 #include "media/base/video_decoder_config.h"
 #include "media/video/picture.h"
 #include "ui/gfx/size.h"
 #include "ui/gl/gl_bindings.h"
 
 namespace base {
 class MessageLoopProxy;
 }
 
 namespace content {
 class H264Parser;
 
 // This class handles Exynos video acceleration directly through the V4L2
 // device exported by the Multi Format Codec hardware block.

[Pawel Osciak, 2014/01/07 04:16:27]

"This class handles video accelerators directly through a V4L2 device exported
by the hardware blocks."

 //
 // The threading model of this class is driven by the fact that it needs to
 // interface two fundamentally different event queues -- the one Chromium
 // provides through MessageLoop, and the one driven by the V4L2 devices which
 // is waited on with epoll().  There are three threads involved in this class:
 //
 // * The child thread, which is the main GPU process thread which calls the
 //   media::VideoDecodeAccelerator entry points.  Calls from this thread
 //   generally do not block (with the exception of Initialize() and Destroy()).
 //   They post tasks to the decoder_thread_, which actually services the task
 //   and calls back when complete through the
 //   media::VideoDecodeAccelerator::Client interface.
 // * The decoder_thread_, owned by this class.  It services API tasks, through
 //   the *Task() routines, as well as V4L2 device events, through
 //   ServiceDeviceTask().  Almost all state modification is done on this thread.
 // * The device_poll_thread_, owned by this class.  All it does is epoll() on
 //   the V4L2 in DevicePollTask() and schedule a ServiceDeviceTask() on the
 //   decoder_thread_ when something interesting happens.
 //   TODO(sheu): replace this thread with an TYPE_IO decoder_thread_.
 //
 // Note that this class has no locks!  Everything's serviced on the
 // decoder_thread_, so there are no synchronization issues.
 // ... well, there are, but it's a matter of getting messages posted in the
 // right order, not fiddling with locks.
-class CONTENT_EXPORT ExynosVideoDecodeAccelerator
+class CONTENT_EXPORT V4l2VideoDecodeAccelerator

[Pawel Osciak, 2014/01/07 04:16:27]

Nit: I think we might prefer V4L2 (with capital "L").

[shivdasp, 2014/01/07 04:31:14]

Done.

     : public VideoDecodeAcceleratorImpl {
  public:
-  ExynosVideoDecodeAccelerator(
+  V4l2VideoDecodeAccelerator(
       EGLDisplay egl_display,
       Client* client,
       const base::WeakPtr<Client>& io_client_,
       const base::Callback<bool(void)>& make_context_current,
       const scoped_refptr<base::MessageLoopProxy>& io_message_loop_proxy);
-  virtual ~ExynosVideoDecodeAccelerator();
+  virtual ~V4l2VideoDecodeAccelerator();
 
   // media::VideoDecodeAccelerator implementation.
   // Note: Initialize() and Destroy() are synchronous.
   virtual bool Initialize(media::VideoCodecProfile profile) OVERRIDE;
   virtual void Decode(const media::BitstreamBuffer& bitstream_buffer) OVERRIDE;
   virtual void AssignPictureBuffers(
       const std::vector<media::PictureBuffer>& buffers) OVERRIDE;
   virtual void ReusePictureBuffer(int32 picture_buffer_id) OVERRIDE;
   virtual void Flush() OVERRIDE;
   virtual void Reset() OVERRIDE;
   virtual void Destroy() OVERRIDE;
 
   // VideoDecodeAcceleratorImpl implementation.
   virtual bool CanDecodeOnIOThread() OVERRIDE;
 
  private:
   // These are rather subjectively tuned.
   enum {
     kMfcInputBufferCount = 8,

[Pawel Osciak, 2014/01/07 04:16:27]

I'm leaning towards renaming MFC -> Decoder everywhere.

[shivdasp, 2014/01/07 04:31:14]

Should we replace "MFC" with "Decoder" for members too (mfc_input_stream_on_
etc..) ? And is the Decoder really required since this file is the decoder impl.
Names would become:
kMfcInputBufferCount -> kDecoderInputBufferCount
Just kInputBufferCount will do ? Variable names will also become very long.

On 2014/01/07 04:16:27, posciak wrote:

[Pawel Osciak, 2014/01/07 04:35:48]

Good point. I agree.

     // TODO(posciak): determine MFC input buffer size based on level limits.
     // See http://crbug.com/255116.
     kMfcInputBufferMaxSize = 1024 * 1024,
     // Number of output buffers to use for each VDA stage above what's required
     // by the decoder (e.g. DPB size, in H264).  We need
     // media::limits::kMaxVideoFrames to fill up the GpuVideoDecode pipeline,
     // and +1 for a frame in transit.
     kDpbOutputBufferExtraCount = media::limits::kMaxVideoFrames + 1,
   };
 
@@ skipping 197 matching lines @@
 
   // Message loop of the IO thread.
   scoped_refptr<base::MessageLoopProxy> io_message_loop_proxy_;
 
   // WeakPtr<> pointing to |this| for use in posting tasks from the decoder or
   // device worker threads back to the child thread.  Because the worker threads
   // are members of this class, any task running on those threads is guaranteed
   // that this object is still alive.  As a result, tasks posted from the child
   // thread to the decoder or device thread should use base::Unretained(this),
   // and tasks posted the other way should use |weak_this_|.
-  base::WeakPtr<ExynosVideoDecodeAccelerator> weak_this_;
+  base::WeakPtr<V4l2VideoDecodeAccelerator> weak_this_;
 
   // To expose client callbacks from VideoDecodeAccelerator.
   // NOTE: all calls to these objects *MUST* be executed on
   // child_message_loop_proxy_.
   base::WeakPtrFactory<Client> client_ptr_factory_;
   base::WeakPtr<Client> client_;
   // Callbacks to |io_client_| must be executed on |io_message_loop_proxy_|.
   base::WeakPtr<Client> io_client_;
 
   //
@@ skipping 96 matching lines @@
 
   // Make our context current before running any EGL entry points.
   base::Callback<bool(void)> make_context_current_;
 
   // EGL state
   EGLDisplay egl_display_;
 
   // The codec we'll be decoding for.
   media::VideoCodecProfile video_profile_;
 
-  DISALLOW_COPY_AND_ASSIGN(ExynosVideoDecodeAccelerator);
+  DISALLOW_COPY_AND_ASSIGN(V4l2VideoDecodeAccelerator);
 };
 
 }  // namespace content
 
-#endif  // CONTENT_COMMON_GPU_MEDIA_EXYNOS_VIDEO_DECODE_ACCELERATOR_H_
+#endif  // CONTENT_COMMON_GPU_MEDIA_V4L2_VIDEO_DECODE_ACCELERATOR_H_