[Bug 415754] [API] GstCollectPads2; muxing sparse/subtitle streams

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=415754
  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
queues etc.

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
one.

-- 
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.