[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 #46 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2011-09-22 12:58:04 UTC ---
W.r.t "a problem" as mentioned above it seems (FTR) that it is due to the way
GstCollectPads2 is being (ab)used here, in particular the newsegment handling
approach, or rather lack thereof.

Specifically, the (as said) simple approach of the "newsegment plugin" consists
of only sending a single newsegment event.  As such, there is indeed and
evidently "a long time before that audio buffer got awoken" as it is generally
meant to be awoken by newsegment event activity that is totally discarded here.

However, as it stands, afaics it can be pretty easily patched to handle such
use as well, e.g. add a gst_collect_pads2_recalculate_full (pads) at the end of
gst_collect_pads2_default_collected (and it should again release the sparse
stream from being waited on).

As such, the 'bitfield algo' is not so much an alternative algo, but an
alternative implementation that (incidentally) happens to sort-of implicitly
include the above easy fix (as side-effect).

Comments/thoughts that spring to mind regarding it:
* afaics (quickly) it should work
* ... except e.g. for only being able to handle a finite number of pads in a
bitfield.  And as such there is some problematic code in _add_pad that dumps
another pad if overrun.  Probably there will never be so many pads, but that's
the tricky stuff with generic library code (trade off between fast/simple and
general/complicated).
* don't really like or see the need to rename _set_waiting to _set_sparse.  A
stream is (considered) sparse or it is not (typically so designated in
developer speak).  OTOH, the _set_waiting (likely) really regularly changes a
transient state, i.e. whether it needs to be waited for or not (it does not
flip sparse or not back and forth).

Also, btw, while it may (or not?) work for mpegtsmux, it is generally not
recommended to have all pads considered as sparse.  This could cause buffer
collection to start before all pads have a buffer, so before all pads have been
negotiated.  Hence, a muxer that needs to write some header may have a lot of
info for doing so still missing when it needs it.  Therefore, it is best to
have some streams as locked/continuous (e.g. video/audio) and others
not-locked/sparse along with special purpose code that can handle header
re-writing.

Of course, if no "header", then likely not so much an issue (at all).

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