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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Sep 26 10:07:11 PDT 2011


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