[Bug 767071] qtdemux: Various SEGMENT event related fixes, including regression fixes

[GStreamer (GNOME Bugzilla)]

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

--- Comment #12 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #11)
> (In reply to Thiago Sousa Santos from comment #10)
> > Review of attachment 328807 [details] [review] [review]:
> > 
> > dash should default to creating a 'dummy segment' that has its stop time
> > updated and increasing when new data is parsed. So what happens here is that
> > the segment isn't activated as the stop-time is still too small if you seek
> > forward to a fragment that isn't available yet.
> > 
> > Forwarding the segment directly for fragmented would work, but I think just
> > doing it when dummy_segment == true would cover more cases. Also it worries
> > me a bit that validate didn't catch any of these issues, will check what
> > tests are missing there.
> 
> What's dummy_segment and how is that supposed to work? The problem here is
> that adaptivedemux will have to push a SEGMENT event for the seek, and only
> after that it can push the new moof from which qtdemux would know that there
> is actually data available at the segment start.

As there is no edts, qtdemux fakes it by creating a qt-segment that goes from 0
to the current last timestamp. With dash it should grow a bit after every moof.
The problem is that the user can seek to a position much more forward than what
qtdemux has seen so far, so it will just assume it is EOS.

The fix by forwarding the segment event directly if it is fragment already
improves the problem for dash but I think there is a more generic way to just
forward it for streams that use this 'dummy segment'.

As the forward for fragmented already improves the situation we can push that
to make things work again and then improve it again by checking the
dummy_segment flag once I figure out how to improve validate to properly cover
these use cases.

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