MediaCodecPlayer implementation (stage 5 - reconfiguration)

MediaCodecPlayer implementation (stage 5 - reconfiguration)

This CL addresses a simple case when reconfiguration does
not interfere with prerolling or simultaneous reconfig on
another stream.

When decoder detects that reconfiguration is required,
it enqueues EOS to drain itself. After the drain is completed
the decoder releases the media codec and posts notification to
the player.

The release of the media codec marks that this decoder would
need preroll.

Upon receiving the notificaton the player requests to stop another
stream and also marks it for preroll. The player also sets
the pending start.

After the stop is completed the player will restart,
recreating the deleted MediaCodec and performing the preroll.

BUG=407577
Committed: https://crrev.com/39392412c833b080409464a2d875ccfcfeb23b5c
Cr-Commit-Position: refs/heads/master@{#346276}

[Tima Vaisburd, 2015-08-13 23:18:45]

timav@chromium.org changed reviewers:
+ qinmin@chromium.org

[Tima Vaisburd, 2015-08-13 23:18:46]

Not tested yet. No real unit tests as well.

[Tima Vaisburd, 2015-08-20 01:29:29]

I restored the original place where I post OnDecoderDrained callback. After that
as far as I see audio frames should not be skipped. There is a theoretical
possibility that the video frame(s) can be skipped if audio would be slow to
stop and restart, but I did not see it in reality.

Please take a look.

[qinmin, 2015-08-20 19:41:25]

https://codereview.chromium.org/1287423004/diff/40001/media/base/android/acce...
File media/base/android/access_unit_queue.h (right):

https://codereview.chromium.org/1287423004/diff/40001/media/base/android/acce...
media/base/android/access_unit_queue.h:73: // Request to emulate config changes
for some key frames.
I don't understand this. Why is this function needed? what is the usecase?

https://codereview.chromium.org/1287423004/diff/40001/media/base/android/medi...
File media/base/android/media_codec_video_decoder.cc (right):

https://codereview.chromium.org/1287423004/diff/40001/media/base/android/medi...
media/base/android/media_codec_video_decoder.cc:39: // Generate |kConfigChanged|
before every key frame
why we need this? cannot we just do that in test by outselves?

[Tima Vaisburd, 2015-08-20 20:05:22]

https://codereview.chromium.org/1287423004/diff/40001/media/base/android/medi...
File media/base/android/media_codec_video_decoder.cc (right):

https://codereview.chromium.org/1287423004/diff/40001/media/base/android/medi...
media/base/android/media_codec_video_decoder.cc:39: // Generate |kConfigChanged|
before every key frame
On 2015/08/20 19:41:25, qinmin wrote:
> why we need this? cannot we just do that in test by outselves?

It was intended not for the unit tests, but for testing real stream (e.g. from
YouTube) and forcing artificial reconfiguration for every key frame.

I take it that it's better to remove this code, and I will remove it.

[Tima Vaisburd, 2015-08-20 20:36:21]

On 2015/08/20 20:05:22, Tima Vaisburd wrote:
>
https://codereview.chromium.org/1287423004/diff/40001/media/base/android/medi...
> File media/base/android/media_codec_video_decoder.cc (right):
> 
>
https://codereview.chromium.org/1287423004/diff/40001/media/base/android/medi...
> media/base/android/media_codec_video_decoder.cc:39: // Generate
|kConfigChanged|
> before every key frame
> On 2015/08/20 19:41:25, qinmin wrote:
> > why we need this? cannot we just do that in test by outselves?
> 
> It was intended not for the unit tests, but for testing real stream (e.g. from
> YouTube) and forcing artificial reconfiguration for every key frame.
> 
> I take it that it's better to remove this code, and I will remove it.

Deleted. Sorry.

[qinmin, 2015-08-21 18:37:53]

https://codereview.chromium.org/1287423004/diff/80001/media/base/android/acce...
File media/base/android/access_unit_queue.cc (right):

https://codereview.chromium.org/1287423004/diff/80001/media/base/android/acce...
media/base/android/access_unit_queue.cc:197:
DCHECK((*chunk)->demuxer_configs.size() == 1);
doesn't this impacts GetInfo() call above?
so if the returned result is 0, getInfo() will not try initialize the
info.configs field.

https://codereview.chromium.org/1287423004/diff/80001/media/base/android/test...
File media/base/android/test_data_factory.cc (right):

https://codereview.chromium.org/1287423004/diff/80001/media/base/android/test...
media/base/android/test_data_factory.cc:95: if (i == 3 &&
HasReconfigForInterval(chunk->access_units[0].timestamp,
move the if statement outside the loop
just do:

for(int i=0; i <3; ++i) {
  .....
}
if (....)
  AddConfiguration(chunk);

[Tima Vaisburd, 2015-08-25 22:57:30]

I ran the tests on two devices, Nexus 4 (Android 4.4) and Nexus 5 (Android 5).
They did not skip video frames, however, there is no mechanism that guarantees
that.

On the other hand maybe we want to let Android 4.1 devices skip frames sometimes
at the sake of code simplicity. What do you think?

https://codereview.chromium.org/1287423004/diff/80001/media/base/android/acce...
File media/base/android/access_unit_queue.cc (right):

https://codereview.chromium.org/1287423004/diff/80001/media/base/android/acce...
media/base/android/access_unit_queue.cc:197:
DCHECK((*chunk)->demuxer_configs.size() == 1);
On 2015/08/21 18:37:53, qinmin wrote:
> doesn't this impacts GetInfo() call above?
> so if the returned result is 0, getInfo() will not try initialize the
> info.configs field.

Yes, it's a bug. I added another length, |data_length| to Info.

https://codereview.chromium.org/1287423004/diff/80001/media/base/android/test...
File media/base/android/test_data_factory.cc (right):

https://codereview.chromium.org/1287423004/diff/80001/media/base/android/test...
media/base/android/test_data_factory.cc:95: if (i == 3 &&
HasReconfigForInterval(chunk->access_units[0].timestamp,
On 2015/08/21 18:37:53, qinmin wrote:
> move the if statement outside the loop
> just do:
> 
> for(int i=0; i <3; ++i) {
>   .....
> }
> if (....)
>   AddConfiguration(chunk);

Done.

[Tima Vaisburd, 2015-08-26 22:16:35]

Rebased

[Tima Vaisburd, 2015-08-27 19:04:51]

The latest patch set follows Min's idea to have zero preroll timestamp after the
decoder drained. Thus we should avoid skipping frames in case of preroll
timestamp went forward.

I changed bool |needs_preroll_| into enum |PrerollMode| and disregard preroll
timestamp in one of the modes.

This guarantees that we do not skip frames during prerolling phase, but
increases the chances that the video will need to catch up this audio after this
preroll. With the current policy of skipping the late frames diring the regular
playback these late frames will be skipped anyway, but at least there should be
no audio skips.

Please advise on whether you think it is a reasonable addition. On the other
hand we might let the frames to be skipped and have just one preroll mode since
we believe that decoder drain will be a rare case past Android JellyBean.

[Tima Vaisburd, 2015-08-27 19:05:12]

timav@chromium.org changed reviewers:
+ liberato@chromium.org

[qinmin, 2015-08-27 19:38:42]

lgtm % comments

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/acc...
File media/base/android/access_unit_queue.h (right):

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/acc...
media/base/android/access_unit_queue.h:81: // Returns the total number of access
(total_length) and the number of units
s/access/access units/

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
File media/base/android/media_codec_decoder.h (right):

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
media/base/android/media_codec_decoder.h:192: // Sets preroll mode to
kPrerollTillNextFrame.
PrerollTillNextFrame is protected and its hard for external class to know what
this means.
What about DecodeUtilOutputArePresent();

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
media/base/android/media_codec_decoder.h:235: // Drain decoder and reconfigure
for each |kConfigChanged|.
s/Drain/Drains/ 
s/reconfigure/reconfigures/

[Tima Vaisburd, 2015-08-27 20:39:47]

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/acc...
File media/base/android/access_unit_queue.h (right):

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/acc...
media/base/android/access_unit_queue.h:81: // Returns the total number of access
(total_length) and the number of units
On 2015/08/27 19:38:42, qinmin wrote:
> s/access/access units/

Done.

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
File media/base/android/media_codec_decoder.h (right):

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
media/base/android/media_codec_decoder.h:192: // Sets preroll mode to
kPrerollTillNextFrame.
On 2015/08/27 19:38:42, qinmin wrote:
> PrerollTillNextFrame is protected and its hard for external class to know what
> this means.
> What about DecodeUtilOutputArePresent();

I did SetDecodingUntilOutputIsPresent() and changed the comment.

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
media/base/android/media_codec_decoder.h:235: // Drain decoder and reconfigure
for each |kConfigChanged|.
On 2015/08/27 19:38:42, qinmin wrote:
> s/Drain/Drains/ 
> s/reconfigure/reconfigures/

Done.

[liberato (no reviews please), 2015-08-27 20:42:27]

still getting my head wrapped around this.

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
File media/base/android/media_codec_decoder.cc (right):

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
media/base/android/media_codec_decoder.cc:273: preroll_timestamp_ =
(preroll_mode_ == kPrerollTillPTS) ? preroll_timestamp
i don't understand this part.

in TillNextFrame, it looks like preroll_timestamp will be in the past (from the
first preroll).  won't that end up rendering frames during the preroll?

i'm pretty sure that i've misunderstood something.

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
File media/base/android/media_codec_player_unittest.cc (right):

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
media/base/android/media_codec_player_unittest.cc:1759:
WaitForDelay(base::TimeDelta::FromMilliseconds(100));
can this be converted to a WaitForCondition or callback?  100msec is pretty
short.

[liberato (no reviews please), 2015-08-27 20:42:27]

still getting my head wrapped around this.

[Tima Vaisburd, 2015-08-27 22:04:19]

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
File media/base/android/media_codec_decoder.cc (right):

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
media/base/android/media_codec_decoder.cc:273: preroll_timestamp_ =
(preroll_mode_ == kPrerollTillPTS) ? preroll_timestamp
On 2015/08/27 20:42:26, liberato wrote:
> i don't understand this part.
> 
> in TillNextFrame, it looks like preroll_timestamp will be in the past (from
the
> first preroll).  won't that end up rendering frames during the preroll?
> 
> i'm pretty sure that i've misunderstood something.

I understood your words as "in the case TillNextFrame is set, the preroll
timestamp will be in the past anyway". Please correct me if I'm wrong :-)

But if I understood you correctly, then no, there is no guarantee that it will
be in the past.

Consider the case with video reconfiguration while audio goes ahead.

--------+-------------+----------------------------> video
     drained      next video pts

                          last audio pts
---------------+-----------------+----------+------> audio
             stop request              preroll ts


(Not to scale!)

Last audio means before we resume, of course. In the absence of the second
preroll mode we would preroll to preroll ts, and the start.
 
The time it takes the request to propagate from video to audio thread depended
on the device and Android version. On one of my two devices (Nexus 5 with
Android 5) it was long enough to have preroll ts past the next video pts. During
the regular preroll we would skip all frames before preroll pts, thus skipping
this next video frame.

Please ask for more details if it does not make sense.

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
File media/base/android/media_codec_player_unittest.cc (right):

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
media/base/android/media_codec_player_unittest.cc:1759:
WaitForDelay(base::TimeDelta::FromMilliseconds(100));
On 2015/08/27 20:42:26, liberato wrote:
> can this be converted to a WaitForCondition or callback?  100msec is pretty
> short.

IsPlaybackStarted() comes when the first audio frame is rendered after preroll.
We wait for |start_timeout|, 2s, for this to happen. The first video frame might
come later, but the state should not be Prerolling. I will try to delete this
wait and see.

[Tima Vaisburd, 2015-08-27 22:13:11]

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
File media/base/android/media_codec_decoder.cc (right):

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
media/base/android/media_codec_decoder.cc:273: preroll_timestamp_ =
(preroll_mode_ == kPrerollTillPTS) ? preroll_timestamp
On 2015/08/27 22:04:18, Tima Vaisburd wrote:
> On 2015/08/27 20:42:26, liberato wrote:
> > won't that end up rendering frames during the preroll?

Actually, now I'm not sure I got your point. In the TillNextFrame mode the
"preroll" is supposed to report "I'm done" at the moment it gets the output
buffer. We never render frames during the preroll, strictly speaking (if you do
not count the intentional cheating in video with kRenderAfterPreroll).

[Tima Vaisburd, 2015-08-28 00:16:49]

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
File media/base/android/media_codec_player_unittest.cc (right):

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
media/base/android/media_codec_player_unittest.cc:1759:
WaitForDelay(base::TimeDelta::FromMilliseconds(100));
On 2015/08/27 22:04:19, Tima Vaisburd wrote:
> On 2015/08/27 20:42:26, liberato wrote:
> > can this be converted to a WaitForCondition or callback?  100msec is pretty
> > short.
> 
> IsPlaybackStarted() comes when the first audio frame is rendered after
preroll.
> We wait for |start_timeout|, 2s, for this to happen. The first video frame
might
> come later, but the state should not be Prerolling. I will try to delete this
> wait and see.

I removed the wait and the subsequent check for IsPrerollingForTests() in all
three tests altogether since the check do not add anything to the tests: we
check that decoder is recreated and that frames are not skipped.

[liberato (no reviews please), 2015-08-28 15:21:42]

thanks for clarifying all of that.  i'd like to take one more pass at it a
little later today, once i've had a chance to think about it some more.  the
"advance past config AU" logic is bothering me, but it's not quite clear why
yet.

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
File media/base/android/media_codec_decoder.cc (right):

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
media/base/android/media_codec_decoder.cc:273: preroll_timestamp_ =
(preroll_mode_ == kPrerollTillPTS) ? preroll_timestamp
On 2015/08/27 22:13:11, Tima Vaisburd wrote:
> On 2015/08/27 22:04:18, Tima Vaisburd wrote:internal_preroll
> > On 2015/08/27 20:42:26, liberato wrote:
> > > won't that end up rendering frames during the preroll?
> 
> Actually, now I'm not sure I got your point. In the TillNextFrame mode the
> "preroll" is supposed to report "I'm done" at the moment it gets the output
> buffer. We never render frames during the preroll, strictly speaking (if you
do
> not count the intentional cheating in video with kRenderAfterPreroll).

thanks for the explanation.  the root cause of my comment was that i misread
DepleteOutputBuffers().  in the TilNextFrame case in Preroll(), preroll_pts is
TimeDelta() (time 0, "in the past"). this will cause the next call to
DepleteOuputBuffers() to choose render_mode==kRenderAfterPreroll.  i mis-read
that last part as choosing kRender, which made no sense.

that diagram was also quite helpful, thanks for providing it.

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
media/base/android/media_codec_decoder.cc:630: AccessUnitQueue::Info au_info;
this block can probably be split out into a separate function, since this one's
getting somewhat big.

if (AdvanceUntilNonConfigAccessUnit())
  return true;  // starvation
AccessUnitQueue::Info au_info = au_queue_.GetInfo();
// We are ready to enqueue the front unit.

https://codereview.chromium.org/1287423004/diff/180001/media/base/android/acc...
File media/base/android/access_unit_queue.cc (right):

https://codereview.chromium.org/1287423004/diff/180001/media/base/android/acc...
media/base/android/access_unit_queue.cc:190: void
AccessUnitQueue::GetUnconsumedAccessUnitLength(int* total_length,
it looks like one could do this accounting in push_back and advance and flush,
rather than iterating here, for a factor of chunks_.size() improvement.  how
many items are in an AccessQueue in the worst case?

i suspect that it would have to be a fairly large number before the added
complexity is worth it.

[Tima Vaisburd, 2015-08-28 18:31:09]

> the "advance past config AU" logic is bothering me, but 
> it's not quite clear why yet.

Maybe another diagram would help? Again, I'm not quite sure
what you refer to, but the mental picture I had in mind is this:

 ---------------------------------------------------------
 | data | data | configs | data (key frame) | data | data
 ---------------------------------------------------------
                            ^
                            | current AU (past configs)

Why does it bother you?

https://codereview.chromium.org/1287423004/diff/180001/media/base/android/acc...
File media/base/android/access_unit_queue.cc (right):

https://codereview.chromium.org/1287423004/diff/180001/media/base/android/acc...
media/base/android/access_unit_queue.cc:190: void
AccessUnitQueue::GetUnconsumedAccessUnitLength(int* total_length,
On 2015/08/28 15:21:42, liberato wrote:
> it looks like one could do this accounting in push_back and advance and flush,
> rather than iterating here, for a factor of chunks_.size() improvement.  how
> many items are in an AccessQueue in the worst case?
> 
> i suspect that it would have to be a fairly large number before the added
> complexity is worth it.

Currently the number of chunks in the normal run is 2, it matches the two-chunk
situation we have in the MediaSourcePlayer. Maybe we can have 3 sometimes.

[Tima Vaisburd, 2015-08-28 18:33:31]

>  ---------------------------------------------------------
>  | data | data | configs | data (key frame) | data | data
>  ---------------------------------------------------------
>                             ^
>                             | current AU (past configs)
> 
> Why does it bother you?

M-mm, the diagram is surely skewed with the proportional font!
I will put it in the code. The arrow should point to the key frame!

[liberato (no reviews please), 2015-08-28 18:55:55]

On 2015/08/28 18:33:31, Tima Vaisburd wrote:
> >  ---------------------------------------------------------
> >  | data | data | configs | data (key frame) | data | data
> >  ---------------------------------------------------------
> >                             ^
> >                             | current AU (past configs)
> > 
> > Why does it bother you?
> 
> M-mm, the diagram is surely skewed with the proportional font!
> I will put it in the code. The arrow should point to the key frame!

diagrams are awesome.

in this case, though, it's not a diagram thing.  it's the early out for
starvation that worries me.  in particular, i've been trying to convince myself
that setting drain_decoder_ then starving is going to do the right thing.  i
think it does.

[Tima Vaisburd, 2015-08-28 19:04:20]

On 2015/08/28 18:55:55, liberato wrote:
> On 2015/08/28 18:33:31, Tima Vaisburd wrote:
> > >  ---------------------------------------------------------
> > >  | data | data | configs | data (key frame) | data | data
> > >  ---------------------------------------------------------
> > >                             ^
> > >                             | current AU (past configs)
> > > 
> > > Why does it bother you?
> > 
> > M-mm, the diagram is surely skewed with the proportional font!
> > I will put it in the code. The arrow should point to the key frame!
> 
> diagrams are awesome.
> 
> in this case, though, it's not a diagram thing.  it's the early out for
> starvation that worries me.  in particular, i've been trying to convince
myself
> that setting drain_decoder_ then starving is going to do the right thing.  i
> think it does.

In case we set drain_decoder_ the code should bypass starvation. Or do you mean
that
starvation might happen later?

[liberato (no reviews please), 2015-08-28 20:07:53]

On 2015/08/28 19:04:20, Tima Vaisburd wrote:
> On 2015/08/28 18:55:55, liberato wrote:
> > On 2015/08/28 18:33:31, Tima Vaisburd wrote:
> > > >  ---------------------------------------------------------
> > > >  | data | data | configs | data (key frame) | data | data
> > > >  ---------------------------------------------------------
> > > >                             ^
> > > >                             | current AU (past configs)
> > > > 
> > > > Why does it bother you?
> > > 
> > > M-mm, the diagram is surely skewed with the proportional font!
> > > I will put it in the code. The arrow should point to the key frame!
> > 
> > diagrams are awesome.
> > 
> > in this case, though, it's not a diagram thing.  it's the early out for
> > starvation that worries me.  in particular, i've been trying to convince
> myself
> > that setting drain_decoder_ then starving is going to do the right thing.  i
> > think it does.
> 
> In case we set drain_decoder_ the code should bypass starvation. Or do you
mean
> that
> starvation might happen later?

i'm fairly sure that it works as written, after going over it again.  there
really are fewer cases than it seemed like -- once it sets drain_decoder_, the
au queue is ignored.

lgtm

-fl

[Tima Vaisburd, 2015-08-28 21:26:23]

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
File media/base/android/media_codec_decoder.cc (right):

https://codereview.chromium.org/1287423004/diff/140001/media/base/android/med...
media/base/android/media_codec_decoder.cc:630: AccessUnitQueue::Info au_info;
On 2015/08/28 15:21:42, liberato wrote:
> this block can probably be split out into a separate function, since this
one's
> getting somewhat big.
> 
> if (AdvanceUntilNonConfigAccessUnit())
>   return true;  // starvation
> AccessUnitQueue::Info au_info = au_queue_.GetInfo();
> // We are ready to enqueue the front unit.

Made a method AdvanceAccessUnitQueue().

After thinking on your words about stravation I though it would be better to
change the logic and report starvation if we cannot advance to the data unit
event if we need to drain decoder. Although for the drain case we could have
waited I thought that it's better to make the logic uniform.

You might want to take another look.

[liberato (no reviews please), 2015-08-28 21:42:47]

still looks good % nits.

https://codereview.chromium.org/1287423004/diff/200001/media/base/android/med...
File media/base/android/media_codec_decoder.cc (right):

https://codereview.chromium.org/1287423004/diff/200001/media/base/android/med...
media/base/android/media_codec_decoder.cc:636: << ": starvation detected";
might want to mention |drain_decoder_| in the log.

https://codereview.chromium.org/1287423004/diff/200001/media/base/android/med...
media/base/android/media_codec_decoder.cc:724: // Get current frame
without the drain_decoder check here, the behavior changes if we have two config
change blocks in a row.  i don't think this matters, but i point it out anyway. 
before, we would break on the first and queue eos, now we'll consume both.

https://codereview.chromium.org/1287423004/diff/200001/media/base/android/med...
media/base/android/media_codec_decoder.cc:742: drain_decoder_ = true;
(*drain_decoder)?

[Tima Vaisburd, 2015-08-28 22:28:55]

https://codereview.chromium.org/1287423004/diff/200001/media/base/android/med...
File media/base/android/media_codec_decoder.cc (right):

https://codereview.chromium.org/1287423004/diff/200001/media/base/android/med...
media/base/android/media_codec_decoder.cc:636: << ": starvation detected";
On 2015/08/28 21:42:47, liberato wrote:
> might want to mention |drain_decoder_| in the log.

Added the words about the drain inside AdvanceAccessUnitQueue() where I assign
|drain_decoder_|.

https://codereview.chromium.org/1287423004/diff/200001/media/base/android/med...
media/base/android/media_codec_decoder.cc:724: // Get current frame
On 2015/08/28 21:42:47, liberato wrote:
> without the drain_decoder check here, the behavior changes if we have two
config
> change blocks in a row.  i don't think this matters, but i point it out
anyway. 
> before, we would break on the first and queue eos, now we'll consume both.

Yes, before we would break on first, and consume the other before
ConfiguerInternal(), there is another advancement there. I think both variants
are ok.

https://codereview.chromium.org/1287423004/diff/200001/media/base/android/med...
media/base/android/media_codec_decoder.cc:742: drain_decoder_ = true;
On 2015/08/28 21:42:47, liberato wrote:
> (*drain_decoder)?

Yes, indeed. Thank you.

[Tima Vaisburd, 2015-08-28 22:33:27]

The CQ bit was checked by timav@chromium.org

[Tima Vaisburd, 2015-08-28 22:33:28]

The patchset sent to the CQ was uploaded after l-g-t-m from qinmin@chromium.org,
liberato@chromium.org
Link to the patchset: https://codereview.chromium.org/1287423004/#ps220001
(title: "Fixed AdvanceAccessUnitQueue()")

[commit-bot: I haz the power, 2015-08-28 22:34:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1287423004/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1287423004/220001

[commit-bot: I haz the power, 2015-08-28 23:51:12]

Committed patchset #12 (id:220001)

[commit-bot: I haz the power, 2015-08-28 23:51:54]

Patchset 12 (id:??) landed as
https://crrev.com/39392412c833b080409464a2d875ccfcfeb23b5c
Cr-Commit-Position: refs/heads/master@{#346276}