Revert of MSE: Relax the 'media segment must begin with keyframe' requirement

Revert of MSE: Relax the 'media segment must begin with keyframe' requirement (patchset #13 id:240001 of https://codereview.chromium.org/1091293005/ )

Reason for revert:
Two regressions:
BUG=581125, 581458
The latter causes NFLX playback stall. Reverting to fix canary, even if the latter's eventual fix might be external (e.g. NFLX web app).

To allow revert to currently failing code format rules:
NOPRESUBMIT=true

Original issue's description:
> MSE: Relax the 'media segment must begin with keyframe' requirement
>
> The current version of the MSE spec no longer requires that media segments
> start with a keyframe. This change reworks the MSE implementation
> so that it now allows tracks within media segments to not begin
> with a keyframe.
>
> To accomplish this requirement's relaxation, this CL:
> 1) Separates media segment signaling from coded frame group signaling:
>    MSE stream parsers need to report whether or not they are currently
>    in the middle of parsing a media segment, such as a WebM cluster, to
>    comply with spec disallowance of certain operations like changing
>    SourceBuffer appendMode when appendState is PARSING_MEDIA_SEGMENT.
>    However, SourceBufferStream only needs to be signaled when a new coded
>    frame group is beginning, for example when buffers are appended
>    following a discontinuity.
> 2) Since the FrameProcessor now can transitively signal SourceBufferStreams
>    when a new coded frame group is beginning (which might span multiple
>    media segments), the SourceBufferStream can rely upon the fact
>    that the next buffer appended must be a keyframe if it's been told
>    that a new coded frame group is starting. A CHECK() is included.
> 3) New ChunkDemuxerTests.
> 4) Various test cleanup to conform to the distinct "new coded frame group"
>    and "new media segment" signaling separation, as well as removal
>    of decode error verification when a media segment doesn't begin
>    with a keyframe.
>
> Note that the FrameProcessor already drops non-keyframes prior to the
> first keyframe processed for a track following a discontinuity,
> and the SourceBufferStream already drops non-keyframes prior to the
> first keyframe processed for a track following a range removal that
> removed the last appended position in the current coded frame group.
>
> BUG=229412, 459546
> R=chcunningham@chromium.org
> TEST=Updated ChunkDemuxerTests, SourceBufferStreamTests,
> FrameProcessorTests. Also locally tested: bug 459546's
> original report no longer fails. A sample webm VP9 file
> from b/26524063 no longer fails. GPM webm vp9/opus test no
> longer fails. Bug 518854's original report's "flags_all.mp4"
> no longer fails.
>
> Committed: https://crrev.com/3d152e528e97024860822d3e75109c0c597bf4de
> Cr-Commit-Position: refs/heads/master@{#371018}

TBR=chcunningham@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=229412, 459546
Committed: https://crrev.com/4d3c457f2301754ca4321c77c8ff13e69dec8acc
Cr-Commit-Position: refs/heads/master@{#371686}

[wolenetz, 2016-01-27 00:39:46]

Created Revert of MSE: Relax the 'media segment must begin with keyframe'
requirement

[wolenetz, 2016-01-27 00:40:02]

Description was changed from

==========
Revert of MSE: Relax the 'media segment must begin with keyframe' requirement
(patchset #13 id:240001 of https://codereview.chromium.org/1091293005/ )

Reason for revert:
Two regressions:
B=581125,581458

The latter causes NFLX playback stall. Reverting to fix canary, even if the
latter's eventual fix might be external (e.g. NFLX web app).

Original issue's description:
> MSE: Relax the 'media segment must begin with keyframe' requirement
> 
> The current version of the MSE spec no longer requires that media segments
> start with a keyframe. This change reworks the MSE implementation
> so that it now allows tracks within media segments to not begin
> with a keyframe.
> 
> To accomplish this requirement's relaxation, this CL:
> 1) Separates media segment signaling from coded frame group signaling:
>    MSE stream parsers need to report whether or not they are currently
>    in the middle of parsing a media segment, such as a WebM cluster, to
>    comply with spec disallowance of certain operations like changing
>    SourceBuffer appendMode when appendState is PARSING_MEDIA_SEGMENT.
>    However, SourceBufferStream only needs to be signaled when a new coded
>    frame group is beginning, for example when buffers are appended
>    following a discontinuity.
> 2) Since the FrameProcessor now can transitively signal SourceBufferStreams
>    when a new coded frame group is beginning (which might span multiple
>    media segments), the SourceBufferStream can rely upon the fact
>    that the next buffer appended must be a keyframe if it's been told
>    that a new coded frame group is starting. A CHECK() is included.
> 3) New ChunkDemuxerTests.
> 4) Various test cleanup to conform to the distinct "new coded frame group"
>    and "new media segment" signaling separation, as well as removal
>    of decode error verification when a media segment doesn't begin
>    with a keyframe.
> 
> Note that the FrameProcessor already drops non-keyframes prior to the
> first keyframe processed for a track following a discontinuity,
> and the SourceBufferStream already drops non-keyframes prior to the
> first keyframe processed for a track following a range removal that
> removed the last appended position in the current coded frame group.
> 
> BUG=229412,459546
> R=chcunningham@chromium.org
> TEST=Updated ChunkDemuxerTests, SourceBufferStreamTests,
> FrameProcessorTests. Also locally tested: bug 459546's
> original report no longer fails. A sample webm VP9 file
> from b/26524063 no longer fails. GPM webm vp9/opus test no
> longer fails. Bug 518854's original report's "flags_all.mp4"
> no longer fails.
> 
> Committed: https://crrev.com/3d152e528e97024860822d3e75109c0c597bf4de
> Cr-Commit-Position: refs/heads/master@{#371018}

TBR=chcunningham@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=229412,459546
==========

to

==========
Revert of MSE: Relax the 'media segment must begin with keyframe' requirement
(patchset #13 id:240001 of https://codereview.chromium.org/1091293005/ )

Reason for revert:
Two regressions:
BUG=581125,581458

The latter causes NFLX playback stall. Reverting to fix canary, even if the
latter's eventual fix might be external (e.g. NFLX web app).

Original issue's description:
> MSE: Relax the 'media segment must begin with keyframe' requirement
> 
> The current version of the MSE spec no longer requires that media segments
> start with a keyframe. This change reworks the MSE implementation
> so that it now allows tracks within media segments to not begin
> with a keyframe.
> 
> To accomplish this requirement's relaxation, this CL:
> 1) Separates media segment signaling from coded frame group signaling:
>    MSE stream parsers need to report whether or not they are currently
>    in the middle of parsing a media segment, such as a WebM cluster, to
>    comply with spec disallowance of certain operations like changing
>    SourceBuffer appendMode when appendState is PARSING_MEDIA_SEGMENT.
>    However, SourceBufferStream only needs to be signaled when a new coded
>    frame group is beginning, for example when buffers are appended
>    following a discontinuity.
> 2) Since the FrameProcessor now can transitively signal SourceBufferStreams
>    when a new coded frame group is beginning (which might span multiple
>    media segments), the SourceBufferStream can rely upon the fact
>    that the next buffer appended must be a keyframe if it's been told
>    that a new coded frame group is starting. A CHECK() is included.
> 3) New ChunkDemuxerTests.
> 4) Various test cleanup to conform to the distinct "new coded frame group"
>    and "new media segment" signaling separation, as well as removal
>    of decode error verification when a media segment doesn't begin
>    with a keyframe.
> 
> Note that the FrameProcessor already drops non-keyframes prior to the
> first keyframe processed for a track following a discontinuity,
> and the SourceBufferStream already drops non-keyframes prior to the
> first keyframe processed for a track following a range removal that
> removed the last appended position in the current coded frame group.
> 
> BUG=229412,459546
> R=chcunningham@chromium.org
> TEST=Updated ChunkDemuxerTests, SourceBufferStreamTests,
> FrameProcessorTests. Also locally tested: bug 459546's
> original report no longer fails. A sample webm VP9 file
> from b/26524063 no longer fails. GPM webm vp9/opus test no
> longer fails. Bug 518854's original report's "flags_all.mp4"
> no longer fails.
> 
> Committed: https://crrev.com/3d152e528e97024860822d3e75109c0c597bf4de
> Cr-Commit-Position: refs/heads/master@{#371018}

TBR=chcunningham@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=229412,459546
==========

[commit-bot: I haz the power, 2016-01-27 00:41:29]

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

[commit-bot: I haz the power, 2016-01-27 00:53:56]

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

[commit-bot: I haz the power, 2016-01-27 00:53:56]

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, 2016-01-27 00:59:32]

Silly presubmit source formatting rule failure (original code had bad format,
revert tries to reinstate the original code and fails the format check). Once
all the other bots are green, I'll switch to NOTRY and land it.

[wolenetz, 2016-01-27 01:01:27]

On 2016/01/27 00:59:32, wolenetz wrote:
> Silly presubmit source formatting rule failure (original code had bad format,
> revert tries to reinstate the original code and fails the format check). Once
> all the other bots are green, I'll switch to NOTRY and land it.

s/NOTRY/NOPRESUBMIT=true

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

Description was changed from

==========
Revert of MSE: Relax the 'media segment must begin with keyframe' requirement
(patchset #13 id:240001 of https://codereview.chromium.org/1091293005/ )

Reason for revert:
Two regressions:
BUG=581125,581458

The latter causes NFLX playback stall. Reverting to fix canary, even if the
latter's eventual fix might be external (e.g. NFLX web app).

Original issue's description:
> MSE: Relax the 'media segment must begin with keyframe' requirement
> 
> The current version of the MSE spec no longer requires that media segments
> start with a keyframe. This change reworks the MSE implementation
> so that it now allows tracks within media segments to not begin
> with a keyframe.
> 
> To accomplish this requirement's relaxation, this CL:
> 1) Separates media segment signaling from coded frame group signaling:
>    MSE stream parsers need to report whether or not they are currently
>    in the middle of parsing a media segment, such as a WebM cluster, to
>    comply with spec disallowance of certain operations like changing
>    SourceBuffer appendMode when appendState is PARSING_MEDIA_SEGMENT.
>    However, SourceBufferStream only needs to be signaled when a new coded
>    frame group is beginning, for example when buffers are appended
>    following a discontinuity.
> 2) Since the FrameProcessor now can transitively signal SourceBufferStreams
>    when a new coded frame group is beginning (which might span multiple
>    media segments), the SourceBufferStream can rely upon the fact
>    that the next buffer appended must be a keyframe if it's been told
>    that a new coded frame group is starting. A CHECK() is included.
> 3) New ChunkDemuxerTests.
> 4) Various test cleanup to conform to the distinct "new coded frame group"
>    and "new media segment" signaling separation, as well as removal
>    of decode error verification when a media segment doesn't begin
>    with a keyframe.
> 
> Note that the FrameProcessor already drops non-keyframes prior to the
> first keyframe processed for a track following a discontinuity,
> and the SourceBufferStream already drops non-keyframes prior to the
> first keyframe processed for a track following a range removal that
> removed the last appended position in the current coded frame group.
> 
> BUG=229412,459546
> R=chcunningham@chromium.org
> TEST=Updated ChunkDemuxerTests, SourceBufferStreamTests,
> FrameProcessorTests. Also locally tested: bug 459546's
> original report no longer fails. A sample webm VP9 file
> from b/26524063 no longer fails. GPM webm vp9/opus test no
> longer fails. Bug 518854's original report's "flags_all.mp4"
> no longer fails.
> 
> Committed: https://crrev.com/3d152e528e97024860822d3e75109c0c597bf4de
> Cr-Commit-Position: refs/heads/master@{#371018}

TBR=chcunningham@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=229412,459546
==========

to

==========
Revert of MSE: Relax the 'media segment must begin with keyframe' requirement
(patchset #13 id:240001 of https://codereview.chromium.org/1091293005/ )

Reason for revert:
Two regressions:
BUG=581125,581458

The latter causes NFLX playback stall. Reverting to fix canary, even if the
latter's eventual fix might be external (e.g. NFLX web app).

To allow revert to currently failing code format rules:
NOPRESUBMIT=true

Original issue's description:
> MSE: Relax the 'media segment must begin with keyframe' requirement
> 
> The current version of the MSE spec no longer requires that media segments
> start with a keyframe. This change reworks the MSE implementation
> so that it now allows tracks within media segments to not begin
> with a keyframe.
> 
> To accomplish this requirement's relaxation, this CL:
> 1) Separates media segment signaling from coded frame group signaling:
>    MSE stream parsers need to report whether or not they are currently
>    in the middle of parsing a media segment, such as a WebM cluster, to
>    comply with spec disallowance of certain operations like changing
>    SourceBuffer appendMode when appendState is PARSING_MEDIA_SEGMENT.
>    However, SourceBufferStream only needs to be signaled when a new coded
>    frame group is beginning, for example when buffers are appended
>    following a discontinuity.
> 2) Since the FrameProcessor now can transitively signal SourceBufferStreams
>    when a new coded frame group is beginning (which might span multiple
>    media segments), the SourceBufferStream can rely upon the fact
>    that the next buffer appended must be a keyframe if it's been told
>    that a new coded frame group is starting. A CHECK() is included.
> 3) New ChunkDemuxerTests.
> 4) Various test cleanup to conform to the distinct "new coded frame group"
>    and "new media segment" signaling separation, as well as removal
>    of decode error verification when a media segment doesn't begin
>    with a keyframe.
> 
> Note that the FrameProcessor already drops non-keyframes prior to the
> first keyframe processed for a track following a discontinuity,
> and the SourceBufferStream already drops non-keyframes prior to the
> first keyframe processed for a track following a range removal that
> removed the last appended position in the current coded frame group.
> 
> BUG=229412,459546
> R=chcunningham@chromium.org
> TEST=Updated ChunkDemuxerTests, SourceBufferStreamTests,
> FrameProcessorTests. Also locally tested: bug 459546's
> original report no longer fails. A sample webm VP9 file
> from b/26524063 no longer fails. GPM webm vp9/opus test no
> longer fails. Bug 518854's original report's "flags_all.mp4"
> no longer fails.
> 
> Committed: https://crrev.com/3d152e528e97024860822d3e75109c0c597bf4de
> Cr-Commit-Position: refs/heads/master@{#371018}

TBR=chcunningham@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=229412,459546
==========

[wolenetz, 2016-01-27 01:02:22]

The CQ bit was checked by wolenetz@chromium.org

[commit-bot: I haz the power, 2016-01-27 01:08:03]

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

[commit-bot: I haz the power, 2016-01-27 01:54:37]

Description was changed from

==========
Revert of MSE: Relax the 'media segment must begin with keyframe' requirement
(patchset #13 id:240001 of https://codereview.chromium.org/1091293005/ )

Reason for revert:
Two regressions:
BUG=581125,581458

The latter causes NFLX playback stall. Reverting to fix canary, even if the
latter's eventual fix might be external (e.g. NFLX web app).

To allow revert to currently failing code format rules:
NOPRESUBMIT=true

Original issue's description:
> MSE: Relax the 'media segment must begin with keyframe' requirement
> 
> The current version of the MSE spec no longer requires that media segments
> start with a keyframe. This change reworks the MSE implementation
> so that it now allows tracks within media segments to not begin
> with a keyframe.
> 
> To accomplish this requirement's relaxation, this CL:
> 1) Separates media segment signaling from coded frame group signaling:
>    MSE stream parsers need to report whether or not they are currently
>    in the middle of parsing a media segment, such as a WebM cluster, to
>    comply with spec disallowance of certain operations like changing
>    SourceBuffer appendMode when appendState is PARSING_MEDIA_SEGMENT.
>    However, SourceBufferStream only needs to be signaled when a new coded
>    frame group is beginning, for example when buffers are appended
>    following a discontinuity.
> 2) Since the FrameProcessor now can transitively signal SourceBufferStreams
>    when a new coded frame group is beginning (which might span multiple
>    media segments), the SourceBufferStream can rely upon the fact
>    that the next buffer appended must be a keyframe if it's been told
>    that a new coded frame group is starting. A CHECK() is included.
> 3) New ChunkDemuxerTests.
> 4) Various test cleanup to conform to the distinct "new coded frame group"
>    and "new media segment" signaling separation, as well as removal
>    of decode error verification when a media segment doesn't begin
>    with a keyframe.
> 
> Note that the FrameProcessor already drops non-keyframes prior to the
> first keyframe processed for a track following a discontinuity,
> and the SourceBufferStream already drops non-keyframes prior to the
> first keyframe processed for a track following a range removal that
> removed the last appended position in the current coded frame group.
> 
> BUG=229412,459546
> R=chcunningham@chromium.org
> TEST=Updated ChunkDemuxerTests, SourceBufferStreamTests,
> FrameProcessorTests. Also locally tested: bug 459546's
> original report no longer fails. A sample webm VP9 file
> from b/26524063 no longer fails. GPM webm vp9/opus test no
> longer fails. Bug 518854's original report's "flags_all.mp4"
> no longer fails.
> 
> Committed: https://crrev.com/3d152e528e97024860822d3e75109c0c597bf4de
> Cr-Commit-Position: refs/heads/master@{#371018}

TBR=chcunningham@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=229412,459546
==========

to

==========
Revert of MSE: Relax the 'media segment must begin with keyframe' requirement
(patchset #13 id:240001 of https://codereview.chromium.org/1091293005/ )

Reason for revert:
Two regressions:
BUG=581125,581458

The latter causes NFLX playback stall. Reverting to fix canary, even if the
latter's eventual fix might be external (e.g. NFLX web app).

To allow revert to currently failing code format rules:
NOPRESUBMIT=true

Original issue's description:
> MSE: Relax the 'media segment must begin with keyframe' requirement
> 
> The current version of the MSE spec no longer requires that media segments
> start with a keyframe. This change reworks the MSE implementation
> so that it now allows tracks within media segments to not begin
> with a keyframe.
> 
> To accomplish this requirement's relaxation, this CL:
> 1) Separates media segment signaling from coded frame group signaling:
>    MSE stream parsers need to report whether or not they are currently
>    in the middle of parsing a media segment, such as a WebM cluster, to
>    comply with spec disallowance of certain operations like changing
>    SourceBuffer appendMode when appendState is PARSING_MEDIA_SEGMENT.
>    However, SourceBufferStream only needs to be signaled when a new coded
>    frame group is beginning, for example when buffers are appended
>    following a discontinuity.
> 2) Since the FrameProcessor now can transitively signal SourceBufferStreams
>    when a new coded frame group is beginning (which might span multiple
>    media segments), the SourceBufferStream can rely upon the fact
>    that the next buffer appended must be a keyframe if it's been told
>    that a new coded frame group is starting. A CHECK() is included.
> 3) New ChunkDemuxerTests.
> 4) Various test cleanup to conform to the distinct "new coded frame group"
>    and "new media segment" signaling separation, as well as removal
>    of decode error verification when a media segment doesn't begin
>    with a keyframe.
> 
> Note that the FrameProcessor already drops non-keyframes prior to the
> first keyframe processed for a track following a discontinuity,
> and the SourceBufferStream already drops non-keyframes prior to the
> first keyframe processed for a track following a range removal that
> removed the last appended position in the current coded frame group.
> 
> BUG=229412,459546
> R=chcunningham@chromium.org
> TEST=Updated ChunkDemuxerTests, SourceBufferStreamTests,
> FrameProcessorTests. Also locally tested: bug 459546's
> original report no longer fails. A sample webm VP9 file
> from b/26524063 no longer fails. GPM webm vp9/opus test no
> longer fails. Bug 518854's original report's "flags_all.mp4"
> no longer fails.
> 
> Committed: https://crrev.com/3d152e528e97024860822d3e75109c0c597bf4de
> Cr-Commit-Position: refs/heads/master@{#371018}

TBR=chcunningham@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=229412,459546
==========

[commit-bot: I haz the power, 2016-01-27 01:54:38]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-01-27 01:56:17]

Description was changed from

==========
Revert of MSE: Relax the 'media segment must begin with keyframe' requirement
(patchset #13 id:240001 of https://codereview.chromium.org/1091293005/ )

Reason for revert:
Two regressions:
BUG=581125,581458

The latter causes NFLX playback stall. Reverting to fix canary, even if the
latter's eventual fix might be external (e.g. NFLX web app).

To allow revert to currently failing code format rules:
NOPRESUBMIT=true

Original issue's description:
> MSE: Relax the 'media segment must begin with keyframe' requirement
> 
> The current version of the MSE spec no longer requires that media segments
> start with a keyframe. This change reworks the MSE implementation
> so that it now allows tracks within media segments to not begin
> with a keyframe.
> 
> To accomplish this requirement's relaxation, this CL:
> 1) Separates media segment signaling from coded frame group signaling:
>    MSE stream parsers need to report whether or not they are currently
>    in the middle of parsing a media segment, such as a WebM cluster, to
>    comply with spec disallowance of certain operations like changing
>    SourceBuffer appendMode when appendState is PARSING_MEDIA_SEGMENT.
>    However, SourceBufferStream only needs to be signaled when a new coded
>    frame group is beginning, for example when buffers are appended
>    following a discontinuity.
> 2) Since the FrameProcessor now can transitively signal SourceBufferStreams
>    when a new coded frame group is beginning (which might span multiple
>    media segments), the SourceBufferStream can rely upon the fact
>    that the next buffer appended must be a keyframe if it's been told
>    that a new coded frame group is starting. A CHECK() is included.
> 3) New ChunkDemuxerTests.
> 4) Various test cleanup to conform to the distinct "new coded frame group"
>    and "new media segment" signaling separation, as well as removal
>    of decode error verification when a media segment doesn't begin
>    with a keyframe.
> 
> Note that the FrameProcessor already drops non-keyframes prior to the
> first keyframe processed for a track following a discontinuity,
> and the SourceBufferStream already drops non-keyframes prior to the
> first keyframe processed for a track following a range removal that
> removed the last appended position in the current coded frame group.
> 
> BUG=229412,459546
> R=chcunningham@chromium.org
> TEST=Updated ChunkDemuxerTests, SourceBufferStreamTests,
> FrameProcessorTests. Also locally tested: bug 459546's
> original report no longer fails. A sample webm VP9 file
> from b/26524063 no longer fails. GPM webm vp9/opus test no
> longer fails. Bug 518854's original report's "flags_all.mp4"
> no longer fails.
> 
> Committed: https://crrev.com/3d152e528e97024860822d3e75109c0c597bf4de
> Cr-Commit-Position: refs/heads/master@{#371018}

TBR=chcunningham@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=229412,459546
==========

to

==========
Revert of MSE: Relax the 'media segment must begin with keyframe' requirement
(patchset #13 id:240001 of https://codereview.chromium.org/1091293005/ )

Reason for revert:
Two regressions:
BUG=581125,581458

The latter causes NFLX playback stall. Reverting to fix canary, even if the
latter's eventual fix might be external (e.g. NFLX web app).

To allow revert to currently failing code format rules:
NOPRESUBMIT=true

Original issue's description:
> MSE: Relax the 'media segment must begin with keyframe' requirement
>
> The current version of the MSE spec no longer requires that media segments
> start with a keyframe. This change reworks the MSE implementation
> so that it now allows tracks within media segments to not begin
> with a keyframe.
>
> To accomplish this requirement's relaxation, this CL:
> 1) Separates media segment signaling from coded frame group signaling:
>    MSE stream parsers need to report whether or not they are currently
>    in the middle of parsing a media segment, such as a WebM cluster, to
>    comply with spec disallowance of certain operations like changing
>    SourceBuffer appendMode when appendState is PARSING_MEDIA_SEGMENT.
>    However, SourceBufferStream only needs to be signaled when a new coded
>    frame group is beginning, for example when buffers are appended
>    following a discontinuity.
> 2) Since the FrameProcessor now can transitively signal SourceBufferStreams
>    when a new coded frame group is beginning (which might span multiple
>    media segments), the SourceBufferStream can rely upon the fact
>    that the next buffer appended must be a keyframe if it's been told
>    that a new coded frame group is starting. A CHECK() is included.
> 3) New ChunkDemuxerTests.
> 4) Various test cleanup to conform to the distinct "new coded frame group"
>    and "new media segment" signaling separation, as well as removal
>    of decode error verification when a media segment doesn't begin
>    with a keyframe.
>
> Note that the FrameProcessor already drops non-keyframes prior to the
> first keyframe processed for a track following a discontinuity,
> and the SourceBufferStream already drops non-keyframes prior to the
> first keyframe processed for a track following a range removal that
> removed the last appended position in the current coded frame group.
>
> BUG=229412,459546
> R=chcunningham@chromium.org
> TEST=Updated ChunkDemuxerTests, SourceBufferStreamTests,
> FrameProcessorTests. Also locally tested: bug 459546's
> original report no longer fails. A sample webm VP9 file
> from b/26524063 no longer fails. GPM webm vp9/opus test no
> longer fails. Bug 518854's original report's "flags_all.mp4"
> no longer fails.
>
> Committed: https://crrev.com/3d152e528e97024860822d3e75109c0c597bf4de
> Cr-Commit-Position: refs/heads/master@{#371018}

TBR=chcunningham@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=229412,459546

Committed: https://crrev.com/4d3c457f2301754ca4321c77c8ff13e69dec8acc
Cr-Commit-Position: refs/heads/master@{#371686}
==========

[commit-bot: I haz the power, 2016-01-27 01:56:18]

Patchset 1 (id:??) landed as
https://crrev.com/4d3c457f2301754ca4321c77c8ff13e69dec8acc
Cr-Commit-Position: refs/heads/master@{#371686}