WIP - MSE: Drop non-keyframes that lack keyframe dependency

WIP - MSE: Drop non-keyframes that lack keyframe dependency

This change relaxes the previous requirement that all media segments'
(e.g. WebM clusters', MP4 moofs', etc.) tracks begin with keyframes.

Specifically, this change:
TODO
* Modifies the coded frame processing algorithm to signal "new coded
  frame group", rather than "new media segment", when it detects an
  append discontinuity. Parser's signaling of begin and end of media
  segments is retained so that the API can behave correctly depending on
  "PARSING_MEDIA_SEGMENT".
Update: See separate WIP CL for this piece: https://codereview.chromium.org/1091293005/

TODO
* Updates SourceState(?? TODO or SBS?? :: needs to know GC side-effect
  as well as Remove() from API) to signal the coded frame processing
  algorithm when range removals occur. CFP then uses this to determine
  if the range removal impacts any of the tracks such that an append
  discontinuity in the current coded frame group could have been
  introduced.

* Retains previous behavior (in compliant coded frame processor) that
  drops non-keyframes occurring at the beginning of a "coded frame
  group" following an append discontinuity.

TODO:
* Changes the SourceBufferStream::Append() decode error when a media
  segment begins with a non-keyframe to a CHECK when a new coded frame
  group begins with a non-keyframe. The coded frame processor is
  depended upon to emit the "new coded frame group" signal correctly and
  to drop any leading non-keyframes in a new coded frame group.

BUG=229412
TEST=New SourceBufferStreamTests: LeadingNonKeyframes_Kept, LeadingNonKeyframes_Dropped, NonKeyframesDirectlyFollowingRemovedRange_Dropped
TODO: more tests (layout, chunkdemuxer (muxed coded frame group behaviour around remove, for instance))

[wolenetz, 2015-04-20 23:37:18]

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

[wolenetz, 2015-04-20 23:37:54]

No review needed yet. I'm just uploading current state as I work on this
work-in-progress fix for bug 229412.

[wolenetz, 2015-04-21 00:03:41]

Chris, if you could please take a look at the current CL description and
identify anything that appears wrong, I would appreciate it. Of course, much
implementation will follow; I just want a sanity check on strategy for this fix.

[chcunningham, 2015-04-22 20:22:46]

On 2015/04/21 00:03:41, wolenetz wrote:
> Chris, if you could please take a look at the current CL description and
> identify anything that appears wrong, I would appreciate it. Of course, much
> implementation will follow; I just want a sanity check on strategy for this
fix.

Hey Matt, sorry for the slow reply. We've chatted in person, but just to say it
officially here - the plan you've laid out sounds great.

[wolenetz, 2015-04-22 20:43:15]

On 2015/04/22 20:22:46, chcunningham wrote:
> On 2015/04/21 00:03:41, wolenetz wrote:
> > Chris, if you could please take a look at the current CL description and
> > identify anything that appears wrong, I would appreciate it. Of course, much
> > implementation will follow; I just want a sanity check on strategy for this
> fix.
> 
> Hey Matt, sorry for the slow reply. We've chatted in person, but just to say
it
> officially here - the plan you've laid out sounds great.

Thanks Chris.
Note, I believe the MSE spec will also require some update to make it clear that
a range removal that impacts the most recently appended buffer in any of the
SourceBuffer's tracks (or maybe just the one with the highest end time?) needs
to trigger the same conditions in the coded frame processing algorithm as when
it detects a discontinuity during appends.
This CL will then be made to align with the updated spec.

[wolenetz, 2015-04-24 21:03:14]

On 2015/04/22 20:43:15, wolenetz wrote:
> On 2015/04/22 20:22:46, chcunningham wrote:
> > On 2015/04/21 00:03:41, wolenetz wrote:
> > > Chris, if you could please take a look at the current CL description and
> > > identify anything that appears wrong, I would appreciate it. Of course,
much
> > > implementation will follow; I just want a sanity check on strategy for
this
> > fix.
> > 
> > Hey Matt, sorry for the slow reply. We've chatted in person, but just to say
> it
> > officially here - the plan you've laid out sounds great.
> 
> Thanks Chris.
> Note, I believe the MSE spec will also require some update to make it clear
that
> a range removal that impacts the most recently appended buffer in any of the
> SourceBuffer's tracks (or maybe just the one with the highest end time?) needs
> to trigger the same conditions in the coded frame processing algorithm as when
> it detects a discontinuity during appends.
> This CL will then be made to align with the updated spec.

I've filed MSE spec bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=28557 to
track corresponding updates to the spec.

[wolenetz, 2015-09-09 23:17:42]

On 2015/04/24 21:03:14, wolenetz wrote:
> On 2015/04/22 20:43:15, wolenetz wrote:
> > On 2015/04/22 20:22:46, chcunningham wrote:
> > > On 2015/04/21 00:03:41, wolenetz wrote:
> > > > Chris, if you could please take a look at the current CL description and
> > > > identify anything that appears wrong, I would appreciate it. Of course,
> much
> > > > implementation will follow; I just want a sanity check on strategy for
> this
> > > fix.
> > > 
> > > Hey Matt, sorry for the slow reply. We've chatted in person, but just to
say
> > it
> > > officially here - the plan you've laid out sounds great.
> > 
> > Thanks Chris.
> > Note, I believe the MSE spec will also require some update to make it clear
> that
> > a range removal that impacts the most recently appended buffer in any of the
> > SourceBuffer's tracks (or maybe just the one with the highest end time?)
needs
> > to trigger the same conditions in the coded frame processing algorithm as
when
> > it detects a discontinuity during appends.
> > This CL will then be made to align with the updated spec.
> 
> I've filed MSE spec bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=28557
to
> track corresponding updates to the spec.

Update: I've rebased the prereq CL (which is meant to fix the critical
"non-keyframes at the beginning of a coded frame group should simply be
dropped).
Regarding *this* CL, I believe this MSE spec bug clarification (and signalling
CFP on removal of last appended buffer(s) so that CFP drops subsequent
non-keyframes/etc) is not critically required in short term in our Chromium
implementation since the prereq CL (https://codereview.chromium.org/1091293005/)
knows when append-related discontinuities occur (and drops non-keyframes
following an append discontinuity), *and* SourceBufferStream::Append(..) is
already aware of need to drop (without err) non-keyframes not at beginning of
coded frame group but following a remove-induced discontinuity according to
l.286 in
https://codereview.chromium.org/1091293005/diff/60001/media/filters/source_bu....
However, the MSE spec and Chromium will probably still need some sort of
less-critical update to allow for CFP discontinuity logic, especially in
sequence mode or across tracks in a muxed stream, to potentially be triggered by
remove.

[wolenetz, 2016-01-20 01:12:08]

On 2015/09/09 23:17:42, wolenetz wrote:
> On 2015/04/24 21:03:14, wolenetz wrote:
> > On 2015/04/22 20:43:15, wolenetz wrote:
> > > On 2015/04/22 20:22:46, chcunningham wrote:
> > > > On 2015/04/21 00:03:41, wolenetz wrote:
> > > > > Chris, if you could please take a look at the current CL description
and
> > > > > identify anything that appears wrong, I would appreciate it. Of
course,
> > much
> > > > > implementation will follow; I just want a sanity check on strategy for
> > this
> > > > fix.
> > > > 
> > > > Hey Matt, sorry for the slow reply. We've chatted in person, but just to
> say
> > > it
> > > > officially here - the plan you've laid out sounds great.
> > > 
> > > Thanks Chris.
> > > Note, I believe the MSE spec will also require some update to make it
clear
> > that
> > > a range removal that impacts the most recently appended buffer in any of
the
> > > SourceBuffer's tracks (or maybe just the one with the highest end time?)
> needs
> > > to trigger the same conditions in the coded frame processing algorithm as
> when
> > > it detects a discontinuity during appends.
> > > This CL will then be made to align with the updated spec.
> > 
> > I've filed MSE spec bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=28557
> to
> > track corresponding updates to the spec.
> 
> Update: I've rebased the prereq CL (which is meant to fix the critical
> "non-keyframes at the beginning of a coded frame group should simply be
> dropped).
> Regarding *this* CL, I believe this MSE spec bug clarification (and signalling
> CFP on removal of last appended buffer(s) so that CFP drops subsequent
> non-keyframes/etc) is not critically required in short term in our Chromium
> implementation since the prereq CL
(https://codereview.chromium.org/1091293005/)
> knows when append-related discontinuities occur (and drops non-keyframes
> following an append discontinuity), *and* SourceBufferStream::Append(..) is
> already aware of need to drop (without err) non-keyframes not at beginning of
> coded frame group but following a remove-induced discontinuity according to
> l.286 in
>
https://codereview.chromium.org/1091293005/diff/60001/media/filters/source_bu....
> However, the MSE spec and Chromium will probably still need some sort of
> less-critical update to allow for CFP discontinuity logic, especially in
> sequence mode or across tracks in a muxed stream, to potentially be triggered
by
> remove.

Closing this CL, since the previous one appears to be working mostly per the
reasons in the last Update: ^^^