Send hardware video frames with mailboxes.

webkit/media/android/webmediaplayer_android.cc

Index: webkit/media/android/webmediaplayer_android.cc
diff --git a/webkit/media/android/webmediaplayer_android.cc b/webkit/media/android/webmediaplayer_android.cc
index 5a0382204ce6439723150262f17cff3727ace428..5a4945e581541e753bfb1744a5e23467b6a00fd5 100644
--- a/webkit/media/android/webmediaplayer_android.cc
+++ b/webkit/media/android/webmediaplayer_android.cc
@@ -43,6 +43,9 @@ WebMediaPlayerAndroid::WebMediaPlayerAndroid(
       manager_(manager),
       network_state_(WebMediaPlayer::NetworkStateEmpty),
       ready_state_(WebMediaPlayer::ReadyStateHaveNothing),
+      texture_id_(0),
+      texture_mailbox_sync_point_(0),
+      stream_id_(0),
       is_playing_(false),
       needs_establish_peer_(true),
       has_size_info_(false),
@@ -55,7 +58,11 @@ WebMediaPlayerAndroid::WebMediaPlayerAndroid(
 
   if (stream_texture_factory_.get()) {
     stream_texture_proxy_.reset(stream_texture_factory_->CreateProxy());
-    stream_id_ = stream_texture_factory_->CreateStreamTexture(&texture_id_);
+    stream_id_ = stream_texture_factory_->CreateStreamTexture(
+        kGLTextureExternalOES,
+        &texture_id_,
+        &texture_mailbox_,
+        &texture_mailbox_sync_point_);
     ReallocateVideoFrame();
   }
 }
@@ -64,8 +71,13 @@ WebMediaPlayerAndroid::~WebMediaPlayerAndroid() {
   SetVideoFrameProviderClient(NULL);
   client_->setWebLayer(NULL);
 
-  if (stream_id_)
-    stream_texture_factory_->DestroyStreamTexture(texture_id_);
+  if (stream_id_) {
+    stream_texture_factory_->DestroyStreamTexture(
+        kGLTextureExternalOES,
+        texture_id_,
+        texture_mailbox_,
+        0);  // TODO(danakj): How do I get this sync point?

[danakj, 2013/04/18 02:38:34]

Daniel/Antoine, besides "things I did horribly wrong", I'd especially like your
input here.

There's a callback on the VideoFrame that will fire with the sync point we want
for this. But the callback happens then the VideoFrame is released from the
compositor, which means this class could be gone already.

Options that I see
1) Make stream_texture_factory_ a refptr, and hold a ref inside the VideoFrame.
(I'm not sure of the consequences of making it live longer).
2) We're assuming shared mailboxes, so..
2a) maybe this class just deletes its client id when it stuffs it into a video
frame for the first time? But then what if it needs to make a new frame for some
reason?
2b) maybe we don't need to consume the mailbox we produced and can just delete
the client id here directly. Would that cause a leak?

[piman, 2013/04/18 04:11:19]

Reading the code, my interpretation of how StreamTextures work is that the
content is updated when the texture is bound, as long as a stream exists.
If the stream is destroyed, the existing data will still be there, it just won't
update on a bind.

So with the sharing model, it would be no problem at all to destroy the texture
at any time (before any sync point), as well as the stream, with the (expected)
behavior that the texture won't update in other contexts after that.
I.e. after sharing, 2b is correct, and no that won't cause a leak.

With ÜC I realize that the texture will also not update if it's only bound in a
context that's on the same channel, but that looks reasonably easy to fix (by
sharing the StreamTextureManagerAndroid across channels - like the mailbox
manager - while giving enough routing info so that the callbacks do happen on
the right channel).

[no sievers, 2013/04/18 17:37:08]

Yep, and notice that deleting the client texture (that is currently connected to
the stream) also implies a DestroyStreamTexture(). For sharing, we'll have to
remove that bit from GLES2DecoderImpl::DeleteTexturesHelper() and instead delete
the stream object from the shared texture when it goes away.
I really want to merge StreamTexture(Manager) with GLImage/ImageManager.
However, ImageManager is also currently per channel. But maybe if I unify the
code a bit we can solve mailbox problems for both.

By the way, now that I think about it, updating the stream from BindTexture()
seems fishy. If the external binding never changes, we would not update. It
should probably either be an explicit GL call, or implied at draw time.

[danakj, 2013/04/19 18:03:52]

Oh, I have it just deleting the client texture and the stream texture now, with
a todo inside against sievers to make the StreamTexture get deleted later when
the last texture referencing it is destroyed.

+  }
 
   if (manager_)
     manager_->UnregisterMediaPlayer(player_id_);
@@ -457,7 +469,11 @@ void WebMediaPlayerAndroid::Detach() {
   Destroy();
 
   if (stream_id_) {
-    stream_texture_factory_->DestroyStreamTexture(texture_id_);
+    stream_texture_factory_->DestroyStreamTexture(
+        kGLTextureExternalOES,
+        texture_id_,
+        texture_mailbox_,
+        0);  // TODO(danakj): How do I get this sync point?
     stream_id_ = 0;
   }
 
@@ -477,9 +493,11 @@ void WebMediaPlayerAndroid::ReallocateVideoFrame() {
 #endif
   } else if (texture_id_) {
     current_frame_ = VideoFrame::WrapNativeTexture(
-        texture_id_, kGLTextureExternalOES, natural_size_,
+        texture_mailbox_, texture_mailbox_sync_point_,
+        kGLTextureExternalOES, natural_size_,
         gfx::Rect(natural_size_), natural_size_, base::TimeDelta(),
         VideoFrame::ReadPixelsCB(),
+        VideoFrame::TextureNoLongerNeededCallback(),
         base::Closure());
   }
 }