[Bug 795424] qtdemux: Add MSE-style flush

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=795424

--- Comment #20 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Alicia Boya García from comment #19)
> (In reply to Sebastian Dröge (slomo) from comment #16)
> > I could imagine apps/users wanting to flush while keeping the sample table
> > too. IMHO you should re-use the existing logic that is already there for
> > resyncing the adaptivedemux keyframe-only mode.
> > 
> > Make sure to look at buffer offsets, check for a new moov/moof, etc after
> > the flush.
> > 
> > While you might not need that right now, let's better fix this properly from
> > the beginning.
> 
> Can you provide an example of a test case where you would want to keep the
> sample table after a user-initiated flush? I can't think of any case. What
> would such a flush be supposed to reset?

It would flush everything downstream to directly start playback again from
whatever next data comes. Similarly to how the adaptivedemux keyframe-only mode
is currently implemented in qtdemux.

> > > > The demuxer should not depend on the flush coming from a seek or not, and it
> > > > should also properly handle disconts in the stream (as signaled by the
> > > > corresponding buffer flag).
> > > 
> > > Well, if you get a flushing seek, and transmit a flushing seek upstream, you
> > > can rely on the fact that you will get flushes. Or what you meant was
> > > related to making a distinction between a flush coming from a seek or coming
> > > from something else? I think it is not so unusual in practice.
> > 
> > It requires additional code for mapping seek and flushes together though.
> > This seems unnecessary and potentially fragile (what if a flush arrives just
> > between the seek and upstream flushing us?)
> 
> That won't happen because the seek is synchronous. Indeed, this fact is used
> to reset demux->offset_seek_seqnum after the seek. (See
> qtdemux_seek_offset() and gst_qtdemux_do_push_seek())

There's nothing preventing another flush-start from another thread, it's an OOB
event.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.