MSE: Warn when keyframe after track_buffer is significantly in future

MSE: Warn when keyframe after track_buffer is significantly in future

Adds logging to chrome://media-internals when an overlapped append of
the currently playing GOP introduces significant delay until keyframe
following the end of the overlap.

Also adds a MockMediaLog and uses it in a StrictMock within
SourceBufferStreamTests to verify the new (and existing)
MediaLog events produced by SourceBufferStreamTests.

Visual example:
First append:
[K..t...........]
2nd append:
[K.......................................][*K....................]...

Since the buffer around 't' from first append is in the middle of being
decoded and rendered when the second append is done, the rest of the
first append's GOP is played and then the stream continues decode at the
next (*) keyframe in time in the 2nd append. The result is frozen video
frame (on the last PTS from the GOP containing t) until time of keyframe
at (*).

Note, once playback of the overlapped GOP containing t is completed, the
overlapped GOP is dropped, and only the buffered media from the second
append is available for replay upon seeking back.

BUG=518069
TEST=no regression. Internal b/23015270 repro demonstrates new log. Added
SourceBufferStreamTest.TrackBuffer_ExhaustionWithSkipForward and
SourceBufferStreamTest.TrackBuffer_ExhaustionAndImmediateNewTrackBuffer

Committed: https://crrev.com/ba8d79c02368809cab3f17844e93e6ef2cc6b639
Cr-Commit-Position: refs/heads/master@{#342861}

[wolenetz, 2015-08-08 00:51:35]

wolenetz@chromium.org changed reviewers:
+ chcunningham@chromium.org, xhwang@chromium.org

[wolenetz, 2015-08-08 00:51:35]

chcunningham@: everything
xhwang@: committer and from perspective of media internals spam prevention.

(See also the internal b/ for an example of the new log entry.)

Thanks!

https://codereview.chromium.org/1281113002/diff/1/media/filters/source_buffer...
File media/filters/source_buffer_stream.cc (right):

https://codereview.chromium.org/1281113002/diff/1/media/filters/source_buffer...
media/filters/source_buffer_stream.cc:1136:
DCHECK(!just_exhausted_track_buffer_);
I could think of no scenario where we exhaust track_buffer_, then emit the next
buffer somehow from another track_buffer_. This seems like a sane DCHECK to add
(somewhat drive-by, though).

[chcunningham, 2015-08-10 18:02:18]

Woot. LGTM

https://codereview.chromium.org/1281113002/diff/1/media/filters/source_buffer...
File media/filters/source_buffer_stream.cc (right):

https://codereview.chromium.org/1281113002/diff/1/media/filters/source_buffer...
media/filters/source_buffer_stream.cc:1136:
DCHECK(!just_exhausted_track_buffer_);
On 2015/08/08 00:51:35, wolenetz wrote:
> I could think of no scenario where we exhaust track_buffer_, then emit the
next
> buffer somehow from another track_buffer_. This seems like a sane DCHECK to
add
> (somewhat drive-by, though).

What if we encounter this sequence:

1. Overlapped append #1 fills TB
2. We read out all frames from TB, and execute lines 1154 - 1156
 -- setting just_exhausted = true 
 -- SetSelectedRangeIfNeede to somewhere in overlapped append #1
3. Overlapped append #2 causes us to push fresh stuff into TB
4. We GetNextBufferInternal ... DCHECK?

https://codereview.chromium.org/1281113002/diff/1/media/filters/source_buffer...
media/filters/source_buffer_stream.cc:1164: if (IsEndOfStreamReached()) {
Random out of scope question: I'm just reading the impl of IsEndOfStreamReached
for the first time. Most stuff made sense, except for the last line


return selected_range_ == ranges_.back();


I'm probably missing some detail, but doesn't it seem like that would hit pretty
often? e.g. you only have range, and you've got it selected as you feed buffers
out if it. I'm not seeing a guard that you've actually fed out all the buffers,
and even if there is a guard, how do we know EOS is the right thing to do
instead of kNeedBuffer? Again, I'm probably missing something...

[wolenetz, 2015-08-10 20:14:43]

I'll do some further investigation around the DCHECK. Thanks for review.

https://codereview.chromium.org/1281113002/diff/1/media/filters/source_buffer...
File media/filters/source_buffer_stream.cc (right):

https://codereview.chromium.org/1281113002/diff/1/media/filters/source_buffer...
media/filters/source_buffer_stream.cc:1136:
DCHECK(!just_exhausted_track_buffer_);
On 2015/08/10 18:02:18, chcunningham wrote:
> On 2015/08/08 00:51:35, wolenetz wrote:
> > I could think of no scenario where we exhaust track_buffer_, then emit the
> next
> > buffer somehow from another track_buffer_. This seems like a sane DCHECK to
> add
> > (somewhat drive-by, though).
> 
> What if we encounter this sequence:
> 
> 1. Overlapped append #1 fills TB
> 2. We read out all frames from TB, and execute lines 1154 - 1156
>  -- setting just_exhausted = true 
>  -- SetSelectedRangeIfNeede to somewhere in overlapped append #1
> 3. Overlapped append #2 causes us to push fresh stuff into TB
> 4. We GetNextBufferInternal ... DCHECK? 

While I had thought bullet #3 shouldn't put anything into TB if there has been
no GetNextBufferInternal() since previous track buffer exhaustion because a
precondition for putting anything into TB (and leaving it after pruning) is that
only sequences beginning with non-keyframes can begin track_buffers_. However, I
could be wrong (I'll read some code/write a test). I'm also unsure how much
value the DCHECK is really adding, but it could be exposing a scenario that
doesn't log the gap the way we think it should, so I'll investigate instead of
just removing the DCHECK.

https://codereview.chromium.org/1281113002/diff/1/media/filters/source_buffer...
media/filters/source_buffer_stream.cc:1164: if (IsEndOfStreamReached()) {
On 2015/08/10 18:02:18, chcunningham wrote:
> Random out of scope question: I'm just reading the impl of
IsEndOfStreamReached
> for the first time. Most stuff made sense, except for the last line
> 
> 
> return selected_range_ == ranges_.back();
> 
> 
> I'm probably missing some detail, but doesn't it seem like that would hit
pretty
> often? e.g. you only have range, and you've got it selected as you feed
buffers
> out if it. I'm not seeing a guard that you've actually fed out all the
buffers,
> and even if there is a guard, how do we know EOS is the right thing to do
> instead of kNeedBuffer? Again, I'm probably missing something...

I think IsEndOfStreamReached's name is perhaps confusing.
See the header comments. A true retval from it doesn't necessarily mean that
there is no more possible response to GetNextBuffer. It's more like
"IsEndOfStreamRangeReached", though there's also some confusing logic around
seek_pending, which might make its true name something like
"IsEndOfStreamRangeReachedOrIsSeekPendingBeyondEndOfStreamRange".

Patches welcome ;)

(Also, the guard that we've fed out all the buffers in currently selected range
(if any) is in l.1163 of this patch.)

[wolenetz, 2015-08-10 21:41:21]

On 2015/08/10 20:14:43, wolenetz wrote:
> I'll do some further investigation around the DCHECK. Thanks for review.
> 
>
https://codereview.chromium.org/1281113002/diff/1/media/filters/source_buffer...
> File media/filters/source_buffer_stream.cc (right):
> 
>
https://codereview.chromium.org/1281113002/diff/1/media/filters/source_buffer...
> media/filters/source_buffer_stream.cc:1136:
> DCHECK(!just_exhausted_track_buffer_);
> On 2015/08/10 18:02:18, chcunningham wrote:
> > On 2015/08/08 00:51:35, wolenetz wrote:
> > > I could think of no scenario where we exhaust track_buffer_, then emit the
> > next
> > > buffer somehow from another track_buffer_. This seems like a sane DCHECK
to
> > add
> > > (somewhat drive-by, though).
> > 
> > What if we encounter this sequence:
> > 
> > 1. Overlapped append #1 fills TB
> > 2. We read out all frames from TB, and execute lines 1154 - 1156
> >  -- setting just_exhausted = true 
> >  -- SetSelectedRangeIfNeede to somewhere in overlapped append #1
> > 3. Overlapped append #2 causes us to push fresh stuff into TB
> > 4. We GetNextBufferInternal ... DCHECK? 
> 
> While I had thought bullet #3 shouldn't put anything into TB if there has been
> no GetNextBufferInternal() since previous track buffer exhaustion because a
> precondition for putting anything into TB (and leaving it after pruning) is
that
> only sequences beginning with non-keyframes can begin track_buffers_. However,
I
> could be wrong (I'll read some code/write a test). I'm also unsure how much
> value the DCHECK is really adding, but it could be exposing a scenario that
> doesn't log the gap the way we think it should, so I'll investigate instead of
> just removing the DCHECK.
> 
>
https://codereview.chromium.org/1281113002/diff/1/media/filters/source_buffer...
> media/filters/source_buffer_stream.cc:1164: if (IsEndOfStreamReached()) {
> On 2015/08/10 18:02:18, chcunningham wrote:
> > Random out of scope question: I'm just reading the impl of
> IsEndOfStreamReached
> > for the first time. Most stuff made sense, except for the last line
> > 
> > 
> > return selected_range_ == ranges_.back();
> > 
> > 
> > I'm probably missing some detail, but doesn't it seem like that would hit
> pretty
> > often? e.g. you only have range, and you've got it selected as you feed
> buffers
> > out if it. I'm not seeing a guard that you've actually fed out all the
> buffers,
> > and even if there is a guard, how do we know EOS is the right thing to do
> > instead of kNeedBuffer? Again, I'm probably missing something...
> 
> I think IsEndOfStreamReached's name is perhaps confusing.
> See the header comments. A true retval from it doesn't necessarily mean that
> there is no more possible response to GetNextBuffer. It's more like
> "IsEndOfStreamRangeReached", though there's also some confusing logic around
> seek_pending, which might make its true name something like
> "IsEndOfStreamRangeReachedOrIsSeekPendingBeyondEndOfStreamRange".
> 
> Patches welcome ;)
> 
> (Also, the guard that we've fed out all the buffers in currently selected
range
> (if any) is in l.1163 of this patch.)

I made a unit test that exposed the truth: the DCHECK could indeed fire, and
when it's removed, the same scenario demonstrates the new log message could
understate the frozen gap. I'll work on fixing this for the next patch set.

[wolenetz, 2015-08-10 21:56:29]

Patch set 2 is just a checkpoint (not ready for review; don't land it)

https://codereview.chromium.org/1281113002/diff/1/media/filters/source_buffer...
File media/filters/source_buffer_stream.cc (right):

https://codereview.chromium.org/1281113002/diff/1/media/filters/source_buffer...
media/filters/source_buffer_stream.cc:1136:
DCHECK(!just_exhausted_track_buffer_);
On 2015/08/10 20:14:43, wolenetz wrote:
> On 2015/08/10 18:02:18, chcunningham wrote:
> > On 2015/08/08 00:51:35, wolenetz wrote:
> > > I could think of no scenario where we exhaust track_buffer_, then emit the
> > next
> > > buffer somehow from another track_buffer_. This seems like a sane DCHECK
to
> > add
> > > (somewhat drive-by, though).
> > 
> > What if we encounter this sequence:
> > 
> > 1. Overlapped append #1 fills TB
> > 2. We read out all frames from TB, and execute lines 1154 - 1156
> >  -- setting just_exhausted = true 
> >  -- SetSelectedRangeIfNeede to somewhere in overlapped append #1
> > 3. Overlapped append #2 causes us to push fresh stuff into TB
> > 4. We GetNextBufferInternal ... DCHECK? 
> 
> While I had thought bullet #3 shouldn't put anything into TB if there has been
> no GetNextBufferInternal() since previous track buffer exhaustion because a
> precondition for putting anything into TB (and leaving it after pruning) is
that
> only sequences beginning with non-keyframes can begin track_buffers_. However,
I
> could be wrong (I'll read some code/write a test). I'm also unsure how much
> value the DCHECK is really adding, but it could be exposing a scenario that
> doesn't log the gap the way we think it should, so I'll investigate instead of
> just removing the DCHECK.

DCHECK was indeed possible. Removed.

[xhwang, 2015-08-10 23:51:08]

I don't really understand this code, so defer to chrunningham to finish the
review. Added a nit though.

https://codereview.chromium.org/1281113002/diff/20001/media/filters/source_bu...
File media/filters/source_buffer_stream.cc (right):

https://codereview.chromium.org/1281113002/diff/20001/media/filters/source_bu...
media/filters/source_buffer_stream.cc:36: };
nit: As discussed before, these could just be "const int"s.

[wolenetz, 2015-08-11 00:32:13]

Thanks for reviews. I'm continuing to refactor this CL to add media log entry
verification for sourcebufferstream unittests (and some of this is likely to be
split off into a prerequisite CL). Patch set 3 is just another checkpoint, not
yet ready for review, and not yet fixing xhwang@'s nit.

[wolenetz, 2015-08-11 02:06:35]

The CQ bit was checked by wolenetz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-08-11 02:06:43]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1281113002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1281113002/60001

[commit-bot: I haz the power, 2015-08-11 02:18:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-08-11 02:18:34]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[wolenetz, 2015-08-11 02:46:53]

The CQ bit was checked by wolenetz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-08-11 02:47:08]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1281113002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1281113002/80001

[wolenetz, 2015-08-11 02:53:31]

I've reworked some things, especially some test support using a new MockMediaLog
in SourceBufferStreamTests.
Please take another look (patch set 5 this time):
chcunningham@: Everything
xhwang@: non-Author committer (or would you prefer Dale?)

Thanks!

https://codereview.chromium.org/1281113002/diff/20001/media/filters/source_bu...
File media/filters/source_buffer_stream.cc (right):

https://codereview.chromium.org/1281113002/diff/20001/media/filters/source_bu...
media/filters/source_buffer_stream.cc:36: };
On 2015/08/10 23:51:08, xhwang wrote:
> nit: As discussed before, these could just be "const int"s.

Oops! Done :)

https://codereview.chromium.org/1281113002/diff/60001/media/filters/source_bu...
File media/filters/source_buffer_stream_unittest.cc (right):

https://codereview.chromium.org/1281113002/diff/60001/media/filters/source_bu...
media/filters/source_buffer_stream_unittest.cc:79: SourceBufferStreamTest() :
media_log_(new StrictMock<MockMediaLog>()) {
Note that I chose strict media log mocking for these unit tests. If this becomes
too much maintenance burden, we can loosen this, but my hope is the helpers and
matchers, above, will lessen that burden while maintaining clarity of
expectations around sourcebufferstream media-internals logging scenarios.

https://codereview.chromium.org/1281113002/diff/60001/media/filters/source_bu...
media/filters/source_buffer_stream_unittest.cc:1464:
EXPECT_MEDIA_LOG_STRING(ContainsTrackBufferExhaustionSkipLog(133));
Note: this test is distinct from the two added below, and I think it is pretty
cool that we can see this log gets emitted here, too (correctly).

https://codereview.chromium.org/1281113002/diff/60001/media/filters/source_bu...
media/filters/source_buffer_stream_unittest.cc:1730:
EXPECT_MEDIA_LOG_STRING(ContainsTrackBufferExhaustionSkipLog(50));
Note ditto..

https://codereview.chromium.org/1281113002/diff/60001/media/filters/source_bu...
media/filters/source_buffer_stream_unittest.cc:1762:
EXPECT_MEDIA_LOG_STRING(ContainsTrackBufferExhaustionSkipLog(40));
Note ditto (all these are slightly differently focused..)

https://codereview.chromium.org/1281113002/diff/60001/media/filters/source_bu...
media/filters/source_buffer_stream_unittest.cc:4067: "Skipping splice frame
generation: not enough samples for splicing new "
Note: For this and the next test, the log message checking is almost better than
code comments! \o/

[commit-bot: I haz the power, 2015-08-11 03:52:48]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-08-11 03:52:49]

Dry run: This issue passed the CQ dry run.

[xhwang, 2015-08-11 07:04:37]

lgtm

https://codereview.chromium.org/1281113002/diff/80001/media/base/mock_media_l...
File media/base/mock_media_log.cc (right):

https://codereview.chromium.org/1281113002/diff/80001/media/base/mock_media_l...
media/base/mock_media_log.cc:1: // Copyright (c) 2015 The Chromium Authors. All
rights reserved.
ditto

https://codereview.chromium.org/1281113002/diff/80001/media/base/mock_media_l...
File media/base/mock_media_log.h (right):

https://codereview.chromium.org/1281113002/diff/80001/media/base/mock_media_l...
media/base/mock_media_log.h:1: // Copyright (c) 2015 The Chromium Authors. All
rights reserved.
nit: s/(c)// 

See
https://code.google.com/p/chromium/codesearch#search/&q=%22Copyright%202015%2...

https://codereview.chromium.org/1281113002/diff/80001/media/base/mock_media_l...
media/base/mock_media_log.h:17: MOCK_METHOD1(DoAddEventLogString,
void(std::string event));
nit: const std::string&

https://codereview.chromium.org/1281113002/diff/80001/media/filters/source_bu...
File media/filters/source_buffer_stream.cc (right):

https://codereview.chromium.org/1281113002/diff/80001/media/filters/source_bu...
media/filters/source_buffer_stream.cc:214: num_track_buffer_gap_warning_logs_(0)
{}
For future cleanup, consider using in-class member initialization to simplify
these constructors:

https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Initialization

[wolenetz, 2015-08-11 15:53:51]

The CQ bit was checked by wolenetz@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-08-11 15:54:08]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1281113002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1281113002/100001

[wolenetz, 2015-08-11 15:54:40]

Thanks for the review, Xiohan.
Chris, please take a look at patch 6, since there has been significant rework
since your previous l*tm.

https://codereview.chromium.org/1281113002/diff/80001/media/base/mock_media_l...
File media/base/mock_media_log.h (right):

https://codereview.chromium.org/1281113002/diff/80001/media/base/mock_media_l...
media/base/mock_media_log.h:1: // Copyright (c) 2015 The Chromium Authors. All
rights reserved.
On 2015/08/11 07:04:36, xhwang wrote:
> nit: s/(c)// 
> 
> See
>
https://code.google.com/p/chromium/codesearch#search/&q=%22Copyright%202015%2...

Done.

https://codereview.chromium.org/1281113002/diff/80001/media/base/mock_media_l...
media/base/mock_media_log.h:17: MOCK_METHOD1(DoAddEventLogString,
void(std::string event));
On 2015/08/11 07:04:36, xhwang wrote:
> nit: const std::string& 

Done.

https://codereview.chromium.org/1281113002/diff/80001/media/filters/source_bu...
File media/filters/source_buffer_stream.cc (right):

https://codereview.chromium.org/1281113002/diff/80001/media/filters/source_bu...
media/filters/source_buffer_stream.cc:214: num_track_buffer_gap_warning_logs_(0)
{}
On 2015/08/11 07:04:36, xhwang wrote:
> For future cleanup, consider using in-class member initialization to simplify
> these constructors:
> 
>
https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Initialization

Acknowledged.

[wolenetz, 2015-08-11 15:55:22]

On 2015/08/11 15:54:40, wolenetz wrote:
> Thanks for the review, Xiohan.
> Chris, please take a look at patch 6, since there has been significant rework
> since your previous l*tm.
> 
>
https://codereview.chromium.org/1281113002/diff/80001/media/base/mock_media_l...
> File media/base/mock_media_log.h (right):
> 
>
https://codereview.chromium.org/1281113002/diff/80001/media/base/mock_media_l...
> media/base/mock_media_log.h:1: // Copyright (c) 2015 The Chromium Authors. All
> rights reserved.
> On 2015/08/11 07:04:36, xhwang wrote:
> > nit: s/(c)// 
> > 
> > See
> >
>
https://code.google.com/p/chromium/codesearch#search/&q=%22Copyright%202015%2...
> 
> Done.
> 
>
https://codereview.chromium.org/1281113002/diff/80001/media/base/mock_media_l...
> media/base/mock_media_log.h:17: MOCK_METHOD1(DoAddEventLogString,
> void(std::string event));
> On 2015/08/11 07:04:36, xhwang wrote:
> > nit: const std::string& 
> 
> Done.
> 
>
https://codereview.chromium.org/1281113002/diff/80001/media/filters/source_bu...
> File media/filters/source_buffer_stream.cc (right):
> 
>
https://codereview.chromium.org/1281113002/diff/80001/media/filters/source_bu...
> media/filters/source_buffer_stream.cc:214:
num_track_buffer_gap_warning_logs_(0)
> {}
> On 2015/08/11 07:04:36, xhwang wrote:
> > For future cleanup, consider using in-class member initialization to
simplify
> > these constructors:
> > 
> >
>
https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Initialization
> 
> Acknowledged.

s/Xiohan/Xiaohan/. Sorry :)

[commit-bot: I haz the power, 2015-08-11 17:15:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-08-11 17:15:15]

Dry run: This issue passed the CQ dry run.

[wolenetz, 2015-08-11 17:52:16]

https://codereview.chromium.org/1281113002/diff/80001/media/filters/source_bu...
File media/filters/source_buffer_stream.cc (right):

https://codereview.chromium.org/1281113002/diff/80001/media/filters/source_bu...
media/filters/source_buffer_stream.cc:214: num_track_buffer_gap_warning_logs_(0)
{}
On 2015/08/11 15:54:40, wolenetz wrote:
> On 2015/08/11 07:04:36, xhwang wrote:
> > For future cleanup, consider using in-class member initialization to
simplify
> > these constructors:
> > 
> >
>
https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Initialization
> 
> Acknowledged.

Thanks for pointing out this cleanup opportunity! I've made a start at some of
this cleanup in https://codereview.chromium.org/1278193003/.

[chcunningham, 2015-08-11 19:01:18]

LGTM x2

https://codereview.chromium.org/1281113002/diff/100001/media/base/mock_media_...
File media/base/mock_media_log.cc (left):

https://codereview.chromium.org/1281113002/diff/100001/media/base/mock_media_...
media/base/mock_media_log.cc:9: JpegDecodeAccelerator::~JpegDecodeAccelerator()
{
did you git copy this?

[wolenetz, 2015-08-11 19:06:05]

Thanks again for the reviews.

https://codereview.chromium.org/1281113002/diff/100001/media/base/mock_media_...
File media/base/mock_media_log.cc (left):

https://codereview.chromium.org/1281113002/diff/100001/media/base/mock_media_...
media/base/mock_media_log.cc:9: JpegDecodeAccelerator::~JpegDecodeAccelerator()
{
On 2015/08/11 19:01:18, chcunningham wrote:
> did you git copy this? 

Nope. That's git just finding great commonality automagically in truly unrelated
files.

[wolenetz, 2015-08-11 19:06:10]

The CQ bit was checked by wolenetz@chromium.org

[wolenetz, 2015-08-11 19:06:10]

The patchset sent to the CQ was uploaded after l-g-t-m from xhwang@chromium.org
Link to the patchset: https://codereview.chromium.org/1281113002/#ps100001
(title: "Fixes xhwang@'s nits")

[commit-bot: I haz the power, 2015-08-11 19:06:39]

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

[commit-bot: I haz the power, 2015-08-11 19:17:53]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-08-11 19:18:55]

Patchset 6 (id:??) landed as
https://crrev.com/ba8d79c02368809cab3f17844e93e6ef2cc6b639
Cr-Commit-Position: refs/heads/master@{#342861}