diff options
| author | dongseong.hwang@intel.com <dongseong.hwang@intel.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2014-04-30 19:15:28 +0000 |
|---|---|---|
| committer | dongseong.hwang@intel.com <dongseong.hwang@intel.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2014-04-30 19:15:28 +0000 |
| commit | c37a4cc4ca8b30e5c5c47fe831d5a35f6b8461bf (patch) | |
| tree | e51b1458cb8e5cc03ef2b8e5098c21e8ebe3ce6f /media/base/video_frame.h | |
| parent | bac64671bef27d0b35d4a7b099bb61fe9944c5d7 (diff) | |
| download | chromium_src-c37a4cc4ca8b30e5c5c47fe831d5a35f6b8461bf.zip chromium_src-c37a4cc4ca8b30e5c5c47fe831d5a35f6b8461bf.tar.gz chromium_src-c37a4cc4ca8b30e5c5c47fe831d5a35f6b8461bf.tar.bz2 | |
HW Video: Make media::VideoFrame handle the sync point of the compositor as well as webgl and canvas.
This makes it compatible when the video hw texture and WebGL destination texture are
in different share groups.
media::VideoFrame must receive multiple sync points from clients, because clients can be many.
In WebGL case, only the compositor is the client of the mailbox in a frame. So we reuse
MailboxHolder::sync_point as release sync point. However, media::VideoFrame has multiple
clients, so media::VideoFrame must handle multiple release sync points.
Let me explain the lifecycle of the mailbox of a video frame in detail,
1. The video decoder receives a new mailbox from gpu process. The video decoder doesn't
insert a sync point, because all GPU operations for the mailbox already were executed
in the gpu process.
2. Blink or the compositor reads the mailbox. After that, all clients must insert
a release sync point.
3. When the ref count of the video frame is 0, the destructor of the video frame calls
recycle callback of the video decoder.
4. The video decoder notifies reusable mailboxes to the gpu process after waiting for
the release sync points.
Currently, there are three providers that can make a texture type video frame: GpuVideoDecoder,
RTCVideoDecoder, and VideoCapture. The video frame of VideoCapture is created in the browser
process, not the gpu process. So, VideoCapture inserts a sync point before providing it to
clients.
BUG=127940, 350925, 362521
Review URL: https://codereview.chromium.org/175223003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@267290 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'media/base/video_frame.h')
| -rw-r--r-- | media/base/video_frame.h | 20 |
1 files changed, 17 insertions, 3 deletions
diff --git a/media/base/video_frame.h b/media/base/video_frame.h index 8106a27..024cb4c 100644 --- a/media/base/video_frame.h +++ b/media/base/video_frame.h @@ -5,9 +5,12 @@ #ifndef MEDIA_BASE_VIDEO_FRAME_H_ #define MEDIA_BASE_VIDEO_FRAME_H_ +#include <vector> + #include "base/callback.h" #include "base/md5.h" #include "base/memory/shared_memory.h" +#include "base/synchronization/lock.h" #include "media/base/buffers.h" #include "ui/gfx/rect.h" #include "ui/gfx/size.h" @@ -80,7 +83,7 @@ class MEDIA_EXPORT VideoFrame : public base::RefCountedThreadSafe<VideoFrame> { // CB to be called on the mailbox backing this frame when the frame is // destroyed. - typedef base::Callback<void(scoped_ptr<gpu::MailboxHolder>)> ReleaseMailboxCB; + typedef base::Callback<void(const std::vector<uint32>&)> ReleaseMailboxCB; // Wraps a native texture of the given parameters with a VideoFrame. The // backing of the VideoFrame is held in the mailbox held by |mailbox_holder|, @@ -204,7 +207,7 @@ class MEDIA_EXPORT VideoFrame : public base::RefCountedThreadSafe<VideoFrame> { // Returns the mailbox holder of the native texture wrapped by this frame. // Only valid to call if this is a NATIVE_TEXTURE frame. Before using the // mailbox, the caller must wait for the included sync point. - gpu::MailboxHolder* mailbox_holder() const; + const gpu::MailboxHolder* mailbox_holder() const; // Returns the shared-memory handle, if present base::SharedMemoryHandle shared_memory_handle() const; @@ -219,6 +222,13 @@ class MEDIA_EXPORT VideoFrame : public base::RefCountedThreadSafe<VideoFrame> { timestamp_ = timestamp; } + // Append |sync_point| into |release_sync_points_| which will be passed to + // the video decoder when |mailbox_holder_release_cb_| is called so that + // the video decoder waits for the sync points before reusing the mailbox. + // Multiple clients can append multiple sync points on one frame. + // This method is thread safe. Both blink and compositor threads can call it. + void AppendReleaseSyncPoint(uint32 sync_point); + // Used to keep a running hash of seen frames. Expects an initialized MD5 // context. Calls MD5Update with the context and the contents of the frame. void HashFrameForTesting(base::MD5Context* context); @@ -230,6 +240,7 @@ class MEDIA_EXPORT VideoFrame : public base::RefCountedThreadSafe<VideoFrame> { const gfx::Size& coded_size, const gfx::Rect& visible_rect, const gfx::Size& natural_size, + scoped_ptr<gpu::MailboxHolder> mailbox_holder, base::TimeDelta timestamp, bool end_of_stream); virtual ~VideoFrame(); @@ -267,7 +278,7 @@ class MEDIA_EXPORT VideoFrame : public base::RefCountedThreadSafe<VideoFrame> { uint8* data_[kMaxPlanes]; // Native texture mailbox, if this is a NATIVE_TEXTURE frame. - scoped_ptr<gpu::MailboxHolder> mailbox_holder_; + const scoped_ptr<gpu::MailboxHolder> mailbox_holder_; ReleaseMailboxCB mailbox_holder_release_cb_; ReadPixelsCB read_pixels_cb_; @@ -278,6 +289,9 @@ class MEDIA_EXPORT VideoFrame : public base::RefCountedThreadSafe<VideoFrame> { base::TimeDelta timestamp_; + base::Lock release_sync_point_lock_; + std::vector<uint32> release_sync_points_; + const bool end_of_stream_; DISALLOW_IMPLICIT_CONSTRUCTORS(VideoFrame); |