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

content/renderer/media/android/webmediaplayer_android.cc

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/renderer/media/android/webmediaplayer_android.h"
 
 #include <limits>
 
 #include "base/bind.h"
 #include "base/callback_helpers.h"
@@ skipping 412 matching lines @@
 }
 
 bool WebMediaPlayerAndroid::copyVideoTextureToPlatformTexture(
     blink::WebGraphicsContext3D* web_graphics_context,
     unsigned int texture,
     unsigned int level,
     unsigned int internal_format,
     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_;
   }
 
   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.
   web_graphics_context->pixelStorei(GL_UNPACK_PREMULTIPLY_ALPHA_CHROMIUM,
                                     premultiply_alpha);
 
   // Application itself needs to take care of setting the right flip_y
   // value down to get the expected result.
   // flip_y==true means to reverse the video orientation while
   // flip_y==false means to keep the intrinsic orientation.
   web_graphics_context->pixelStorei(GL_UNPACK_FLIP_Y_CHROMIUM, flip_y);

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

Aren't flip_y and premultiply_alpha incorrect here for the remote_playback
placeholder?

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

both stream texture and remote playback texture have the same flip_y direction.
I check it by my hack code.

   web_graphics_context->copyTextureCHROMIUM(GL_TEXTURE_2D, source_texture,
                                             texture, level, internal_format,
                                             type);
   web_graphics_context->pixelStorei(GL_UNPACK_FLIP_Y_CHROMIUM, false);
   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;
 }
 
 bool WebMediaPlayerAndroid::hasSingleSecurityOrigin() const {
   if (info_loader_)
     return info_loader_->HasSingleOrigin();
   // The info loader may have failed.
   if (player_type_ == MEDIA_PLAYER_TYPE_URL)
@@ skipping 1004 matching lines @@
 
 void WebMediaPlayerAndroid::exitFullscreen() {
   manager_->ExitFullscreen(player_id_);
 }
 
 bool WebMediaPlayerAndroid::canEnterFullscreen() const {
   return manager_->CanEnterFullscreen(frame_);
 }
 
 }  // namespace content