Chromium Code Reviews
Help | Chromium Project | Gerrit Changes | Sign in
(131)

Issue 1089873006: WIP - MSE: Drop non-keyframes that lack keyframe dependency (Closed)

Created:
3 years, 11 months ago by wolenetz
Modified:
3 years, 1 month ago
Reviewers:
chcunningham
CC:
chromium-reviews, feature-media-reviews_chromium.org
Base URL:
https://chromium.googlesource.com/chromium/src.git@master
Target Ref:
refs/pending/heads/master
Project:
chromium
Visibility:
Public.

Description

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))

Patch Set 1 #

Patch Set 2 : Adds SBSTests.LeadingNonKeyframes_Kept #

Patch Set 3 : Checkpoint of WIP while I work on prereq https://codereview.chromium.org/1091293005/ #

Unified diffs Side-by-side diffs Delta from patch set Stats (+151 lines, -1 line) Patch
M media/filters/chunk_demuxer.h View 1 2 1 chunk +4 lines, -0 lines 0 comments Download
M media/filters/chunk_demuxer.cc View 1 2 5 chunks +24 lines, -1 line 0 comments Download
M media/filters/frame_processor.h View 1 2 1 chunk +11 lines, -0 lines 0 comments Download
M media/filters/frame_processor.cc View 1 2 1 chunk +49 lines, -0 lines 0 comments Download
M media/filters/source_buffer_stream.h View 1 2 4 chunks +17 lines, -0 lines 0 comments Download
M media/filters/source_buffer_stream_unittest.cc View 1 1 chunk +46 lines, -0 lines 0 comments Download

Messages

Total messages: 8 (1 generated)
wolenetz
No review needed yet. I'm just uploading current state as I work on this work-in-progress ...
3 years, 11 months ago (2015-04-20 23:37:54 UTC) #2
wolenetz
Chris, if you could please take a look at the current CL description and identify ...
3 years, 11 months ago (2015-04-21 00:03:41 UTC) #3
chcunningham
On 2015/04/21 00:03:41, wolenetz wrote: > Chris, if you could please take a look at ...
3 years, 11 months ago (2015-04-22 20:22:46 UTC) #4
wolenetz
On 2015/04/22 20:22:46, chcunningham wrote: > On 2015/04/21 00:03:41, wolenetz wrote: > > Chris, if ...
3 years, 11 months ago (2015-04-22 20:43:15 UTC) #5
wolenetz
On 2015/04/22 20:43:15, wolenetz wrote: > On 2015/04/22 20:22:46, chcunningham wrote: > > On 2015/04/21 ...
3 years, 10 months ago (2015-04-24 21:03:14 UTC) #6
wolenetz
On 2015/04/24 21:03:14, wolenetz wrote: > On 2015/04/22 20:43:15, wolenetz wrote: > > On 2015/04/22 ...
3 years, 6 months ago (2015-09-09 23:17:42 UTC) #7
wolenetz
3 years, 1 month ago (2016-01-20 01:12:08 UTC) #8
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: ^^^

Powered by Google App Engine
This is Rietveld 408576698