[Bug 415754] [API] GstCollectPads2; muxing sparse/subtitle streams
bugzilla at gnome.org
Tue Sep 27 07:03:17 PDT 2011
GStreamer | gstreamer (core) | git
--- Comment #49 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2011-09-27 14:03:01 UTC ---
IIRC, newsegment events are usually sent (e.g. by demuxers) with a 0.5s
interval (as "magic value"), which happens to work/interact well with usual
But there is not really a right or wrong here. With the "fix" (or whatever) in
place, collectpads2 should be able to handle the "brain-dead" approach as well
(so it appears) and that may be good enough.
The only "real" difference/impact with using an "infinite" segment is that it
prevents collectpads2 from (ever) waiting on (sparse) video, which could lead
to some out-of-order timestamping. That is, audio with ts X might already be
picked, and only then video with ts Y < X might arrive and be picked. In a
live use-case such as this, however, X - Y is probably small and the container
format and/or subsequent playback are (probably?) not going to trip over that.
So, this simple (newsegment) approach may very well suffice in this particular
scenario, whereas other cases (e.g. non-live (re)muxing) require a more subtle
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