[Bug 706779] oggmux: support flushing seeks

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=706779
  GStreamer | gst-plugins-base | git

--- Comment #2 from Sebastian Dröge (slomo) <slomo at circular-chaos.org> 2013-08-26 07:39:41 UTC ---
(In reply to comment #0)
> Created an attachment (id=253094)
 View: https://bugzilla.gnome.org/attachment.cgi?id=253094
 Review: https://bugzilla.gnome.org/review?bug=706779&attachment=253094

> WIP patch
> 
> Here's some initial code that adds flushing seek support to oggmux. Likely not
> 100% correct/complete, but works for the simple case audiotestsrc ! vorbisenc !
> oggmux ! filesink
> 
> The logic is copied from (my limited understanding of) videomixer. Things i'm
> not sure about:
> 
> 1) not sure if what happens in the case upstream fails to seek after
> gst_ogg_mux_handle_src_event has already sent FLUSH_START is correct. In that
> case gst_ogg_mux_collected will send a flush_stop but won't send a new segment.
> Should it?

What happens when a seek fails? Doesn't it just error out anyway?

> 2) FLUSH_STOP aggregation is done by forwarding the first FLUSH_STOP and then
> ignoring the others. That's what videomixer does but what if this case happens:
> one upstream sends FLUSH_STOP; another upstream sends more data belonging to
> the old segment; the other upstream finally sends FLUSH_STOP. Isn't this racy?

I think you should wait until all FLUSH_START of all upstreams are received.
After that you can safely forward the very first FLUSH_STOP. Any data that is
sent from upstream before the FLUSH_STOP is dropped because the pads are
flushing.

> 3) related to 2), the code that handles the _SEEK sets collectpads to flushing,
> grabs GST_COLLECT_PADS_STREAM_LOCK, sets some internal flags, unsets
> collectpads flushing. Is that really enough? shouldn't it wait until upstreams
> have started flushing?

Wait until upstream started flushing until doing what?

> And a final note: the muxer still outputs a start=0, stop=-1 segment. I wonder 
> if it's worth making it output the incoming seek segment given that other
> places in the code make the assumption that timestamps start from 0 (see
> gst_ogg_mux_decorate_buffer for example)

After a seek it should output exactly the seek segment.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.