Handle config changes for MSE on android

Handle config changes for MSE

In case of config changes, we need to recreate the MediaCodec. Here is the workflow:
1. MediaSourcePlayer now stores the surface for later use.
2. Once a config change is detected, it sends an IPC requesting the new config.
3. upon receiving the new config, it creates a new MediaCodec using the stored surface

Youtube Dash player should work after this patch

BUG=233420
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=204844

[qinmin, 2013-06-03 20:40:28]

PTAL

[acolwell GONE FROM CHROMIUM, 2013-06-04 15:19:13]

https://codereview.chromium.org/16098014/diff/1/content/browser/android/media...
File content/browser/android/media_player_manager_impl.cc (right):

https://codereview.chromium.org/16098014/diff/1/content/browser/android/media...
content/browser/android/media_player_manager_impl.cc:257: int player_id,
unsigned request_id) {
nit: ditto

https://codereview.chromium.org/16098014/diff/1/content/browser/android/media...
File content/browser/android/media_player_manager_impl.h (right):

https://codereview.chromium.org/16098014/diff/1/content/browser/android/media...
content/browser/android/media_player_manager_impl.h:113: void
OnMediaSeekRequestAck(int player_id, unsigned request_id);
nit: s/request_id/seek_request_id/ to match the name in OnMediaSeekRequest()

https://codereview.chromium.org/16098014/diff/1/content/common/media/media_pl...
File content/common/media/media_player_messages_android.h (right):

https://codereview.chromium.org/16098014/diff/1/content/common/media/media_pl...
content/common/media/media_player_messages_android.h:184: unsigned /* request_id
*/)
nit: s/request/seek_request/

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_play...
File media/base/android/media_player_android.cc (right):

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_play...
media/base/android/media_player_android.cc:75: void
MediaPlayerAndroid::OnSeekRequestAck(unsigned request_id) {
nit: ditto

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_play...
File media/base/android/media_player_android.h (right):

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_play...
media/base/android/media_player_android.h:91: virtual void
OnSeekRequestAck(unsigned request_id);
nit:s/request/seek_request/

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_play...
File media/base/android/media_player_manager.h (right):

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_play...
media/base/android/media_player_manager.h:104: unsigned media_request_id) = 0;
nit:s/media/seek/ to match all other methods

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
File media/base/android/media_source_player.cc (right):

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
media/base/android/media_source_player.cc:89: decoding_ = true;
Should there be a DCHECK(!decoding_) here?

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
media/base/android/media_source_player.cc:200: if (decoding_ &&
thread_->message_loop() != base::MessageLoop::current())
This doesn't seem right. Shouldn't this code look something more like the
following?

if (decoding_ || thread_->message_loop() != base::MessageLoop::current()) {
  thread_->message_loop()->PostTask(FROM_HERE,
base::Bind(&MediaDecoderJob::Release, base::Unretained(this));
  return;
}

delete this;

This makes sure we are always done decoding and are on the proper thread before
deleting.

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
media/base/android/media_source_player.cc:260: // Or otherwise, MediaCodec might
crash. See b/8950387.
The seek is needed because you have to create a new decoder for the new surface
right? If so, you should probably updated the comment to indicate something
along these lines because it isn't obvious here that the new surface triggers a
new decoder.

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
media/base/android/media_source_player.cc:404: void
MediaSourcePlayer::OnSeekRequestAck(unsigned request_id) {
nit:s/request/seek_request/

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
media/base/android/media_source_player.cc:589: if (HasAudio() && (config_change
|| !audio_decoder_job_)) {
I don't think this is quite right. Audio & Video config changes are not
necessarily always aligned. They can happen at different times. It looks like
this code resets both decoders here if it sees a config change from either
DemuxerStream. It should only reset the decoder for the stream the signalled the
change.

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
File media/base/android/media_source_player.h (right):

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
media/base/android/media_source_player.h:141: virtual void
OnSeekRequestAck(unsigned request_id) OVERRIDE;
nit:ditto

[qinmin, 2013-06-04 19:03:23]

https://codereview.chromium.org/16098014/diff/1/content/browser/android/media...
File content/browser/android/media_player_manager_impl.cc (right):

https://codereview.chromium.org/16098014/diff/1/content/browser/android/media...
content/browser/android/media_player_manager_impl.cc:257: int player_id,
unsigned request_id) {
On 2013/06/04 15:19:14, acolwell wrote:
> nit: ditto

Done.

https://codereview.chromium.org/16098014/diff/1/content/browser/android/media...
File content/browser/android/media_player_manager_impl.h (right):

https://codereview.chromium.org/16098014/diff/1/content/browser/android/media...
content/browser/android/media_player_manager_impl.h:113: void
OnMediaSeekRequestAck(int player_id, unsigned request_id);
On 2013/06/04 15:19:14, acolwell wrote:
> nit: s/request_id/seek_request_id/ to match the name in OnMediaSeekRequest()

Done.

https://codereview.chromium.org/16098014/diff/1/content/common/media/media_pl...
File content/common/media/media_player_messages_android.h (right):

https://codereview.chromium.org/16098014/diff/1/content/common/media/media_pl...
content/common/media/media_player_messages_android.h:184: unsigned /* request_id
*/)
On 2013/06/04 15:19:14, acolwell wrote:
> nit: s/request/seek_request/

Done.

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_play...
File media/base/android/media_player_android.cc (right):

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_play...
media/base/android/media_player_android.cc:75: void
MediaPlayerAndroid::OnSeekRequestAck(unsigned request_id) {
On 2013/06/04 15:19:14, acolwell wrote:
> nit: ditto

Done.

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_play...
File media/base/android/media_player_android.h (right):

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_play...
media/base/android/media_player_android.h:91: virtual void
OnSeekRequestAck(unsigned request_id);
On 2013/06/04 15:19:14, acolwell wrote:
> nit:s/request/seek_request/

Done.

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_play...
File media/base/android/media_player_manager.h (right):

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_play...
media/base/android/media_player_manager.h:104: unsigned media_request_id) = 0;
On 2013/06/04 15:19:14, acolwell wrote:
> nit:s/media/seek/ to match all other methods

Done.

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
File media/base/android/media_source_player.cc (right):

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
media/base/android/media_source_player.cc:89: decoding_ = true;
On 2013/06/04 15:19:14, acolwell wrote:
> Should there be a DCHECK(!decoding_) here?

Done.

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
media/base/android/media_source_player.cc:200: if (decoding_ &&
thread_->message_loop() != base::MessageLoop::current())
Backgroud info: there is a problem in android that a java surface cannot be
assigned to 2 MediaCodecs at the same time, or otherwise that will cause an
exception.

If |decoding_| is false, there is nothing running on the decoder thread. So it
is safe to delete the MediaDecoderJob on the main thread. However, if we post a
task to the decoder thread to delete object, then we cannot immediately pass the
surface to a new MediaDecoderJob. So sth like "video_decoder_job_.reset(new
VideoDecoderJob())" will cause the app to crash. Basically we are blocked on the
main thread until the previous decoder got deleted. I can do a
PostTaskAndReply（）， but that will introduce longer delays when config change
happens. And it further complicates the logic in MediaSourcePlayer. Added a TODO
here to mention the bug and see if we can find a better way to handle this.

On 2013/06/04 15:19:14, acolwell wrote:
> This doesn't seem right. Shouldn't this code look something more like the
> following?
> 
> if (decoding_ || thread_->message_loop() != base::MessageLoop::current()) {
>   thread_->message_loop()->PostTask(FROM_HERE,
> base::Bind(&MediaDecoderJob::Release, base::Unretained(this));
>   return;
> }
> 
> delete this;
> 
> This makes sure we are always done decoding and are on the proper thread
before
> deleting.

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
media/base/android/media_source_player.cc:260: // Or otherwise, MediaCodec might
crash. See b/8950387.
On 2013/06/04 15:19:14, acolwell wrote:
> The seek is needed because you have to create a new decoder for the new
surface
> right? If so, you should probably updated the comment to indicate something
> along these lines because it isn't obvious here that the new surface triggers
a
> new decoder.

Done.

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
media/base/android/media_source_player.cc:404: void
MediaSourcePlayer::OnSeekRequestAck(unsigned request_id) {
On 2013/06/04 15:19:14, acolwell wrote:
> nit:s/request/seek_request/

Done.

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
media/base/android/media_source_player.cc:589: if (HasAudio() && (config_change
|| !audio_decoder_job_)) {
added 2 new variable, |reconfig_audio_decoder_| and |reconfig_video_decoder_| to
indicate whether we need to recreate the audio/video decoder.

On 2013/06/04 15:19:14, acolwell wrote:
> I don't think this is quite right. Audio & Video config changes are not
> necessarily always aligned. They can happen at different times. It looks like
> this code resets both decoders here if it sees a config change from either
> DemuxerStream. It should only reset the decoder for the stream the signalled
the
> change.

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
File media/base/android/media_source_player.h (right):

https://codereview.chromium.org/16098014/diff/1/media/base/android/media_sour...
media/base/android/media_source_player.h:141: virtual void
OnSeekRequestAck(unsigned request_id) OVERRIDE;
On 2013/06/04 15:19:14, acolwell wrote:
> nit:ditto

Done.

[acolwell GONE FROM CHROMIUM, 2013-06-05 23:13:38]

https://codereview.chromium.org/16098014/diff/11001/media/base/android/media_...
File media/base/android/media_source_player.cc (right):

https://codereview.chromium.org/16098014/diff/11001/media/base/android/media_...
media/base/android/media_source_player.cc:213: if (decoding_ &&
thread_->message_loop() != base::MessageLoop::current())
This logic still doesn't seem safe to me, but I'm fine with defering the fix to
another CL.

https://codereview.chromium.org/16098014/diff/11001/media/base/android/media_...
media/base/android/media_source_player.cc:257: reconfig_audio_decoder_(true),
Nit: I think these should default to false so the only reflect when actual
config changes occur.

https://codereview.chromium.org/16098014/diff/11001/media/base/android/media_...
media/base/android/media_source_player.cc:273: reconfig_video_decoder_ = true;
nit: Shouldn't this also set CONFIG_CHANGE_EVENT_PENDING?

https://codereview.chromium.org/16098014/diff/11001/media/base/android/media_...
media/base/android/media_source_player.cc:392: pending_event_ &=
~SURFACE_CHANGE_EVENT_PENDING;
Shouldn't this only be done if a video config check was pending?

https://codereview.chromium.org/16098014/diff/11001/media/base/android/media_...
media/base/android/media_source_player.cc:463: CreateMediaDecoderJobs();
Shouldn't this only apply for a video reconfig? It seems like you should split
CreateMediaDecoderJobs() into audio and video methods so it is clear when only
one is really needed.

[qinmin, 2013-06-06 01:17:25]

https://codereview.chromium.org/16098014/diff/11001/media/base/android/media_...
File media/base/android/media_source_player.cc (right):

https://codereview.chromium.org/16098014/diff/11001/media/base/android/media_...
media/base/android/media_source_player.cc:213: if (decoding_ &&
thread_->message_loop() != base::MessageLoop::current())
ok, i will follow up with another CL to address this. One workaround is that
when creating the MediaDecoderJob, we post a task onto the decoder thread to
configure the new decoder. So the old decoder will be gone first, and the new
decoder will be configured with the same surface.

On 2013/06/05 23:13:38, acolwell wrote:
> This logic still doesn't seem safe to me, but I'm fine with defering the fix
to
> another CL.

https://codereview.chromium.org/16098014/diff/11001/media/base/android/media_...
media/base/android/media_source_player.cc:257: reconfig_audio_decoder_(true),
On 2013/06/05 23:13:38, acolwell wrote:
> Nit: I think these should default to false so the only reflect when actual
> config changes occur.

Done.

https://codereview.chromium.org/16098014/diff/11001/media/base/android/media_...
media/base/android/media_source_player.cc:273: reconfig_video_decoder_ = true;
Surface change is a little different from config change, it requires recreation
of the decoder and perform a seek, But the player does not need to ask
chunk_demuxer for a new config. 
If we set CONFIG_CHANGE_EVENT here, then all the SURFACE_CHANGE_EVENT will be
accompanied with a CONFIG_CHANGE_EVENT, which will cause an extra round trip
IPCs to chunk demuxer.
Removed the "reconfig_video_decoder_ = true" statement here, so
reconfig_video_decoder_ only applies to real config changes in the stream, not
surface change

On 2013/06/05 23:13:38, acolwell wrote:
> nit: Shouldn't this also set CONFIG_CHANGE_EVENT_PENDING?

https://codereview.chromium.org/16098014/diff/11001/media/base/android/media_...
media/base/android/media_source_player.cc:392: pending_event_ &=
~SURFACE_CHANGE_EVENT_PENDING;
good catch, fixed.

On 2013/06/05 23:13:38, acolwell wrote:
> Shouldn't this only be done if a video config check was pending?

https://codereview.chromium.org/16098014/diff/11001/media/base/android/media_...
media/base/android/media_source_player.cc:463: CreateMediaDecoderJobs();
Done, split the function into CreateVideoDecoderJob and CreateAudioDecoderJob.

On 2013/06/05 23:13:38, acolwell wrote:
> Shouldn't this only apply for a video reconfig? It seems like you should split
> CreateMediaDecoderJobs() into audio and video methods so it is clear when only
> one is really needed.

[DaleCurtis, 2013-06-06 01:23:12]

https://codereview.chromium.org/16098014/diff/15001/content/common/media/medi...
File content/common/media/media_player_messages_android.h (right):

https://codereview.chromium.org/16098014/diff/15001/content/common/media/medi...
content/common/media/media_player_messages_android.h:133: unsigned /*
seek_request_id */)
drive by: you should use explicitly sized types for IPC messages. this should be
an uint32 at most here and below.

[qinmin, 2013-06-06 01:32:08]

https://codereview.chromium.org/16098014/diff/15001/content/common/media/medi...
File content/common/media/media_player_messages_android.h (right):

https://codereview.chromium.org/16098014/diff/15001/content/common/media/medi...
content/common/media/media_player_messages_android.h:133: unsigned /*
seek_request_id */)
On 2013/06/06 01:23:12, DaleCurtis wrote:
> drive by: you should use explicitly sized types for IPC messages. this should
be
> an uint32 at most here and below.

Done.

[acolwell GONE FROM CHROMIUM, 2013-06-06 14:32:19]

lgtm

https://codereview.chromium.org/16098014/diff/18002/media/base/android/media_...
File media/base/android/media_source_player.cc (right):

https://codereview.chromium.org/16098014/diff/18002/media/base/android/media_...
media/base/android/media_source_player.cc:324: reconfig_audio_decoder_ = true;
nit: Should these be false too so they match the constructor?

[Yaron, 2013-06-06 16:07:27]

content/browser/android lgtm

[qinmin, 2013-06-06 16:32:34]

https://codereview.chromium.org/16098014/diff/18002/media/base/android/media_...
File media/base/android/media_source_player.cc (right):

https://codereview.chromium.org/16098014/diff/18002/media/base/android/media_...
media/base/android/media_source_player.cc:324: reconfig_audio_decoder_ = true;
On 2013/06/06 14:32:19, acolwell wrote:
> nit: Should these be false too so they match the constructor?

Yes. Since the decoder jobs are deleted, we will always recreate them when
start() is called. Changed to false.

[commit-bot: I haz the power, 2013-06-06 16:32:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/qinmin@chromium.org/16098014/18002

[commit-bot: I haz the power, 2013-06-06 16:32:50]

Failed to apply patch for content/browser/android/media_player_manager_impl.cc:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file content/browser/android/media_player_manager_impl.cc
  Hunk #1 succeeded at 274 (offset 15 lines).
  Hunk #2 FAILED at 315.
  1 out of 2 hunks FAILED -- saving rejects to file
content/browser/android/media_player_manager_impl.cc.rej

Patch:       content/browser/android/media_player_manager_impl.cc
Index: content/browser/android/media_player_manager_impl.cc
diff --git a/content/browser/android/media_player_manager_impl.cc
b/content/browser/android/media_player_manager_impl.cc
index
8ffc5eaa7b05c93d060419b15df7363b1a3f7686..29edef22efe0af48620e2f794aad2cfd9a0c8269
100644
--- a/content/browser/android/media_player_manager_impl.cc
+++ b/content/browser/android/media_player_manager_impl.cc
@@ -259,10 +259,11 @@ void MediaPlayerManagerImpl::OnReadFromDemuxerAck(
     player->ReadFromDemuxerAck(params);
 }
 
-void MediaPlayerManagerImpl::OnMediaSeekRequestAck(int player_id) {
+void MediaPlayerManagerImpl::OnMediaSeekRequestAck(
+    int player_id, unsigned seek_request_id) {
   MediaPlayerAndroid* player = GetPlayer(player_id);
   if (player)
-    player->OnSeekRequestAck();
+    player->OnSeekRequestAck(seek_request_id);
 }
 
 MediaPlayerAndroid* MediaPlayerManagerImpl::GetPlayer(int player_id) {
@@ -314,14 +315,13 @@ void MediaPlayerManagerImpl::OnSeekComplete(int player_id,
 }
 
 void MediaPlayerManagerImpl::OnMediaSeekRequest(
-    int player_id, base::TimeDelta time_to_seek, bool request_surface) {
-  bool request_texture_peer = request_surface;
-  if (request_surface && player_id == fullscreen_player_id_) {
-    video_view_.CreateContentVideoView();
-    request_texture_peer = false;
-  }
+    int player_id, base::TimeDelta time_to_seek, unsigned seek_request_id) {
   Send(new MediaPlayerMsg_MediaSeekRequest(
-      routing_id(), player_id, time_to_seek, request_texture_peer));
+      routing_id(), player_id, time_to_seek, seek_request_id));
+}
+
+void MediaPlayerManagerImpl::OnMediaConfigRequest(int player_id) {
+  Send(new MediaPlayerMsg_MediaConfigRequest(routing_id(), player_id));
 }
 
 void MediaPlayerManagerImpl::OnError(int player_id, int error) {

[commit-bot: I haz the power, 2013-06-06 16:33:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/qinmin@chromium.org/16098014/36001

[commit-bot: I haz the power, 2013-06-06 16:33:25]

Failed to apply patch for content/browser/android/media_player_manager_impl.cc:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file content/browser/android/media_player_manager_impl.cc
  Hunk #1 succeeded at 274 (offset 15 lines).
  Hunk #2 FAILED at 315.
  1 out of 2 hunks FAILED -- saving rejects to file
content/browser/android/media_player_manager_impl.cc.rej

Patch:       content/browser/android/media_player_manager_impl.cc
Index: content/browser/android/media_player_manager_impl.cc
diff --git a/content/browser/android/media_player_manager_impl.cc
b/content/browser/android/media_player_manager_impl.cc
index
8ffc5eaa7b05c93d060419b15df7363b1a3f7686..29edef22efe0af48620e2f794aad2cfd9a0c8269
100644
--- a/content/browser/android/media_player_manager_impl.cc
+++ b/content/browser/android/media_player_manager_impl.cc
@@ -259,10 +259,11 @@ void MediaPlayerManagerImpl::OnReadFromDemuxerAck(
     player->ReadFromDemuxerAck(params);
 }
 
-void MediaPlayerManagerImpl::OnMediaSeekRequestAck(int player_id) {
+void MediaPlayerManagerImpl::OnMediaSeekRequestAck(
+    int player_id, unsigned seek_request_id) {
   MediaPlayerAndroid* player = GetPlayer(player_id);
   if (player)
-    player->OnSeekRequestAck();
+    player->OnSeekRequestAck(seek_request_id);
 }
 
 MediaPlayerAndroid* MediaPlayerManagerImpl::GetPlayer(int player_id) {
@@ -314,14 +315,13 @@ void MediaPlayerManagerImpl::OnSeekComplete(int player_id,
 }
 
 void MediaPlayerManagerImpl::OnMediaSeekRequest(
-    int player_id, base::TimeDelta time_to_seek, bool request_surface) {
-  bool request_texture_peer = request_surface;
-  if (request_surface && player_id == fullscreen_player_id_) {
-    video_view_.CreateContentVideoView();
-    request_texture_peer = false;
-  }
+    int player_id, base::TimeDelta time_to_seek, unsigned seek_request_id) {
   Send(new MediaPlayerMsg_MediaSeekRequest(
-      routing_id(), player_id, time_to_seek, request_texture_peer));
+      routing_id(), player_id, time_to_seek, seek_request_id));
+}
+
+void MediaPlayerManagerImpl::OnMediaConfigRequest(int player_id) {
+  Send(new MediaPlayerMsg_MediaConfigRequest(routing_id(), player_id));
 }
 
 void MediaPlayerManagerImpl::OnError(int player_id, int error) {

[DaleCurtis, 2013-06-06 17:05:18]

https://codereview.chromium.org/16098014/diff/36001/content/common/media/medi...
File content/common/media/media_player_messages_android.h (right):

https://codereview.chromium.org/16098014/diff/36001/content/common/media/medi...
content/common/media/media_player_messages_android.h:1: // Copyright (c) 2012
The Chromium Authors. All rights reserved.
I'm surprised this was able to CQ w/o a security review which all messages files
are supposed to have.  +palmer as an FYI if the OWNERS needs to be fixed.

[qinmin, 2013-06-06 17:07:54]

Hi, Chris, would you please take a look?

[qinmin, 2013-06-06 17:28:40]

Chris, seems there is a bug in OWNERS. 
In content/common/OWNERs, it uses *_messages.h, however, the ipc file here is
named *_messages_android.h, so it doesn't fall into that rule.

[palmer, 2013-06-06 19:01:21]

> Chris, seems there is a bug in OWNERS. 
> In content/common/OWNERs, it uses *_messages.h, however, the ipc file here is
> named *_messages_android.h, so it doesn't fall into that rule.

Thank you, I'll take care of that. I am hoping that meacer or jorgelo can handle
doing the actual code review for this one; I've got my hands full with bug
fixing right now.

[qinmin, 2013-06-06 20:43:25]

Jorge and Mustafa, would any one of you take a look at
media_player_messages_android.h? 

Thanks

[Jorge Lucangeli Obes, 2013-06-06 20:58:16]

On 2013/06/06 20:43:25, qinmin wrote:
> Jorge and Mustafa, would any one of you take a look at
> media_player_messages_android.h? 
> 
> Thanks

I can take a look but not before EOD today.

[meacer, 2013-06-06 21:39:41]

On 2013/06/06 20:43:25, qinmin wrote:
> Jorge and Mustafa, would any one of you take a look at
> media_player_messages_android.h? 
> 
> Thanks

IPC messages lgtm.

[commit-bot: I haz the power, 2013-06-06 21:49:18]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/qinmin@chromium.org/16098014/42001

[commit-bot: I haz the power, 2013-06-07 06:31:06]

Retried try job too often on win_rel for step(s) content_browsertests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-06-07 14:06:27]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/qinmin@chromium.org/16098014/42001

[commit-bot: I haz the power, 2013-06-07 15:21:36]

Change committed as 204844