After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 574160 - collectpads does not reliably eos when last pad is removed
collectpads does not reliably eos when last pad is removed
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.10.23
Assigned To: Stefan Sauer (gstreamer, gtkdoc dev)
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-04 19:19 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2009-03-05 11:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
this reliably goes to eos for me (7.76 KB, text/x-csrc)
2009-03-04 19:20 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
  Details
this does not eos (8.04 KB, text/x-csrc)
2009-03-04 19:21 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
  Details
update status, when removing pads (1.37 KB, patch)
2009-03-04 19:24 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
rejected Details | Review

Description Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-04 19:19:06 UTC
The title says it all. Two examples + tentative patch follows.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-04 19:20:00 UTC
Created attachment 130052 [details]
this reliably goes to eos for me
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-04 19:21:28 UTC
Created attachment 130053 [details]
this does not eos

GST_DEBUG="*:2,collectpads:5,adder:5" ./sprinkle3

...
0:00:04.244315597 17235  0x804c008 DEBUG                adder gstadder.c:819:gst_adder_release_pad:<adder> release pad adder:sink19
0:00:04.244330961 17235  0x804c008 DEBUG          collectpads gstcollectpads.c:372:gst_collect_pads_remove_pad: removing pad adder:sink19
0:00:04.244344649 17235  0x804c008 DEBUG          collectpads gstcollectpads.c:383:gst_collect_pads_remove_pad: found pad adder:sink19 at 0x8224c80
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-04 19:24:46 UTC
Created attachment 130054 [details] [review]
update status, when removing pads
Comment 4 Wim Taymans 2009-03-05 11:45:04 UTC
I don't think we should automatically EOS collectpads when all pads are removed because it might be possible that you request a new pad later and simply continue pushing data. We should not make this use case impossible.

There is a hidden feature in sprinkle.c that your other examples (sprinkle2.c by accident, though..) failed to capture: when shutting down the source element, it will push out an EOS event, which makes adder push EOS when needed. I've updated the docs in the code to make this more clear.

sprinkle2.c fails to perform the state change of the source and the effect correctly. State changes should always be done from sink to source. Failure to do so might cause a deadlock. In this case it does not cause a deadlock but since the source is shut down before the effect, the EOS event manages to reach the adder sinkpad, making it EOS eventually. If you make it correct and change the state of the effect before the source, sprinkle2 also fails to EOS.

sprinkle3 uses a bin that contains the effect and the source. In this case the bin will do the correct state change order and the effect is the same as sprinkle2.

The right solution in all cases is to always send EOS to the adder sinkpad before releasing it.

I've commited fixed versions with added comments to git.

commit 44574b0ca64be7f28084f5a63cc3d198a7d357c2
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Thu Mar 5 12:43:02 2009 +0100

    examples: add some more sprinkle examples
    
    Add some more sprinle examples and add some more comments.
    See #574160.