Adding the logic for releasing decoder resources in WebMediaPlayerManagerAndroid

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 faaadaf79731cebeadb3c1947b04d0003aa3bea2..065493c6ca633eea1c0f5c8498941dd5bddbd9f9 100644
--- a/webkit/media/android/webmediaplayer_android.cc
+++ b/webkit/media/android/webmediaplayer_android.cc
@@ -63,7 +63,8 @@ WebMediaPlayerAndroid::WebMediaPlayerAndroid(
       client_(client),
       buffered_(1u),
       video_frame_(new WebVideoFrameImpl(VideoFrame::CreateEmptyFrame())),
-      proxy_(new WebMediaPlayerProxyAndroid(base::MessageLoopProxy::current(),
+      main_loop_(MessageLoop::current()),
+      proxy_(new WebMediaPlayerProxyAndroid(main_loop_->message_loop_proxy(),
                                             AsWeakPtr())),
       prepared_(false),
       duration_(0),
@@ -81,7 +82,9 @@ WebMediaPlayerAndroid::WebMediaPlayerAndroid(
       stream_id_(0),
       needs_establish_peer_(true),
       stream_texture_factory_(factory) {
-  player_id_ = manager_->RegisterMediaPlayer(this);
+  main_loop_->AddDestructionObserver(this);
+  if (manager_)
+    player_id_ = manager_->RegisterMediaPlayer(this);
   if (stream_texture_factory_.get())
     stream_texture_proxy_.reset(stream_texture_factory_->CreateProxy());
 }
@@ -91,7 +94,11 @@ WebMediaPlayerAndroid::~WebMediaPlayerAndroid() {
     media_player_->Stop();

[scherkus (not reviewing), 2012/06/07 21:44:34]

how does Stop() differ from deleting the media_player_?

[qinmin, 2012/06/08 17:09:06]

After stop(), the player needs to call setDataSource() again. I think this call
is introduced long time ago when we have a crash if we delete a running
media_player_. The bug should have been fixed and we should no longer need this.

On 2012/06/07 21:44:34, scherkus wrote:

   }
 
-  manager_->UnregisterMediaPlayer(player_id_);
+  if (manager_)
+    manager_->UnregisterMediaPlayer(player_id_);
+
+  if (main_loop_)
+    main_loop_->RemoveDestructionObserver(this);
 }
 
 void WebMediaPlayerAndroid::InitIncognito(bool incognito_mode) {
@@ -473,6 +480,10 @@ void WebMediaPlayerAndroid::ReleaseMediaResources() {
   prepared_ = false;
 }
 
+bool WebMediaPlayerAndroid::IsInitialized() const {
+  return (media_player_ != NULL);
+}
+
 void WebMediaPlayerAndroid::InitializeMediaPlayer() {
   CHECK(!media_player_.get());
   prepared_ = false;
@@ -486,6 +497,9 @@ void WebMediaPlayerAndroid::InitializeMediaPlayer() {
   }
   media_player_->SetDataSource(url_.spec(), cookies, incognito_mode_);
 
+  if (manager_)
+    manager_->RequestMediaResources(player_id_);
+
   media_player_->Prepare(
       base::Bind(&WebMediaPlayerProxyAndroid::MediaInfoCallback, proxy_),
       base::Bind(&WebMediaPlayerProxyAndroid::MediaErrorCallback, proxy_),
@@ -548,6 +562,11 @@ void WebMediaPlayerAndroid::DestroyStreamTexture() {
   stream_id_ = 0;
 }
 
+void WebMediaPlayerAndroid::WillDestroyCurrentMessageLoop() {

[scherkus (not reviewing), 2012/06/07 21:44:34]

typically when the loop is going away the process we're going to get deleted
very soon -- what's the delta between this being called and the dtor being
called?

[qinmin, 2012/06/08 17:09:06]

I haven't see that happening myself, but i saw that in our crash reports. I
think that delta should be pretty small though, as I only saw 2 reports on this.

On 2012/06/07 21:44:34, scherkus wrote:

+  manager_ = NULL;
+  main_loop_ = NULL;
+}
+
 WebVideoFrame* WebMediaPlayerAndroid::getCurrentFrame() {
   if (!stream_texture_proxy_->IsInitialized() && stream_id_) {
     stream_texture_proxy_->Initialize(