Roll FFMpeg for M26. Fix ffmpeg float audio decoding.

Roll FFMpeg for M26. Fix ffmpeg float audio decoding.

FFmpeg now outputs float for some audio decoders.  Unfortunately our pipeline
doesn't support float between the FFmpegAudioDecoder and AudioRenderer at
present.  As such, we need to convert the data into an integer format first.

As a byproduct of this, AMR support for ChromeOS is finally fixed and adding
support for PCM float is trivial.

In summary this patch adds:
- A SampleFormat property to AudioDecoderConfig.
- AVSampleFormat <-> SampleFormat converters in FFmpegCommon.
- Fixes ChromeOS AMR playback.
- Finally plumbs pcm_f32le support (enabled in FFmpeg long ago).
- Add decoder support for float planar and float interleaved playback.

BUG=109085, 158187, 167069
TEST=unittests, layout tests, and demos all pass under tooling without issue.

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

[DaleCurtis, 2012-12-05 21:35:45]

FFmpeg roll is still in testing, but this should be the complete Chrome side
change minus a DEPS update.

[DaleCurtis, 2012-12-05 21:43:31]

+rbultje to ensure I'm not forgetting something in FFmpeg land.
cc:xhwang for cdm stuff.

[rbultje1, 2012-12-05 21:48:38]

Did you re-apply the x86inc.asm manual re-alignment (for MSVC x86 assembly)
patch? It's still not landed upstream...

[DaleCurtis, 2012-12-05 22:19:27]

I haven't done Windows testing yet, but there were no conflicts in that area
during the merge, so I just left it applied.

[rbultje1, 2012-12-05 22:20:17]

On 2012/12/05 22:19:27, DaleCurtis wrote:
> I haven't done Windows testing yet, but there were no conflicts in that area
> during the merge, so I just left it applied.

OK, that's all I have, so assuming tests pass, lgtm.

[scherkus (not reviewing), 2012-12-06 17:25:31]

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
File media/base/audio_decoder_config.cc (right):

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
media/base/audio_decoder_config.cc:65: // vorbis are going to be kFormatFLTP.
Float PCM and AMR will be kFormatFLT.
is there any way to get the pre-conversion-to-float data?

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
media/base/audio_decoder_config.cc:65: // vorbis are going to be kFormatFLTP.
Float PCM and AMR will be kFormatFLT.
s/kFormat/kSampleFormat/g

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
File media/base/audio_decoder_config.h (right):

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
media/base/audio_decoder_config.h:46: kSampleFormatFLT,   // Float.
perhaps instead of "FLT" we go with "F32" to denote the size of the float

also I don't find the "P" suffix to be very clear -- F32Planar?

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
media/base/audio_decoder_config.h:61: AudioDecoderConfig(AudioCodec codec, int
bits_per_channel,
is bits_per_channel still worth carrying around if we now include a SampleFormat
enum?

U8/S16/S32 all specify their bits per channel and float is typically understood
to be 32-bit

what does it mean to pass in 16 + kSampleFormatU8?

https://codereview.chromium.org/11280301/diff/2001/media/filters/audio_file_r...
File media/filters/audio_file_reader.cc (right):

https://codereview.chromium.org/11280301/diff/2001/media/filters/audio_file_r...
media/filters/audio_file_reader.cc:172: for(int ch = 0; ch < channels; ++ch) {
space after "for"

https://codereview.chromium.org/11280301/diff/2001/media/filters/ffmpeg_audio...
File media/filters/ffmpeg_audio_decoder.cc (right):

https://codereview.chromium.org/11280301/diff/2001/media/filters/ffmpeg_audio...
media/filters/ffmpeg_audio_decoder.cc:351: // AudioBus::ToInterleaved() to
convert the data as necessary.
don't we immediately call FromInterleaved() in ARI::Render()?

do you have a plan in mind for minimizing data format conversions? it seems
unfortunate for audio decoders to deal with converting to planar integer

[DaleCurtis, 2012-12-06 22:15:41]

(no changes in this message, just comments)

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
File media/base/audio_decoder_config.cc (right):

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
media/base/audio_decoder_config.cc:65: // vorbis are going to be kFormatFLTP.
Float PCM and AMR will be kFormatFLT.
On 2012/12/06 17:25:32, scherkus wrote:
> is there any way to get the pre-conversion-to-float data?

The data isn't converted to float, it's decoded in float, in older FFMpeg
versions it was immediately converted S16.  Now it's provided as is.

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
File media/base/audio_decoder_config.h (right):

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
media/base/audio_decoder_config.h:61: AudioDecoderConfig(AudioCodec codec, int
bits_per_channel,
On 2012/12/06 17:25:32, scherkus wrote:
> is bits_per_channel still worth carrying around if we now include a
SampleFormat
> enum?
> 
> U8/S16/S32 all specify their bits per channel and float is typically
understood
> to be 32-bit
> 
> what does it mean to pass in 16 + kSampleFormatU8?

Good point, I think it's better to remove bits per channel in favor of the
sample format.

https://codereview.chromium.org/11280301/diff/2001/media/filters/ffmpeg_audio...
File media/filters/ffmpeg_audio_decoder.cc (right):

https://codereview.chromium.org/11280301/diff/2001/media/filters/ffmpeg_audio...
media/filters/ffmpeg_audio_decoder.cc:351: // AudioBus::ToInterleaved() to
convert the data as necessary.
On 2012/12/06 17:25:32, scherkus wrote:
> don't we immediately call FromInterleaved() in ARI::Render()?
> 
> do you have a plan in mind for minimizing data format conversions? it seems
> unfortunate for audio decoders to deal with converting to planar integer

Not quite immediately, but yes.  The data first goes into a
AudioRendererAlgorithm's SeekableBuffer which handles time advancement as well
as buffer hand outs.

Ideally I'd like to pass an AudioBus out of the decoder at some point, but that
involves reworking AudioRendererAlgorithm.  Wd need to replace its use of
SeekableBuffer with something like an AudioFIFO which understands timestamp
information.

[DaleCurtis, 2012-12-11 03:03:44]

PTAL.

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
File media/base/audio_decoder_config.cc (right):

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
media/base/audio_decoder_config.cc:65: // vorbis are going to be kFormatFLTP.
Float PCM and AMR will be kFormatFLT.
On 2012/12/06 22:15:41, DaleCurtis wrote:
> On 2012/12/06 17:25:32, scherkus wrote:
> > is there any way to get the pre-conversion-to-float data?
> 
> The data isn't converted to float, it's decoded in float, in older FFMpeg
> versions it was immediately converted S16.  Now it's provided as is.

Also I don't intend to check this message in, I was more looking for feedback if
it's worth adding them to the UMA collection. WDYT?

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
File media/base/audio_decoder_config.h (right):

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
media/base/audio_decoder_config.h:46: kSampleFormatFLT,   // Float.
On 2012/12/06 17:25:32, scherkus wrote:
> perhaps instead of "FLT" we go with "F32" to denote the size of the float
> 
> also I don't find the "P" suffix to be very clear -- F32Planar?

Went with F32 an PlanarF32.

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
media/base/audio_decoder_config.h:61: AudioDecoderConfig(AudioCodec codec, int
bits_per_channel,
On 2012/12/06 22:15:41, DaleCurtis wrote:
> On 2012/12/06 17:25:32, scherkus wrote:
> > is bits_per_channel still worth carrying around if we now include a
> SampleFormat
> > enum?
> > 
> > U8/S16/S32 all specify their bits per channel and float is typically
> understood
> > to be 32-bit
> > 
> > what does it mean to pass in 16 + kSampleFormatU8?
> 
> Good point, I think it's better to remove bits per channel in favor of the
> sample format.

Done.

https://codereview.chromium.org/11280301/diff/2001/media/filters/audio_file_r...
File media/filters/audio_file_reader.cc (right):

https://codereview.chromium.org/11280301/diff/2001/media/filters/audio_file_r...
media/filters/audio_file_reader.cc:172: for(int ch = 0; ch < channels; ++ch) {
On 2012/12/06 17:25:32, scherkus wrote:
> space after "for"

Done.

[scherkus (not reviewing), 2012-12-11 21:18:46]

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
File media/base/audio_decoder_config.cc (right):

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
media/base/audio_decoder_config.cc:65: // vorbis are going to be kFormatFLTP.
Float PCM and AMR will be kFormatFLT.
On 2012/12/11 03:03:44, DaleCurtis wrote:
> On 2012/12/06 22:15:41, DaleCurtis wrote:
> > On 2012/12/06 17:25:32, scherkus wrote:
> > > is there any way to get the pre-conversion-to-float data?
> > 
> > The data isn't converted to float, it's decoded in float, in older FFMpeg
> > versions it was immediately converted S16.  Now it's provided as is.
> 
> Also I don't intend to check this message in, I was more looking for feedback
if
> it's worth adding them to the UMA collection. WDYT?

What about deprecating AudioBitsPerChannel in favour of recording the
SampleFormat enum otherwise our 32-bit bucket is about to get inflated w/o
anyway to distinguish float vs integer vs planar

[DaleCurtis, 2012-12-12 01:02:57]

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
File media/base/audio_decoder_config.cc (right):

https://codereview.chromium.org/11280301/diff/2001/media/base/audio_decoder_c...
media/base/audio_decoder_config.cc:65: // vorbis are going to be kFormatFLTP.
Float PCM and AMR will be kFormatFLT.
On 2012/12/11 21:18:47, scherkus wrote:
> On 2012/12/11 03:03:44, DaleCurtis wrote:
> > On 2012/12/06 22:15:41, DaleCurtis wrote:
> > > On 2012/12/06 17:25:32, scherkus wrote:
> > > > is there any way to get the pre-conversion-to-float data?
> > > 
> > > The data isn't converted to float, it's decoded in float, in older FFMpeg
> > > versions it was immediately converted S16.  Now it's provided as is.
> > 
> > Also I don't intend to check this message in, I was more looking for
feedback
> if
> > it's worth adding them to the UMA collection. WDYT?
> 
> What about deprecating AudioBitsPerChannel in favour of recording the
> SampleFormat enum otherwise our 32-bit bucket is about to get inflated w/o
> anyway to distinguish float vs integer vs planar

Done.

[scherkus (not reviewing), 2012-12-12 23:04:25]

lgtm... but I see a lot of media_unittest failures

know what's up?

[DaleCurtis, 2012-12-12 23:29:36]

On 2012/12/12 23:04:25, scherkus wrote:
> lgtm... but I see a lot of media_unittest failures
> 
> know what's up?

Hard to tell, something is corrupting the logs it looks like. I though it was a
bad DCHECK, but looks like there might be another issue too. Digging now.

[DaleCurtis, 2012-12-12 23:44:11]

On 2012/12/12 23:29:36, DaleCurtis wrote:
> On 2012/12/12 23:04:25, scherkus wrote:
> > lgtm... but I see a lot of media_unittest failures
> > 
> > know what's up?
> 
> Hard to tell, something is corrupting the logs it looks like. I though it was
a
> bad DCHECK, but looks like there might be another issue too. Digging now.

Ah, acolwell's recent patch dropped initialization of bytes_per_frame_ leading
to a FP-error when doing % 0. Fixed.

[scherkus (not reviewing), 2012-12-13 00:12:16]

On 2012/12/12 23:44:11, DaleCurtis wrote:
> On 2012/12/12 23:29:36, DaleCurtis wrote:
> > On 2012/12/12 23:04:25, scherkus wrote:
> > > lgtm... but I see a lot of media_unittest failures
> > > 
> > > know what's up?
> > 
> > Hard to tell, something is corrupting the logs it looks like. I though it
was
> a
> > bad DCHECK, but looks like there might be another issue too. Digging now.
> 
> Ah, acolwell's recent patch dropped initialization of bytes_per_frame_ leading
> to a FP-error when doing % 0. Fixed.

lgtm++ assuming you fix it :)

[DaleCurtis, 2012-12-13 02:39:38]

New patch set should fix all unittests. I'll run a more thorough manual pass
tomorrow.

https://codereview.chromium.org/11280301/diff/39002/media/filters/ffmpeg_audi...
File media/filters/ffmpeg_audio_decoder.cc (right):

https://codereview.chromium.org/11280301/diff/39002/media/filters/ffmpeg_audi...
media/filters/ffmpeg_audio_decoder.cc:298:
DCHECK_EQ(static_cast<size_t>(config.bits_per_channel() / 8),
Fails since MediaSource configures S16 in the decoder config. I could have it
specify float, but that means MediaSource has to know about ffmpeg internals.
Instead I've chosen to adjust the decoded_audio_size as necessary.

[DaleCurtis, 2012-12-13 08:10:29]

Whoops, last patch set fixes unittests, but needs some work. Will update
tomorrow.

[DaleCurtis, 2012-12-13 21:06:01]

Latest patch set is ready minus some windows hash fixes, will add #if OS_WIN for
those once my windows box finsihes its security updates :)

[rbultje1, 2012-12-13 22:22:10]

On 2012/12/13 21:06:01, DaleCurtis wrote:
> Latest patch set is ready minus some windows hash fixes, will add #if OS_WIN
for
> those once my windows box finsihes its security updates :)

Why did the hashes change? Is that for fuzzed files?

[DaleCurtis, 2012-12-13 22:22:56]

On 2012/12/13 22:22:10, rbultje1 wrote:
> On 2012/12/13 21:06:01, DaleCurtis wrote:
> > Latest patch set is ready minus some windows hash fixes, will add #if OS_WIN
> for
> > those once my windows box finsihes its security updates :)
> 
> Why did the hashes change? Is that for fuzzed files?

No, the hashes come out differently on Windows vs Mac. Last we talked about this
you said it was due to differences in float decoding. Is that not the case?

[rbultje1, 2012-12-13 22:24:00]

On 2012/12/13 22:22:56, DaleCurtis wrote:
> On 2012/12/13 22:22:10, rbultje1 wrote:
> > On 2012/12/13 21:06:01, DaleCurtis wrote:
> > > Latest patch set is ready minus some windows hash fixes, will add #if
OS_WIN
> > for
> > > those once my windows box finsihes its security updates :)
> > 
> > Why did the hashes change? Is that for fuzzed files?
> 
> No, the hashes come out differently on Windows vs Mac. Last we talked about
this
> you said it was due to differences in float decoding. Is that not the case?

Oh audio hashes? Sorry, misunderstood, I thought it was video hashes. You're
correct about audio, yes.

[rbultje1, 2012-12-13 22:24:38]

On 2012/12/13 22:24:00, rbultje1 wrote:
> On 2012/12/13 22:22:56, DaleCurtis wrote:
> > On 2012/12/13 22:22:10, rbultje1 wrote:
> > > On 2012/12/13 21:06:01, DaleCurtis wrote:
> > > > Latest patch set is ready minus some windows hash fixes, will add #if
> OS_WIN
> > > for
> > > > those once my windows box finsihes its security updates :)
> > > 
> > > Why did the hashes change? Is that for fuzzed files?
> > 
> > No, the hashes come out differently on Windows vs Mac. Last we talked about
> this
> > you said it was due to differences in float decoding. Is that not the case?
> 
> Oh audio hashes? Sorry, misunderstood, I thought it was video hashes. You're
> correct about audio, yes.

Also, ideally we'd replace these with reference checks (in integer format) with
off-by-one allowance to account for float rounding errors. But that can be done
later.

[scherkus (not reviewing), 2012-12-13 22:40:11]

few qs

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
File media/filters/audio_file_reader.cc (right):

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
media/filters/audio_file_reader.cc:82: // MP3 decodes to S16P which we don't
support, tell it to use S16 instead.
should we also be checking the codec id?

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
media/filters/audio_file_reader.cc:83: bool request_s16_format =
codec_context_->sample_fmt == AV_SAMPLE_FMT_S16P;
how about instead of a bool (which I found a bit tricky to follow), we use the
notion of an expected format? should we need to change/expand the code it'll fit
in nicely


AVSampleFormat expected = codec_context_->sample_fmt;

// MP3 blah blah blah
if (codec_context_->sample_fmt == AV_SAMPLE_FMT_S16P) {
  expected = AV_SAMPLE_FMT_S16;
} else if (some other requirement) {
   expected = // etc...
}

codec_context_->sample_fmt = expected;

// open

if (codec_context_->sample_fmt != expected) {
  // blah blah
}

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
File media/filters/audio_file_reader_unittest.cc (right):

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
media/filters/audio_file_reader_unittest.cc:89: // point functions (e.g. sin(),
cos(), etc).
and this is a new thing in the latest roll?

what changed? is there a specific chromium/ffmpeg revision we can reference?

https://codereview.chromium.org/11280301/diff/57001/media/filters/ffmpeg_audi...
File media/filters/ffmpeg_audio_decoder.cc (right):

https://codereview.chromium.org/11280301/diff/57001/media/filters/ffmpeg_audi...
media/filters/ffmpeg_audio_decoder.cc:288: bool request_s16_format =
codec_context_->sample_fmt == AV_SAMPLE_FMT_S16P;
ditto

[DaleCurtis, 2012-12-13 22:51:28]

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
File media/filters/audio_file_reader.cc (right):

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
media/filters/audio_file_reader.cc:82: // MP3 decodes to S16P which we don't
support, tell it to use S16 instead.
On 2012/12/13 22:40:11, scherkus wrote:
> should we also be checking the codec id?

We could but, but this is more generic and the check if() check on the sample
format will catch failures.

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
media/filters/audio_file_reader.cc:83: bool request_s16_format =
codec_context_->sample_fmt == AV_SAMPLE_FMT_S16P;
On 2012/12/13 22:40:11, scherkus wrote:
> how about instead of a bool (which I found a bit tricky to follow), we use the
> notion of an expected format? should we need to change/expand the code it'll
fit
> in nicely
> 
> 
> AVSampleFormat expected = codec_context_->sample_fmt;
> 
> // MP3 blah blah blah
> if (codec_context_->sample_fmt == AV_SAMPLE_FMT_S16P) {
>   expected = AV_SAMPLE_FMT_S16;
> } else if (some other requirement) {
>    expected = // etc...
> }
> 
> codec_context_->sample_fmt = expected;
> 
> // open
> 
> if (codec_context_->sample_fmt != expected) {
>   // blah blah
> }
> 

Sounds good. Will do so in next patch set.

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
File media/filters/audio_file_reader_unittest.cc (right):

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
media/filters/audio_file_reader_unittest.cc:89: // point functions (e.g. sin(),
cos(), etc).
On 2012/12/13 22:40:11, scherkus wrote:
> and this is a new thing in the latest roll?
> 
> what changed? is there a specific chromium/ffmpeg revision we can reference?

This is due to the switch to float decoding. It's not new, this is also the
cause of the PerfAV failures in the WebAudio LayoutTests. As ronald mentions its
due to off by 1 rounding errors.

I could change the test to hash the ToInterleaved int16 data instead which would
probably fix this.

[DaleCurtis, 2012-12-14 20:48:32]

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
File media/filters/audio_file_reader.cc (right):

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
media/filters/audio_file_reader.cc:83: bool request_s16_format =
codec_context_->sample_fmt == AV_SAMPLE_FMT_S16P;
On 2012/12/13 22:51:28, DaleCurtis wrote:
> On 2012/12/13 22:40:11, scherkus wrote:
> > how about instead of a bool (which I found a bit tricky to follow), we use
the
> > notion of an expected format? should we need to change/expand the code it'll
> fit
> > in nicely
> > 
> > 
> > AVSampleFormat expected = codec_context_->sample_fmt;
> > 
> > // MP3 blah blah blah
> > if (codec_context_->sample_fmt == AV_SAMPLE_FMT_S16P) {
> >   expected = AV_SAMPLE_FMT_S16;
> > } else if (some other requirement) {
> >    expected = // etc...
> > }
> > 
> > codec_context_->sample_fmt = expected;
> > 
> > // open
> > 
> > if (codec_context_->sample_fmt != expected) {
> >   // blah blah
> > }
> > 
> 
> Sounds good. Will do so in next patch set.

Done.

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
File media/filters/audio_file_reader_unittest.cc (right):

https://codereview.chromium.org/11280301/diff/57001/media/filters/audio_file_...
media/filters/audio_file_reader_unittest.cc:89: // point functions (e.g. sin(),
cos(), etc).
On 2012/12/13 22:51:28, DaleCurtis wrote:
> On 2012/12/13 22:40:11, scherkus wrote:
> > and this is a new thing in the latest roll?
> > 
> > what changed? is there a specific chromium/ffmpeg revision we can reference?
> 
> This is due to the switch to float decoding. It's not new, this is also the
> cause of the PerfAV failures in the WebAudio LayoutTests. As ronald mentions
its
> due to off by 1 rounding errors.
> 
> I could change the test to hash the ToInterleaved int16 data instead which
would
> probably fix this.

Interleaving to int16 and hashing wasn't enough to fix the inconsistencies.

[scherkus (not reviewing), 2012-12-14 20:50:10]

lgtm

[commit-bot: I haz the power, 2012-12-15 00:46:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dalecurtis@chromium.org/11280301/52008

[commit-bot: I haz the power, 2012-12-15 01:02:54]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dalecurtis@chromium.org/11280301/54004

[Paweł Hajdan Jr., 2012-12-18 18:10:19]

CQ has aborted processing for some reason.

Do you want to try again, or possibly land manually?

[DaleCurtis, 2012-12-18 18:35:27]

On 2012/12/18 18:10:19, Paweł Hajdan Jr. wrote:
> CQ has aborted processing for some reason.
> 
> Do you want to try again, or possibly land manually?

I aborted it due to test failures (inconsistent hashing on bots vs local). Will
land post-M25; it's too risky to land this so close to the branch point.

[Paweł Hajdan Jr., 2013-01-02 20:17:18]

On 2012/12/18 18:35:27, DaleCurtis wrote:
> On 2012/12/18 18:10:19, Paweł Hajdan Jr. wrote:
> > CQ has aborted processing for some reason.
> > 
> > Do you want to try again, or possibly land manually?
> 
> I aborted it due to test failures (inconsistent hashing on bots vs local).
Will
> land post-M25; it's too risky to land this so close to the branch point.

friendly ping :) We're post-M25 now, should be safe.

[DaleCurtis, 2013-01-03 19:20:05]

Rebased, hash checks disabled for float audio for now, filed
http://crbug.com/168204 to track. CQ'ing.

[commit-bot: I haz the power, 2013-01-03 19:21:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dalecurtis@chromium.org/11280301/70001

[commit-bot: I haz the power, 2013-01-03 19:41:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dalecurtis@chromium.org/11280301/83001

[commit-bot: I haz the power, 2013-01-03 20:44:23]

Retried try job too often on win_rel for step(s) browser_tests