Android video: support copying video to WebGL for remote texture.

content/renderer/media/android/webmediaplayer_android.cc

Index: content/renderer/media/android/webmediaplayer_android.cc
diff --git a/content/renderer/media/android/webmediaplayer_android.cc b/content/renderer/media/android/webmediaplayer_android.cc
index b59ddbba967ba7131e63012ca407f452db4fa71a..0f2024315a99f5edfbd4bcc49ca537f9899e7402 100644
--- a/content/renderer/media/android/webmediaplayer_android.cc
+++ b/content/renderer/media/android/webmediaplayer_android.cc
@@ -430,13 +430,32 @@ bool WebMediaPlayerAndroid::copyVideoTextureToPlatformTexture(
     unsigned int type,
     bool premultiply_alpha,
     bool flip_y) {
-  if (is_remote_ || !texture_id_)
+  // Don't allow clients to copy the texture of encrypted video.

[no sievers, 2014/03/26 23:51:22]

Do we need to do this? There is no texture here to access when using encryption,
it punches a whole instead and creates a 1x1 black current_frame_, which we can
just copy here.

[dshwang, 2014/03/27 19:42:57]

The result is the same. If return false, WebGLRenderingContextBase draws black
texture as fallback, although the operation is a bit more expensive because
WebGLRenderingContextBase make the same size texture to video frame. Could we
need to create temporary 1X1 black texture here?

[dshwang, 2014/03/28 19:19:57]

After rethinking, I find 1x1 texture breaks webgl. Web developer regards this
texture as 100x100 texture although actually it is 1x1 texture. after that,
glCopyTexSubImage2D or other texture-related API cause gl error.

+  if (needs_external_surface_)
     return false;
 
+  scoped_refptr<VideoFrame> video_frame;
+  {
+    base::AutoLock auto_lock(current_frame_lock_);
+    video_frame = current_frame_;
+  }
+
+  if (!video_frame ||
+      video_frame->format() != media::VideoFrame::NATIVE_TEXTURE)
+    return false;
+  DCHECK((!is_remote_ && texture_id_) ||
+         (is_remote_ && remote_playback_texture_id_));
+  gpu::MailboxHolder* mailbox_holder = video_frame->mailbox_holder();
+  DCHECK((texture_id_ &&
+          mailbox_holder->texture_target == GL_TEXTURE_EXTERNAL_OES) ||
+         (remote_playback_texture_id_ &&
+          mailbox_holder->texture_target == GL_TEXTURE_2D));
+
   // For hidden video element (with style "display:none"), ensure the texture
   // size is set.
-  if (cached_stream_texture_size_.width != natural_size_.width ||
-      cached_stream_texture_size_.height != natural_size_.height) {
+  if (!is_remote_ &&
+      (cached_stream_texture_size_.width != natural_size_.width ||
+       cached_stream_texture_size_.height != natural_size_.height)) {
     stream_texture_factory_->SetStreamTextureSize(
         stream_id_, gfx::Size(natural_size_.width, natural_size_.height));
     cached_stream_texture_size_ = natural_size_;
@@ -445,13 +464,14 @@ bool WebMediaPlayerAndroid::copyVideoTextureToPlatformTexture(
   uint32 source_texture = web_graphics_context->createTexture();
   // This is strictly not necessary, because we flush when we create the
   // one and only stream texture.
-  web_graphics_context->waitSyncPoint(texture_mailbox_sync_point_);
+  web_graphics_context->waitSyncPoint(mailbox_holder->sync_point);

[no sievers, 2014/03/26 23:51:22]

Doesn't this change the behavior in that we synchronize with the compositor
using the texture now? Which I think doesn't really make sense for this read
access here.

Could we just remove the waitSyncPoint() here entirely like my comment suggests?
We actually flush after creating both textures (remote_playback_texture_id_ and
texture_id_).

[dshwang, 2014/03/27 19:42:57]

We can not make sure web_graphics_context and stream_factory's context3d are in
the same shared group. So waitSyncPoint() is needed.
piman@ told "Flush being only sufficient if the 2 contexts are in the same share
group"
Please refer to https://code.google.com/p/chromium/issues/detail?id=351092#c11

[no sievers, 2014/03/28 18:10:25]

I think he's talking about possible future semantics. All contexts in the same
renderer process are still on the same IPC channel and their flush IPC messages
are therefore ordered.

The thing I'm worried about: Isn't the mailbox_holder updated from another
thread (compositor thread)? While we are on the main thread here.

[dshwang, 2014/03/28 18:30:23]

That's good question. mailbox_holder is updated by only render thread. When the
compositor finishes to use mailbox_holder, the compositor updates
mailbox_holder->sync_point on the render thread by PostTask.

[dshwang, 2014/03/28 19:19:57]

In addition, if https://codereview.chromium.org/175223003/ is landed, only video
decoder code updates mailbox_holder.

[no sievers, 2014/03/28 19:47:59]

Great, thanks for fixing that!

 
   // Ensure the target of texture is set before copyTextureCHROMIUM, otherwise
   // an invalid texture target may be used for copy texture.
-  web_graphics_context->bindTexture(GL_TEXTURE_EXTERNAL_OES, source_texture);
-  web_graphics_context->consumeTextureCHROMIUM(GL_TEXTURE_EXTERNAL_OES,
-                                               texture_mailbox_.name);
+  web_graphics_context->bindTexture(mailbox_holder->texture_target,
+                                    source_texture);
+  web_graphics_context->consumeTextureCHROMIUM(mailbox_holder->texture_target,
+                                               mailbox_holder->mailbox.name);
 
   // The video is stored in an unmultiplied format, so premultiply if
   // necessary.
@@ -470,7 +490,10 @@ bool WebMediaPlayerAndroid::copyVideoTextureToPlatformTexture(
   web_graphics_context->pixelStorei(GL_UNPACK_PREMULTIPLY_ALPHA_CHROMIUM,
                                     false);
 
-  web_graphics_context->bindTexture(GL_TEXTURE_EXTERNAL_OES, 0);
+  if (mailbox_holder->texture_target == GL_TEXTURE_EXTERNAL_OES)
+    web_graphics_context->bindTexture(GL_TEXTURE_EXTERNAL_OES, 0);
+  else
+    web_graphics_context->bindTexture(GL_TEXTURE_2D, texture);
   web_graphics_context->deleteTexture(source_texture);
   web_graphics_context->flush();
   return true;