Set the texture to cleared in VideoDecodeAccelerator::PictureReady.

content/common/gpu/media/exynos_video_decode_accelerator.cc

Index: content/common/gpu/media/exynos_video_decode_accelerator.cc
diff --git a/content/common/gpu/media/exynos_video_decode_accelerator.cc b/content/common/gpu/media/exynos_video_decode_accelerator.cc
index 68d71293b681189c4abd10e25772774dc2d5e0b9..c52c3489be720ab091fe4f99309ba25d29cc0377 100644
--- a/content/common/gpu/media/exynos_video_decode_accelerator.cc
+++ b/content/common/gpu/media/exynos_video_decode_accelerator.cc
@@ -195,7 +195,8 @@ ExynosVideoDecodeAccelerator::GscOutputRecord::GscOutputRecord()
       fd(-1),
       egl_image(EGL_NO_IMAGE_KHR),
       egl_sync(EGL_NO_SYNC_KHR),
-      picture_id(-1) {
+      picture_id(-1),
+      cleared(false) {
 }
 
 ExynosVideoDecodeAccelerator::GscOutputRecord::~GscOutputRecord() {
@@ -1052,6 +1053,7 @@ void ExynosVideoDecodeAccelerator::AssignPictureBuffersTask(
     DCHECK_EQ(output_record.egl_image, EGL_NO_IMAGE_KHR);
     DCHECK_EQ(output_record.egl_sync, EGL_NO_SYNC_KHR);
     DCHECK_EQ(output_record.picture_id, -1);
+    DCHECK_EQ(output_record.cleared, false);
     PictureBufferArrayRef::PictureBufferRef& buffer =
         pic_buffers->picture_buffers[i];
     output_record.fd = buffer.egl_image_fd;
@@ -1415,7 +1417,17 @@ void ExynosVideoDecodeAccelerator::DequeueGsc() {
     gsc_output_buffer_queued_count_--;
     DVLOG(3) << "DequeueGsc(): returning input_id=" << dqbuf.timestamp.tv_sec
              << " as picture_id=" << output_record.picture_id;
-    io_message_loop_proxy_->PostTask(FROM_HERE, base::Bind(
+    // If the picture is not cleared, post it to the child thread because it has
+    // to be cleared in the child thread. Otherwise posting it to IO thread to
+    // reduce latency.

[piman, 2013/09/26 16:50:01]

So, if the main (child) thread is busy, this can mean the PictureReady can come
out-of-order to the client.
E.g. Picture N needs to be clear, we post task to the main thread, it waits in
the task queue because main thread is busy. Picture N+1 doesn't need it, we post
to the IO thread, it goes to the client right way. Main thread unblocks, we
SetLevelCleared on the picture N's texture, and send that to the client.
So the client receives N+1 before N. Is that ok?

[wuchengli, 2013/09/26 17:02:48]

It's not OK. I cannot think of a solution now... I'll see if I can come up with
a solution tomorrow. Sending on IO thread gains 4ms per frame. It will be good
to keep it.

[wuchengli, 2013/09/30 16:11:21]

The code is updated to handle the case you mentioned.

+    scoped_refptr<base::MessageLoopProxy> message_loop_proxy;
+    if (output_record.cleared) {
+      message_loop_proxy = io_message_loop_proxy_;
+    } else {
+      message_loop_proxy = child_message_loop_proxy_;
+      output_record.cleared = true;
+    }
+    message_loop_proxy->PostTask(FROM_HERE, base::Bind(
         &Client::PictureReady, io_client_, media::Picture(
             output_record.picture_id, dqbuf.timestamp.tv_sec)));
     decoder_frames_at_client_++;