Reduce jitter from uneven SincResampler buffer size requests.

Reduce jitter from uneven SincResampler buffer size requests.

Ensures all buffer requests are for the same size.  Reduces jitter
by allowing clients with specific buffer size requirements to avoid
overreading.

BUG=none
TEST=media_unittests.
R=crogers@google.com, henrika@chromium.org, sergeyu@chromium.org

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

[DaleCurtis, 2013-04-24 01:32:19]

Hey Chris, he's my WIP enhancements for SincResampler.  Early testing shows it
works fine without any performance penalties if the request size size is a
multiple of 32 (due to losing aligned loads in SSE).

I still need to do some further testing before this is ready for a full review,
but in general how does this look to you?

[Chris Rogers, 2013-04-24 03:25:07]

Thanks Dale, I had a very quick look.  The basic idea of being able to set
"buffering size" seems good.  I'm not so sure we need to actually make sure that
the callbacks are all equal size, just make sure that they happen in somewhat
smaller chunks on average. 

In actual real-world usage, it will be very common to request a certain amount
of output to render and the actual number of times the callback happens will
still jitter given arbitrary ratios.  In other words, the callback will happen
"back-back" several times and a variable number of times.  That's why I don't
think it's necessary to make all the callbacks be the same size, just smaller.

[henrika (OOO until Aug 14), 2013-04-26 08:57:46]

https://codereview.chromium.org/14189035/diff/1/media/base/sinc_resampler.cc
File media/base/sinc_resampler.cc (right):

https://codereview.chromium.org/14189035/diff/1/media/base/sinc_resampler.cc#...
media/base/sinc_resampler.cc:102: CHECK_GT(block_size_, kKernelSize)
Does not compile on Windows:

[1/1] CXX obj\media\base\media.sinc_resampler.obj

FAILED: ninja -t msvc -o obj\media\base\media.sinc_resampler.obj -e
environment.x86 -- cl.exe /nologo /showIncludes /FC
@obj\media\base\media.sinc_resampler.obj.rsp /c
..\..\media\base\sinc_resampler.cc /Foobj\media\base\media.sinc_resampler.obj
/Fdobj\media\media.pdb 

d:\src\chromium\src\base\logging.h(561) : error C2220: warning treated as error
- no 'object' file generated


        d:\src\chromium\src\media\base\sinc_resampler.cc(102) : see reference to
function template instantiation 'std::string
*logging::CheckGTImpl<size_t,>(const t1 &,const t2 &,const char *)' being
compiled


        with


        [


            t1=size_t,


            t2=


        ]


d:\src\chromium\src\base\logging.h(561) : warning C4018: '>' : signed/unsigned
mismatch


ninja: build stopped: subcommand failed.

[DaleCurtis, 2013-04-27 01:18:46]

Should be all cleaned up and ready for review.  The performance is unchanged
relative to the old version!  What I thought were performance problems were just
crappy test data generators taking forever :)

+wez: for remoting/ OWNERS approval.

https://codereview.chromium.org/14189035/diff/12001/media/base/audio_converte...
File media/base/audio_converter_unittest.cc (left):

https://codereview.chromium.org/14189035/diff/12001/media/base/audio_converte...
media/base/audio_converter_unittest.cc:228: FakeAudioRenderCallback
fake_input1(0.2);
Turns out these are pretty slow and vary depending on requested frame size! 
Switching to a NullInputProvider makes the benchmark a lot more useful and
faster.

[henrika (OOO until Aug 14), 2013-04-27 19:43:40]

LGTM w/ nits.

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
File media/base/multi_channel_resampler.cc (right):

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
media/base/multi_channel_resampler.cc:35: // Optimize the single channel case to
avoid chunking.
"chunking"? Is that a well known term?

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
File media/base/multi_channel_resampler.h (right):

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
media/base/multi_channel_resampler.h:32: size_t request_size, const ReadCB&
read_cb);
Perhaps add a comment about the new parameter?

https://codereview.chromium.org/14189035/diff/12001/media/base/sinc_resampler.cc
File media/base/sinc_resampler.cc (right):

https://codereview.chromium.org/14189035/diff/12001/media/base/sinc_resampler...
media/base/sinc_resampler.cc:102: CHECK_GT(block_size_,
static_cast<size_t>(kKernelSize))
Thanks :-)

[Chris Rogers, 2013-04-28 19:50:56]

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
File media/base/multi_channel_resampler.h (right):

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
media/base/multi_channel_resampler.h:36: void Resample(AudioBus* audio_bus, int
frames);
Wouldn't it be better to try to get the callback size to be exactly (or within
one sample-frame) of the amount expected based on |frames| and the
|io_sample_rate_ratio|, instead of always using the same |request_size| as
you're doing here?  For example, if the ratio is 44100/48000 and you ask to
render 480 frames here, then it will call you back asking for 441.  In the
general case it should always be able to be +/- 1 or 2 from the exact amount.

You might want to try instrumenting the AUVarispeed to see how it handles the
requests for more data, I seem to remember it behaves more like this.

[Sergey Ulanov, 2013-04-29 06:23:36]

remoting - LGTM after my comment in audio_encoder_opus.cc is addressed. I also
have a couple of style nits.

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
File media/base/multi_channel_resampler.h (right):

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
media/base/multi_channel_resampler.h:32: size_t request_size, const ReadCB&
read_cb);
nit: one argument per line please:
http://www.chromium.org/developers/coding-style#Code_Formatting

It's not clear if request_size is in bytes or samples. Perhaps it should be
called request_samples?

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
media/base/multi_channel_resampler.h:36: void Resample(AudioBus* audio_bus, int
frames);
unrelated nit: output parameters should be after input parameters:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Functi...

https://codereview.chromium.org/14189035/diff/12001/remoting/codec/audio_enco...
File remoting/codec/audio_encoder_opus.cc (right):

https://codereview.chromium.org/14189035/diff/12001/remoting/codec/audio_enco...
remoting/codec/audio_encoder_opus.cc:83:
media::SincResampler::kDefaultBlockSize,
I think it would be better to mach default frame size we use in opus. Can you
please define kFrameSamples = 960 in this file and use it here instead of
kDefaultBlockSize? (the frame size is defined in audio_decoder_opus.cc, it's
worth adding a reference to that file).

[Sergey Ulanov, 2013-04-29 07:16:54]

https://codereview.chromium.org/14189035/diff/12001/remoting/codec/audio_enco...
File remoting/codec/audio_encoder_opus.cc (right):

https://codereview.chromium.org/14189035/diff/12001/remoting/codec/audio_enco...
remoting/codec/audio_encoder_opus.cc:83:
media::SincResampler::kDefaultBlockSize,
On 2013/04/29 06:23:37, sergeyu wrote:
> I think it would be better to mach default frame size we use in opus. Can you
> please define kFrameSamples = 960 in this file and use it here instead of
> kDefaultBlockSize? (the frame size is defined in audio_decoder_opus.cc, it's
> worth adding a reference to that file).

Sorry, just realized that kFrameSamples is already defined in this file, just
use it here, please :-)

[henrika (OOO until Aug 14), 2013-04-29 09:14:41]

Dale, could you please expose SetRatio in AudioConverter as well since I need it
for my unified audio CL on Windows. Thanks.

[DaleCurtis, 2013-04-29 18:50:03]

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
File media/base/multi_channel_resampler.h (right):

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
media/base/multi_channel_resampler.h:36: void Resample(AudioBus* audio_bus, int
frames);
On 2013/04/28 19:50:56, Chris Rogers wrote:
> Wouldn't it be better to try to get the callback size to be exactly (or within
> one sample-frame) of the amount expected based on |frames| and the
> |io_sample_rate_ratio|, instead of always using the same |request_size| as
> you're doing here?  For example, if the ratio is 44100/48000 and you ask to
> render 480 frames here, then it will call you back asking for 441.  In the
> general case it should always be able to be +/- 1 or 2 from the exact amount.
> 
> You might want to try instrumenting the AUVarispeed to see how it handles the
> requests for more data, I seem to remember it behaves more like this.

Practically I think it amounts to the same thing in almost all cases, except for
possibly hurting mildly in AudioOutputResampler && TabCapture cases, and would
also be a bit harder to implement.

Only <audio> uses disable_fifo which is where your suggestion would help most
(simply in reducing callback counts for abnormal buffer sizes) -- even in that
case we may not want to use the output request size if it's huge and we're
decoding complex material (2048 and 192kHz multichannel for instance).

With a FIFO it doesn't really matter if we request 50 frames twice or 70 frames
once since it'll still result in two callbacks.  Disregarding the added FIFO
overhead: in the best case your solution is the same as my solution; in the
worst, it will hurt mildly worse if it causes back to back requests without the
delay of Convolve() in between.

Finally it's a bit harder to implement because either: we'd need to reallocate
input buffers and resize ranges to handle frame size changes.  Or, since we
don't support frame size changes, refactor Convert() and Resample() to take
their frame sizes during construction.

[Chris Rogers, 2013-04-29 19:38:13]

On 2013/04/29 18:50:03, DaleCurtis wrote:
>
https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
> File media/base/multi_channel_resampler.h (right):
> 
>
https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
> media/base/multi_channel_resampler.h:36: void Resample(AudioBus* audio_bus,
int
> frames);
> On 2013/04/28 19:50:56, Chris Rogers wrote:
> > Wouldn't it be better to try to get the callback size to be exactly (or
within
> > one sample-frame) of the amount expected based on |frames| and the
> > |io_sample_rate_ratio|, instead of always using the same |request_size| as
> > you're doing here?  For example, if the ratio is 44100/48000 and you ask to
> > render 480 frames here, then it will call you back asking for 441.  In the
> > general case it should always be able to be +/- 1 or 2 from the exact
amount.
> > 
> > You might want to try instrumenting the AUVarispeed to see how it handles
the
> > requests for more data, I seem to remember it behaves more like this.
> 
> Practically I think it amounts to the same thing in almost all cases, except
for
> possibly hurting mildly in AudioOutputResampler && TabCapture cases, and would
> also be a bit harder to implement.
> 
> Only <audio> uses disable_fifo which is where your suggestion would help most
> (simply in reducing callback counts for abnormal buffer sizes) -- even in that
> case we may not want to use the output request size if it's huge and we're
> decoding complex material (2048 and 192kHz multichannel for instance).
> 
> With a FIFO it doesn't really matter if we request 50 frames twice or 70
frames
> once since it'll still result in two callbacks.  Disregarding the added FIFO
> overhead: in the best case your solution is the same as my solution; in the
> worst, it will hurt mildly worse if it causes back to back requests without
the
> delay of Convolve() in between.
> 
> Finally it's a bit harder to implement because either: we'd need to reallocate
> input buffers and resize ranges to handle frame size changes.  Or, since we
> don't support frame size changes, refactor Convert() and Resample() to take
> their frame sizes during construction.

Ok, seeing that my suggestion would involve somewhat more work, this seems good
for now.

[DaleCurtis, 2013-04-29 22:12:31]

sergeyu: Haven't made the requested remoting/ change yet, please confirm that's
really what you want.

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
File media/base/multi_channel_resampler.cc (right):

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
media/base/multi_channel_resampler.cc:35: // Optimize the single channel case to
avoid chunking.
On 2013/04/27 19:43:40, henrika wrote:
> "chunking"? Is that a well known term?

Refers to the code section below.  I've updated this comment to be more clear.

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
File media/base/multi_channel_resampler.h (right):

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
media/base/multi_channel_resampler.h:32: size_t request_size, const ReadCB&
read_cb);
On 2013/04/29 06:23:37, Sergey Ulanov wrote:
> nit: one argument per line please:
> http://www.chromium.org/developers/coding-style#Code_Formatting
> 
> It's not clear if request_size is in bytes or samples. Perhaps it should be
> called request_samples?

Renamed to request_frames and added a comment.

https://codereview.chromium.org/14189035/diff/12001/media/base/multi_channel_...
media/base/multi_channel_resampler.h:36: void Resample(AudioBus* audio_bus, int
frames);
On 2013/04/29 06:23:37, Sergey Ulanov wrote:
> unrelated nit: output parameters should be after input parameters:
>
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Functi...

Done.

https://codereview.chromium.org/14189035/diff/12001/remoting/codec/audio_enco...
File remoting/codec/audio_encoder_opus.cc (right):

https://codereview.chromium.org/14189035/diff/12001/remoting/codec/audio_enco...
remoting/codec/audio_encoder_opus.cc:83:
media::SincResampler::kDefaultBlockSize,
On 2013/04/29 07:16:54, Sergey Ulanov wrote:
> On 2013/04/29 06:23:37, sergeyu wrote:
> > I think it would be better to mach default frame size we use in opus. Can
you
> > please define kFrameSamples = 960 in this file and use it here instead of
> > kDefaultBlockSize? (the frame size is defined in audio_decoder_opus.cc, it's
> > worth adding a reference to that file).
> 
> Sorry, just realized that kFrameSamples is already defined in this file, just
> use it here, please :-) 

kFrameSamples appears to refer to the output sample size, not the input sample
size.  Is this still what you want?  If the packet size provided to Encode() is
constant, it seems you'd want to use that value.

[Sergey Ulanov, 2013-05-01 02:06:25]

https://codereview.chromium.org/14189035/diff/12001/remoting/codec/audio_enco...
File remoting/codec/audio_encoder_opus.cc (right):

https://codereview.chromium.org/14189035/diff/12001/remoting/codec/audio_enco...
remoting/codec/audio_encoder_opus.cc:83:
media::SincResampler::kDefaultBlockSize,
On 2013/04/29 22:12:31, DaleCurtis wrote:
> On 2013/04/29 07:16:54, Sergey Ulanov wrote:
> > On 2013/04/29 06:23:37, sergeyu wrote:
> > > I think it would be better to mach default frame size we use in opus. Can
> you
> > > please define kFrameSamples = 960 in this file and use it here instead of
> > > kDefaultBlockSize? (the frame size is defined in audio_decoder_opus.cc,
it's
> > > worth adding a reference to that file).
> > 
> > Sorry, just realized that kFrameSamples is already defined in this file,
just
> > use it here, please :-) 
> 
> kFrameSamples appears to refer to the output sample size, not the input sample
> size.  Is this still what you want?  If the packet size provided to Encode()
is
> constant, it seems you'd want to use that value.

Oh, right. Then it should be frame_size_, which is frame size in input samples.

https://codereview.chromium.org/14189035/diff/12001/remoting/codec/audio_enco...
remoting/codec/audio_encoder_opus.cc:162: int prefetch_samples =
Not sure if prefetching is still required. If not (i.e. if resampler never
requests more than it needs) then please remove it.

[Chris Rogers, 2013-05-06 21:17:31]

Sorry Dale, I thought I had published this draft on Friday.

https://codereview.chromium.org/14189035/diff/42001/media/base/sinc_resampler.cc
File media/base/sinc_resampler.cc (right):

https://codereview.chromium.org/14189035/diff/42001/media/base/sinc_resampler...
media/base/sinc_resampler.cc:43: //    and reinitialize r0_, r3_, and r4_
appropriately.
It's very hard for me to follow this new diagram, and verify exactly what's
happening with the code below.  I literally don't understand it.  It's not clear
what "appropriately" means, etc.

Is there some way to work on the diagram and explanation to help make it more
approachable?  Maybe there's a way to re-frame the description of the algorithm
in different terms (as far as diagram and explanation) without actually changing
the algorithm.

[DaleCurtis, 2013-05-06 22:52:09]

https://codereview.chromium.org/14189035/diff/42001/media/base/sinc_resampler.cc
File media/base/sinc_resampler.cc (right):

https://codereview.chromium.org/14189035/diff/42001/media/base/sinc_resampler...
media/base/sinc_resampler.cc:43: //    and reinitialize r0_, r3_, and r4_
appropriately.
On 2013/05/06 21:17:31, Chris Rogers wrote:
> It's very hard for me to follow this new diagram, and verify exactly what's
> happening with the code below.  I literally don't understand it.  It's not
clear
> what "appropriately" means, etc.
> 
> Is there some way to work on the diagram and explanation to help make it more
> approachable?  Maybe there's a way to re-frame the description of the
algorithm
> in different terms (as far as diagram and explanation) without actually
changing
> the algorithm.

PTAL. I've rewritten the entire documentation section as well as simplified the
number of moving pieces to a single leader: r0_.

[Chris Rogers, 2013-05-07 22:57:52]

Dale, thanks for cleaning up the diagram/comments - that helps a huge amount

lgtm with nits : not sure if we can further cleanup that diagram or not...

https://codereview.chromium.org/14189035/diff/49001/media/base/audio_converte...
File media/base/audio_converter.cc (right):

https://codereview.chromium.org/14189035/diff/49001/media/base/audio_converte...
media/base/audio_converter.cc:77: // The resampler can be configured to work
with a specific buffer size, so a
nit: "specific buffer size" -> "specific request buffer size"

https://codereview.chromium.org/14189035/diff/49001/media/base/sinc_resampler.cc
File media/base/sinc_resampler.cc (right):

https://codereview.chromium.org/14189035/diff/49001/media/base/sinc_resampler...
media/base/sinc_resampler.cc:12: //                                    r0_
(during first load)
You say that "r0_ is always request_frames_ in size" and both line 10 and line
21 show this, and yet the length of these regions is different and is obviously
longer on line 10?

I can see that the start of r0_ is offset by kKernelSize/2 in the 2nd case, but
shouldn't the end of r0_ on line 22 show that it extends by this amount more to
the right?    I know 80-col limit and all, not sure...

Looking further, I guess the reason is that r3_ and r4_ also shift to the right
after the 1st time --- And I know the goal is to keep the diagram concise so
maybe it's best as is, not sure if it can be clarified.

https://codereview.chromium.org/14189035/diff/49001/media/base/sinc_resampler...
media/base/sinc_resampler.cc:18: //                             block_size_ ==
r2_ - r4_
"r2_ - r4_" should be "r4_ - r2_"   ?

https://codereview.chromium.org/14189035/diff/49001/media/base/sinc_resampler...
media/base/sinc_resampler.cc:149: r0_ = second_load ? r0_ + kKernelSize / 2 :
Maybe clearer and safer to change "r0_ + kKernelSize / 2" ->
"input_buffer_.get() + kKernelSize"

In fact, since r0_ is always just an offset from |input_buffer_|, this whole
expression can probably be something like:

r0_ = input_buffer_.get() + (second_load ? kKernelSize : kKernelSize/2)

https://codereview.chromium.org/14189035/diff/49001/media/base/sinc_resampler.h
File media/base/sinc_resampler.h (right):

https://codereview.chromium.org/14189035/diff/49001/media/base/sinc_resampler...
media/base/sinc_resampler.h:28: kDefaultRequestSize = 512,
Maybe we can reduce this down to at least 256 now?  I chose 512 in WebKit since
we were doing offline processing large chunks of data, so chose a larger size.

[DaleCurtis, 2013-05-07 23:49:40]

https://codereview.chromium.org/14189035/diff/12001/remoting/codec/audio_enco...
File remoting/codec/audio_encoder_opus.cc (right):

https://codereview.chromium.org/14189035/diff/12001/remoting/codec/audio_enco...
remoting/codec/audio_encoder_opus.cc:83:
media::SincResampler::kDefaultBlockSize,
On 2013/05/01 02:06:25, Sergey Ulanov wrote:
> On 2013/04/29 22:12:31, DaleCurtis wrote:
> > On 2013/04/29 07:16:54, Sergey Ulanov wrote:
> > > On 2013/04/29 06:23:37, sergeyu wrote:
> > > > I think it would be better to mach default frame size we use in opus.
Can
> > you
> > > > please define kFrameSamples = 960 in this file and use it here instead
of
> > > > kDefaultBlockSize? (the frame size is defined in audio_decoder_opus.cc,
> it's
> > > > worth adding a reference to that file).
> > > 
> > > Sorry, just realized that kFrameSamples is already defined in this file,
> just
> > > use it here, please :-) 
> > 
> > kFrameSamples appears to refer to the output sample size, not the input
sample
> > size.  Is this still what you want?  If the packet size provided to Encode()
> is
> > constant, it seems you'd want to use that value.
> 
> Oh, right. Then it should be frame_size_, which is frame size in input
samples.

Hmm, I'm not sure about this, so I've just kept the original behavior for now
and added a TODO(sergeyu) :)

https://codereview.chromium.org/14189035/diff/49001/media/base/audio_converte...
File media/base/audio_converter.cc (right):

https://codereview.chromium.org/14189035/diff/49001/media/base/audio_converte...
media/base/audio_converter.cc:77: // The resampler can be configured to work
with a specific buffer size, so a
On 2013/05/07 22:57:53, Chris Rogers wrote:
> nit: "specific buffer size" -> "specific request buffer size"

Changed to request size for consistency with SincResampler.

https://codereview.chromium.org/14189035/diff/49001/media/base/sinc_resampler.cc
File media/base/sinc_resampler.cc (right):

https://codereview.chromium.org/14189035/diff/49001/media/base/sinc_resampler...
media/base/sinc_resampler.cc:12: //                                    r0_
(during first load)
On 2013/05/07 22:57:53, Chris Rogers wrote:
> You say that "r0_ is always request_frames_ in size" and both line 10 and line
> 21 show this, and yet the length of these regions is different and is
obviously
> longer on line 10?
> 
> I can see that the start of r0_ is offset by kKernelSize/2 in the 2nd case,
but
> shouldn't the end of r0_ on line 22 show that it extends by this amount more
to
> the right?    I know 80-col limit and all, not sure...
> 
> Looking further, I guess the reason is that r3_ and r4_ also shift to the
right
> after the 1st time --- And I know the goal is to keep the diagram concise so
> maybe it's best as is, not sure if it can be clarified.

Yeah, I ran out of space here and without shrinking the rest of the graph (hard
to do and keep labels), the ellipsis on line 22 is as best as I can do.

https://codereview.chromium.org/14189035/diff/49001/media/base/sinc_resampler...
media/base/sinc_resampler.cc:18: //                             block_size_ ==
r2_ - r4_
On 2013/05/07 22:57:53, Chris Rogers wrote:
> "r2_ - r4_" should be "r4_ - r2_"   ?

Done.

https://codereview.chromium.org/14189035/diff/49001/media/base/sinc_resampler...
media/base/sinc_resampler.cc:149: r0_ = second_load ? r0_ + kKernelSize / 2 :
On 2013/05/07 22:57:53, Chris Rogers wrote:
> Maybe clearer and safer to change "r0_ + kKernelSize / 2" ->
> "input_buffer_.get() + kKernelSize"
> 
> In fact, since r0_ is always just an offset from |input_buffer_|, this whole
> expression can probably be something like:
> 
> r0_ = input_buffer_.get() + (second_load ? kKernelSize : kKernelSize/2)

Done.

https://codereview.chromium.org/14189035/diff/49001/media/base/sinc_resampler.h
File media/base/sinc_resampler.h (right):

https://codereview.chromium.org/14189035/diff/49001/media/base/sinc_resampler...
media/base/sinc_resampler.h:28: kDefaultRequestSize = 512,
On 2013/05/07 22:57:53, Chris Rogers wrote:
> Maybe we can reduce this down to at least 256 now?  I chose 512 in WebKit
since
> we were doing offline processing large chunks of data, so chose a larger size.

I'd like to do that in a different CL since I'm worried about impacts on the
non-FIFO cases in AudioConverter and OpusEncoder.

[commit-bot: I haz the power, 2013-05-08 14:12:43]

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

[commit-bot: I haz the power, 2013-05-08 22:22:39]

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

[DaleCurtis, 2013-05-08 22:53:32]

Committed patchset #6 manually as r199032 (presubmit successful).