[Bug 721395] GstCollectPads-related freeze in pads mgmt

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Feb 10 06:18:34 PST 2014


https://bugzilla.gnome.org/show_bug.cgi?id=721395
  GStreamer | gstreamer (core) | git

Thiago Sousa Santos <thiago.sousa.santos> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thiago.sousa.santos at collabo
                   |                            |ra.co.uk

--- Comment #3 from Thiago Sousa Santos <thiago.sousa.santos at collabora.co.uk> 2014-02-10 14:18:28 UTC ---
Muxers usually use GstCollectPads to manage their pads. GstCollectPads waits
for buffers on all pads to be able to compare the timestamps available and
deliver the buffers in timestamp order. So simply unlinking/removing a pad that
was pushing to the muxer will make GstCollectPads block waiting for data on
that pad.

If you:
a) Remove the sinkpad: it should work as collect pads should not consider that
pad anymore and will continue operating. If this doesn't work, there might be a
bug.

b) Don't remove: collect pads will keep waiting for buffers on that pad and the
muxer will stall

c) Don't remove and link something else: In theory it should work, but then how
does the new timestamps compare to the ones from the previous input? I wouldn't
recommend this unless you know what you are doing.


It seems that your test app has a flag for doing either 'a' or 'b', and the
results seem to be correct?

You also mention that you are trying to do 'c', what is the use case?

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