[Bug 706779] New: oggmux: support flushing seeks
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Sun Aug 25 23:25:34 PDT 2013
https://bugzilla.gnome.org/show_bug.cgi?id=706779
GStreamer | gst-plugins-base | git
Summary: oggmux: support flushing seeks
Classification: Platform
Product: GStreamer
Version: git
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: gst-plugins-base
AssignedTo: gstreamer-bugs at lists.freedesktop.org
ReportedBy: alessandro.d at gmail.com
QAContact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Created an attachment (id=253094)
--> (https://bugzilla.gnome.org/attachment.cgi?id=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?
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?
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?
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)
Halp!
--
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.
More information about the gstreamer-bugs
mailing list