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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Aug 18 07:10:20 PDT 2011

  GStreamer | gstreamer (core) | git

--- Comment #43 from Ben Cahill <ben.m.cahill at intel.com> 2011-08-18 14:10:06 UTC ---
Created an attachment (id=194131)
 View: https://bugzilla.gnome.org/attachment.cgi?id=194131
 Review: https://bugzilla.gnome.org/review?bug=415754&attachment=194131

New plugin to insert newsegment to support sparse streams

This is an attempt at a very simple plugin to insert a newsegment, with start
time "infinitely" (well, almost 300 years) in the future, just after the very
first buffer passes through it.

This supports a use case such as a video stream sourced from ximagesrc, which
can have sporadic gaps when the screen doesn't change.  We want the
accompanying audio stream to continue to be muxed and sent downstream, even
when there are gaps in the video.

This new plugin approach follows some discussion on IRC on 7/29/11 with __tim
and mnauw.  There may be a more sophisticated way for inserting newsegments,
but this "brain-dead" approach seems to work well for me for now.

Actually, this is only part of the solution that I've found to work for me. 
After adding this sparsesegment plugin, I discovered that GstCollectPads2 still
locked up, and blocked audio ... reason was that the sparse stream was chosen
as "best" one time, which made the continuous stream WAIT, and there was
nothing to wake up the continuous stream in a timely way (there was only one
other stream, and it was sparse).

I've put together a new algo for GstCollectPads2 to determine when "collection"
occurs, and to separately determine whether to make a buffer/pad WAIT (making
sure there's another pad that can wake it!).  New algo is based on bitfields,
rather than totals, so it keeps track of *which* pads are queued/sparse/eos
(rather than simply how many in each category).  As an extra benefit, it is
simpler than the current/old algo.  Will post patch here soon.

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