[Bug 415754] [API] GstCollectPads2; muxing sparse/subtitle streams
bugzilla at gnome.org
Mon Sep 26 10:07:11 PDT 2011
GStreamer | gstreamer (core) | git
--- Comment #48 from Ben Cahill <ben.m.cahill at intel.com> 2011-09-26 17:07:00 UTC ---
(In reply to comment #46)
> 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).
It works! I'm happy with this solution ... wish you'd mentioned it a while ago
;-) ... would you be willing to submit a patch? If not, I could, but I think
you would do a better job of understanding any side effects, etc.
Thanks for your comments about fast/simple vs. generic/complicated code ... I
tried using GArray to make the bitmasks extendable ... and of course it blew up
to be bigger than I would have liked, so I'm happy you figured out another way.
I'm still wondering how to use newsegments in a more intelligent way than I
have, but I'm completely baffled by my use case of a live source with
non-predictable frame time/duration, AND trying to minimize latency ... the
"brain-dead" approach in my sparsesegments plugin works for me (and it does
wait for the first frame before inserting the far-in-the-future newsegment, so
header is complete), but please let me know if you have a better suggestion.
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