summaryrefslogtreecommitdiffstats
path: root/media/filters
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 /media/filters
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 'media/filters')
-rw-r--r--media/filters/gpu_video_decoder.cc6
-rw-r--r--media/filters/gpu_video_decoder.h2
2 files changed, 5 insertions, 3 deletions
diff --git a/media/filters/gpu_video_decoder.cc b/media/filters/gpu_video_decoder.cc
index 392448d6..7a179e3 100644
--- a/media/filters/gpu_video_decoder.cc
+++ b/media/filters/gpu_video_decoder.cc
@@ -501,9 +501,11 @@ void GpuVideoDecoder::ReleaseMailbox(
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) {
DCHECK(factories->GetTaskRunner()->BelongsToCurrentThread());
- factories->WaitSyncPoint(mailbox_holder->sync_point);
+
+ for (size_t i = 0; i < release_sync_points.size(); i++)
+ factories->WaitSyncPoint(release_sync_points[i]);
if (decoder) {
decoder->ReusePictureBuffer(picture_buffer_id);
diff --git a/media/filters/gpu_video_decoder.h b/media/filters/gpu_video_decoder.h
index e8f5f75..1d905cd 100644
--- a/media/filters/gpu_video_decoder.h
+++ b/media/filters/gpu_video_decoder.h
@@ -108,7 +108,7 @@ class MEDIA_EXPORT GpuVideoDecoder
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);
// Indicate the picture buffer can be reused by the decoder.
void ReusePictureBuffer(int64 picture_buffer_id);