[Bug 795424] qtdemux: Add MSE-style flush

[GStreamer (GNOME Bugzilla)]

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

--- Comment #16 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Thibault Saunier from comment #15)
> (In reply to Sebastian Dröge (slomo) from comment #7)
> > Yes I agree with Thibault here. The tricky part will be about keeping the
> > sample tables or not. After a flush, the demuxer should probably check if
> > the first buffer contains a moov/moof somehow for your case, and for the
> > seek case (and also adaptivedemux keyframe-only mode) check if we're at a
> > known sample boundary.
> 
> This patch takes a simple approach where the sample table is flushed
> whenever we get a flush from the "app/user" it might not be always correct
> indeed, but I guess it won't break (people should not flush without knowing
> what they do :)), do you think it would?

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.

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

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