summaryrefslogtreecommitdiffstats
path: root/content/renderer/media/rtc_video_decoder.h
diff options
context:
space:
mode:
authordongseong.hwang@intel.com <dongseong.hwang@intel.com@0039d316-1c4b-4281-b951-d872f2087c98>2014-04-30 19:15:28 +0000
committerdongseong.hwang@intel.com <dongseong.hwang@intel.com@0039d316-1c4b-4281-b951-d872f2087c98>2014-04-30 19:15:28 +0000
commitc37a4cc4ca8b30e5c5c47fe831d5a35f6b8461bf (patch)
treee51b1458cb8e5cc03ef2b8e5098c21e8ebe3ce6f /content/renderer/media/rtc_video_decoder.h
parentbac64671bef27d0b35d4a7b099bb61fe9944c5d7 (diff)
downloadchromium_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 'content/renderer/media/rtc_video_decoder.h')
-rw-r--r--content/renderer/media/rtc_video_decoder.h6
1 files changed, 1 insertions, 5 deletions
diff --git a/content/renderer/media/rtc_video_decoder.h b/content/renderer/media/rtc_video_decoder.h
index e0070b7..d1a04e5 100644
--- a/content/renderer/media/rtc_video_decoder.h
+++ b/content/renderer/media/rtc_video_decoder.h
@@ -28,10 +28,6 @@ class WaitableEvent;
class MessageLoopProxy;
};
-namespace gpu {
-struct MailboxHolder;
-}
-
namespace media {
class DecoderBuffer;
class GpuVideoAcceleratorFactories;
@@ -156,7 +152,7 @@ class CONTENT_EXPORT RTCVideoDecoder
const scoped_refptr<media::GpuVideoAcceleratorFactories>& factories,
int64 picture_buffer_id,
uint32 texture_id,
- scoped_ptr<gpu::MailboxHolder> mailbox_holder);
+ const std::vector<uint32>& release_sync_points);
// Tells VDA that a picture buffer can be recycled.
void ReusePictureBuffer(int64 picture_buffer_id);