[Bug 795424] qtdemux: Add MSE-style flush

[GStreamer (GNOME Bugzilla)]

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

--- Comment #19 from Alicia Boya García <aboya at igalia.com> ---
(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?

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

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