MSE: Log a warning if muxed AV media segment has no A or has no V block

MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify debugging multiple discontinuity detection edge cases related
to the upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals
debug log messages when either the audio or video track has no coded
frames within a media segment (for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412, 542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests

Committed: https://crrev.com/8d425ee590b8902b18a095c865e23470d6a176d7
Cr-Commit-Position: refs/heads/master@{#370281}

[wolenetz, 2016-01-07 00:45:24]

chcunningham@: Please take a look. I still need to switch to
StrickMock<MockMediaLog> in ChunkDemuxerTests, clean up the
WebMIsParsingMediaSegment unit test's formatting (git cl format made it really
ugly), and possibly add more stream-parser-specific testing around segment
boundary detection (latter's inclusion in this CL is less likely).

[chcunningham, 2016-01-07 22:23:57]

Minor fb.

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer.cc
File media/filters/chunk_demuxer.cc (right):

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer.cc:368: void SourceState::ResetParserState(TimeDelta
append_window_start,
Should you set media_segment_contained_{video|audio}_frame_ = false here?

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
File media/filters/chunk_demuxer_unittest.cc (right):

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:481: CHECK((!explicit_duration &&
!is_last_block) || is_last_block);
I *think* you're trying to assert that

 (explicit_duration -> is_last_block)

If I have this right, its more readable to do 

  CHECK(!explicit_duration || is_last_block);

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:2555: // Video: 320 -> 420
This is Video: 300 -> 420 now.

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:2570: // 500, so the added buffered
range is 500 -> 570
Is this due to the fudgy start stuff?

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:2582: // 700, so the added buffered
range is 700 -> 750
Do we now need to add a test where we have 2 SourceBuffers with jagged start so
we can see the naive buffered range actually come to be the reported buffered
range?

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:3194: 
This space seems kinda random?

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:3211: 
ditto

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:3219: 
ditto

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:4067: TEST_F(ChunkDemuxerTest,
SegmentMissingAudioFrame_AudioOnly) {
These are work-in-progress I think?

https://codereview.chromium.org/1564983003/diff/1/media/formats/common/stream...
File media/formats/common/stream_parser_test_base.cc (right):

https://codereview.chromium.org/1564983003/diff/1/media/formats/common/stream...
media/formats/common/stream_parser_test_base.cc:128: return true;  // BIG TODO :
test
:)

https://codereview.chromium.org/1564983003/diff/1/media/formats/mp4/mp4_strea...
File media/formats/mp4/mp4_stream_parser_unittest.cc (right):

https://codereview.chromium.org/1564983003/diff/1/media/formats/mp4/mp4_strea...
media/formats/mp4/mp4_stream_parser_unittest.cc:163: return true;  // BIG TODO
test !
:)

[wolenetz, 2016-01-07 22:37:09]

Nothing new to review yet. Just quick replies as I work on a further prereq for
this CL that does much more strict medialog expectation checking for those
pre-existing ChunkDemuxerTests. Otherwise, this CL would be really bloated.

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
File media/filters/chunk_demuxer_unittest.cc (right):

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:481: CHECK((!explicit_duration &&
!is_last_block) || is_last_block);
On 2016/01/07 22:23:56, chcunningham wrote:
> I *think* you're trying to assert that
> 
>  (explicit_duration -> is_last_block)
> 
> If I have this right, its more readable to do 
> 
>   CHECK(!explicit_duration || is_last_block);

Correct.

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:2555: // Video: 320 -> 420
On 2016/01/07 22:23:57, chcunningham wrote:
> This is Video: 300 -> 420 now.

I suppose the comment format isn't clear. The A/V lines in these comments
describe the actual block timecodes+block durations. The Buffered Range line
describes the SourceBuffer.buffered expected retval. I've included new internal
track buffered range expectations, though these are not exposed directly to web
apps for multiple tracks within the same muxed SourceBuffer. I'll see if I can
make the comments clearer regarding this.

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:2570: // 500, so the added buffered
range is 500 -> 570
On 2016/01/07 22:23:57, chcunningham wrote:
> Is this due to the fudgy start stuff? 

While it seems similar, the fudgy start stuff is meant to equate a slightly
non-zero first-range-start time in [0,1s) to not cause stalls on playback.

These "naive" buffered ranges do not consider that the source of the buffers was
in a muxed media segment, for which the content creator expected playback for
all tracks to be able to begin on the first coded frame group for each track
encountered within that segment, regardless of if it starts precisely at the
segment start time. There's a bit of legacy cruft in here, but this at least
doesn't change the current behavior of SourceBufferStreams in a muxed
SourceBuffer relative to the muxed clusters' cluster timecode (or media segment
start time).

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:2582: // 700, so the added buffered
range is 700 -> 750
On 2016/01/07 22:23:57, chcunningham wrote:
> Do we now need to add a test where we have 2 SourceBuffers with jagged start
so
> we can see the naive buffered range actually come to be the reported buffered
> range?

SGTM.

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:3194: 
On 2016/01/07 22:23:56, chcunningham wrote:
> This space seems kinda random?

Yep. Per my PTAL PS1 comment, git cl format did bad things. I'll fix this.

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:3211: 
On 2016/01/07 22:23:56, chcunningham wrote:
> ditto

ditto

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:3219: 
On 2016/01/07 22:23:57, chcunningham wrote:
> ditto

ditto

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:4067: TEST_F(ChunkDemuxerTest,
SegmentMissingAudioFrame_AudioOnly) {
On 2016/01/07 22:23:57, chcunningham wrote:
> These are work-in-progress I think?

Correct. I need to add strict medialog expectations, at minimum.

[wolenetz, 2016-01-13 02:49:01]

Description was changed from

==========
WIP- MSE: Enforce muxed SourceBuffers' segments have A and V in each segment

To simplify multiple discontinuity detection edge cases related to the
upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change aligns Chrome with currently pending
MSE spec change that requires at least one coded frame for each audio
and video track be contained within each media segment.

The logic is enforced in SourceState::OnEndOfMediaSegment() and failure
is reported in its new return value.

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

Previously, many of the unit tests relied on a relaxed enforcement in
Chrome of a similar webm-bytestream-specific requirement. These tests
including single-stream appends to a muxed SourceState are updated.

BUG=229412,542375
R=chcunningham@chromium.org
TEST=
Work on this CL is still in progress to
1) add strick mock medialog expectations for old and new ChunkDemuxerTests
2) potentially test parser-specific segment detection/enforcement in the
   various stream parser tests' EndMediaSegmentCB
==========

to

==========
MSE: Enforce muxed SourceBuffers' segments have A and V in each segment

To simplify multiple discontinuity detection edge cases related to the
upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change aligns Chrome with currently pending
MSE spec change that requires at least one coded frame for each audio
and video track be contained within each media segment.

The logic is enforced in SourceState::OnEndOfMediaSegment() and failure
is reported in its new return value.

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

Previously, many of the unit tests relied on a relaxed enforcement in
Chrome of a similar webm-bytestream-specific requirement. 

BUG=229412,542375
R=chcunningham@chromium.org
TEST=
Work on this CL is still in progress to
0) rebase upon the final version of the strict chunkdemuxertest medialog CL
(https://codereview.chromium.org/1581003002/)
1) potentially test parser-specific segment detection/enforcement in the
   various stream parser tests' EndMediaSegmentCB
2) due to MSE spec PR push-back, relax back to just warning if expected A or V
block is missing from segment
3) address CR comments
==========

[wolenetz, 2016-01-16 01:19:16]

Description was changed from

==========
MSE: Enforce muxed SourceBuffers' segments have A and V in each segment

To simplify multiple discontinuity detection edge cases related to the
upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change aligns Chrome with currently pending
MSE spec change that requires at least one coded frame for each audio
and video track be contained within each media segment.

The logic is enforced in SourceState::OnEndOfMediaSegment() and failure
is reported in its new return value.

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

Previously, many of the unit tests relied on a relaxed enforcement in
Chrome of a similar webm-bytestream-specific requirement. 

BUG=229412,542375
R=chcunningham@chromium.org
TEST=
Work on this CL is still in progress to
0) rebase upon the final version of the strict chunkdemuxertest medialog CL
(https://codereview.chromium.org/1581003002/)
1) potentially test parser-specific segment detection/enforcement in the
   various stream parser tests' EndMediaSegmentCB
2) due to MSE spec PR push-back, relax back to just warning if expected A or V
block is missing from segment
3) address CR comments
==========

to

==========
MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify multiple discontinuity detection edge cases related to the
upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals debug log
messages
when at least one coded frame for each audio
and video track be contained within each media segment
(for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412,542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests
==========

[wolenetz, 2016-01-16 01:19:39]

Description was changed from

==========
MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify multiple discontinuity detection edge cases related to the
upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals debug log
messages
when at least one coded frame for each audio
and video track be contained within each media segment
(for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412,542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests
==========

to

==========
MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify multiple discontinuity detection edge cases related to the
upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals
debug log messages when at least one coded frame for each audio
and video track be contained within each media segment
(for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412,542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests
==========

[wolenetz, 2016-01-16 01:19:59]

Description was changed from

==========
MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify multiple discontinuity detection edge cases related to the
upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals
debug log messages when at least one coded frame for each audio
and video track be contained within each media segment
(for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412,542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests
==========

to

==========
MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify debugging multiple discontinuity detection edge cases related
to the upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals
debug log messages when at least one coded frame for each audio
and video track be contained within each media segment
(for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412,542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests
==========

[wolenetz, 2016-01-16 01:21:33]

Description was changed from

==========
MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify debugging multiple discontinuity detection edge cases related
to the upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals
debug log messages when at least one coded frame for each audio
and video track be contained within each media segment
(for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412,542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests
==========

to

==========
MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify debugging multiple discontinuity detection edge cases related
to the upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals
debug log messages when either the audio or video track
has no coded frames within a media segment
(for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412,542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests
==========

[wolenetz, 2016-01-16 01:22:14]

Description was changed from

==========
MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify debugging multiple discontinuity detection edge cases related
to the upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals
debug log messages when either the audio or video track
has no coded frames within a media segment
(for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412,542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests
==========

to

==========
MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify debugging multiple discontinuity detection edge cases related
to the upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals
debug log messages when either the audio or video track has no coded
frames within a media segment (for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412,542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests
==========

[wolenetz, 2016-01-16 01:22:28]

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

[commit-bot: I haz the power, 2016-01-16 01:23:28]

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

[wolenetz, 2016-01-16 01:23:36]

Please take a look at patch set 6.
Notably, I've reverted back from emitting decode error, but retained inclusion
of a DEBUG LIMITED_MEDIA_LOG when this condition occurs.

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer.cc
File media/filters/chunk_demuxer.cc (right):

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer.cc:368: void SourceState::ResetParserState(TimeDelta
append_window_start,
On 2016/01/07 22:23:56, chcunningham wrote:
> Should you set media_segment_contained_{video|audio}_frame_ = false here?

Good idea for at least maintainability. Done (in MediaSourceState now).

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
File media/filters/chunk_demuxer_unittest.cc (right):

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:481: CHECK((!explicit_duration &&
!is_last_block) || is_last_block);
On 2016/01/07 22:37:09, wolenetz wrote:
> On 2016/01/07 22:23:56, chcunningham wrote:
> > I *think* you're trying to assert that
> > 
> >  (explicit_duration -> is_last_block)
> > 
> > If I have this right, its more readable to do 
> > 
> >   CHECK(!explicit_duration || is_last_block);
> 
> Correct.

Fixed already in landed prereq CL https://codereview.chromium.org/1581003002/

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:2555: // Video: 320 -> 420
On 2016/01/07 22:37:09, wolenetz wrote:
> On 2016/01/07 22:23:57, chcunningham wrote:
> > This is Video: 300 -> 420 now.
> 
> I suppose the comment format isn't clear. The A/V lines in these comments
> describe the actual block timecodes+block durations. The Buffered Range line
> describes the SourceBuffer.buffered expected retval. I've included new
internal
> track buffered range expectations, though these are not exposed directly to
web
> apps for multiple tracks within the same muxed SourceBuffer. I'll see if I can
> make the comments clearer regarding this.

Done.

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:2582: // 700, so the added buffered
range is 700 -> 750
On 2016/01/07 22:37:09, wolenetz wrote:
> On 2016/01/07 22:23:57, chcunningham wrote:
> > Do we now need to add a test where we have 2 SourceBuffers with jagged start
> so
> > we can see the naive buffered range actually come to be the reported
buffered
> > range?
> 
> SGTM.

Done.

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:3194: 
On 2016/01/07 22:37:09, wolenetz wrote:
> On 2016/01/07 22:23:56, chcunningham wrote:
> > This space seems kinda random?
> 
> Yep. Per my PTAL PS1 comment, git cl format did bad things. I'll fix this.

Done.

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:3211: 
On 2016/01/07 22:37:09, wolenetz wrote:
> On 2016/01/07 22:23:56, chcunningham wrote:
> > ditto
> 
> ditto

Done.

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:3219: 
On 2016/01/07 22:37:09, wolenetz wrote:
> On 2016/01/07 22:23:57, chcunningham wrote:
> > ditto
> 
> ditto

Done.

https://codereview.chromium.org/1564983003/diff/1/media/filters/chunk_demuxer...
media/filters/chunk_demuxer_unittest.cc:4067: TEST_F(ChunkDemuxerTest,
SegmentMissingAudioFrame_AudioOnly) {
On 2016/01/07 22:37:09, wolenetz wrote:
> On 2016/01/07 22:23:57, chcunningham wrote:
> > These are work-in-progress I think?
> 
> Correct. I need to add strict medialog expectations, at minimum.

Done.

https://codereview.chromium.org/1564983003/diff/1/media/formats/common/stream...
File media/formats/common/stream_parser_test_base.cc (right):

https://codereview.chromium.org/1564983003/diff/1/media/formats/common/stream...
media/formats/common/stream_parser_test_base.cc:128: return true;  // BIG TODO :
test
On 2016/01/07 22:23:57, chcunningham wrote:
> :)

No longer changed (PS5, at least).

https://codereview.chromium.org/1564983003/diff/1/media/formats/mp4/mp4_strea...
File media/formats/mp4/mp4_stream_parser_unittest.cc (right):

https://codereview.chromium.org/1564983003/diff/1/media/formats/mp4/mp4_strea...
media/formats/mp4/mp4_stream_parser_unittest.cc:163: return true;  // BIG TODO
test !
On 2016/01/07 22:23:57, chcunningham wrote:
> :)

No longer changed (PS5, at least).

[commit-bot: I haz the power, 2016-01-16 02:31:43]

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

[commit-bot: I haz the power, 2016-01-16 02:31:44]

Dry run: This issue passed the CQ dry run.

[chcunningham, 2016-01-20 00:40:59]

lgtm

https://codereview.chromium.org/1564983003/diff/100001/media/filters/chunk_de...
File media/filters/chunk_demuxer_unittest.cc (right):

https://codereview.chromium.org/1564983003/diff/100001/media/filters/chunk_de...
media/filters/chunk_demuxer_unittest.cc:3519: 0x1A, 0x45, 0xDF, 0xA3, 0x8A,
Is this part needed?

[wolenetz, 2016-01-20 00:45:48]

Thanks for review. I'll send to CQ shortly.

https://codereview.chromium.org/1564983003/diff/100001/media/filters/chunk_de...
File media/filters/chunk_demuxer_unittest.cc (right):

https://codereview.chromium.org/1564983003/diff/100001/media/filters/chunk_de...
media/filters/chunk_demuxer_unittest.cc:3519: 0x1A, 0x45, 0xDF, 0xA3, 0x8A,
On 2016/01/20 00:40:59, chcunningham wrote:
> Is this part needed?

Indeed it is. The termination of an "unknown"-sized WebM cluster is determined
by the presence of something like an EBMLHEADER (or another top-level tag). We
don't know a full EBMLHEADER is complete until we get the full header. Note the
transition in kExpectedReturnValues[], below, from true to false on the very
last byte.

[wolenetz, 2016-01-20 00:45:53]

The CQ bit was checked by wolenetz@chromium.org

[commit-bot: I haz the power, 2016-01-20 00:49:03]

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

[commit-bot: I haz the power, 2016-01-20 02:20:33]

Description was changed from

==========
MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify debugging multiple discontinuity detection edge cases related
to the upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals
debug log messages when either the audio or video track has no coded
frames within a media segment (for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412,542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests
==========

to

==========
MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify debugging multiple discontinuity detection edge cases related
to the upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals
debug log messages when either the audio or video track has no coded
frames within a media segment (for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412,542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests
==========

[commit-bot: I haz the power, 2016-01-20 02:20:33]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-01-20 02:21:20]

Description was changed from

==========
MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify debugging multiple discontinuity detection edge cases related
to the upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals
debug log messages when either the audio or video track has no coded
frames within a media segment (for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412,542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests
==========

to

==========
MSE: Log a warning if muxed AV media segment has no A or has no V block

To simplify debugging multiple discontinuity detection edge cases related
to the upcoming relaxation of the "media segments must begin with keyframe"
requirement in Chrome, this change introduces chrome://media-internals
debug log messages when either the audio or video track has no coded
frames within a media segment (for a muxed A/V SourceBuffer).

A previously redundant and now complicating call to the end of segment
callback in the WebM stream parser's Flush() is removed, and the comment
for interface StreamParser::Flush() is corrected to not refer to "Seek".

BUG=229412,542375
R=chcunningham@chromium.org
TEST=ChunkDemuxerTests

Committed: https://crrev.com/8d425ee590b8902b18a095c865e23470d6a176d7
Cr-Commit-Position: refs/heads/master@{#370281}
==========

[commit-bot: I haz the power, 2016-01-20 02:21:21]

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