[gstreamer-bugs] [Bug 374682] [PATCH] collectpads should only consider linked pads to prevent blocking

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=374682

  GStreamer | gstreamer (core) | Ver: 0.10.10





------- Comment #3 from Mark Nauwelaerts  2006-11-13 15:57 UTC -------
(In reply to comment #2)
> I doubt this is a good idea.  It looks like this would break dynamic
> (re)linking of pipelines.  You assume that unlinking a pad is a bad thing
> because it would cause the streaming to block.  You cannot know whether this is
> the case however.  I can unlink a pad and link it again (to some other pad)
> immediately (while the pad is blocked of course).  This would not pose any form
> of harmful delay for the  user of CollectPads.

Agreed there is no harm if unlinking and then followed again by linking;
there is however blocking (harm?) if not followed by linking (see below).

> If I understand you correctly, you propose to make CollectPads detect the
> unlink and exclude the pad from the collection.  It is clear to see how this is
> not what is generally wanted.  It would break dynamic linking performed on the
> source pads of all muxers and cause slightly different semantics in the case of
> e.g. adder.

It would be (temporarily) excluded from the collection and considered again
after linking.  Indeed, with this patch, there would be different semantics on
dynamically unlinked *sink*pads (I suppose?); i.e. they would be (temporarily)
auto-skipped (and e.g. adder would probably consider it EOS). The current
auto-blocking behaviour may be 'simulated' by blocking peers of sinkpads  when
performing such link-switch.
Anyway, this is admittedly convoluted and not so elegant, and not my desire
either; my concern however is elsewhere (see below).

> Can you name a specific situation where the current behaviour causes problems?

I have no specific situation, but would occur e.g. when unlinking a pad from
videomixer (if the stream in question no longer needs mixing in), and not
linking to another pad.

In short, the 'safety' (against blocking; with indeed other effects) this patch
tries to bring would probably not be needed *if*:
- (permanently) unlinking a (typically request) pad would be consistently
followed by releasing this request pad
- muxing elements would properly cater for this by implementing releasing a
request pad, i.e. implement a release_pad function.  If a muxer does not to
this; then gstreamer core (in gst_element_release_request_pad) will just fall
back to removing the pad from the element, and this pad would still be in the
collectpads collection (but no longer in the element!) --> blocking, which is
then known for sure not to be the intention or a good thing

It can indeed be argued that neither of the above is really responsibility of
the core (and am as such hardly adamant about this patch), but a matter of
'proper programming', either in the applications or in the plugins.  So,
abiding by those rules above, the current behaviour would cause no problems. 
It would also at least require patches as in e.g. #374479 and #374658 (and
possibly more?) to bring a few plugins up to specs/rules.

I hope this explains some concerns a bit better.
[maybe core could somehow act differently in gst_element_release_request_pad
and/or the need for release_pad should be emphasized more to CollectPads
users?]


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email