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 709867 - streamsplitter: Keep still meaningfull pending events on FLUSH_STOP
streamsplitter: Keep still meaningfull pending events on FLUSH_STOP
Status: RESOLVED DUPLICATE of bug 709868
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-10-10 21:51 UTC by Thibault Saunier
Modified: 2013-10-14 22:03 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
streamcombiner: Keep still meaningfull pending events on FLUSH_STOP (2.37 KB, patch)
2013-10-10 21:51 UTC, Thibault Saunier 		none Details | Review
streamsplitter: Keep still meaningfull pending events on FLUSH_STOP (2.37 KB, patch)
2013-10-10 23:00 UTC, Thibault Saunier 		accepted-commit_now Details | Review

Description Thibault Saunier 2013-10-10 21:51:16 UTC 
Only EOS and segment should be deleted in that case.
Comment 1 Thibault Saunier 2013-10-10 21:51:18 UTC 
Created attachment 256953 [details] [review]
streamcombiner: Keep still meaningfull pending events on FLUSH_STOP
Comment 2 Thibault Saunier 2013-10-10 23:00:01 UTC 
Created attachment 256959 [details] [review]
streamsplitter: Keep still meaningfull pending events on FLUSH_STOP

Only EOS and segment should be deleted in that case.
Comment 3 Sebastian Dröge (slomo) 2013-10-14 20:08:05 UTC 
Comment on attachment 256959 [details] [review]
streamsplitter: Keep still meaningfull pending events on FLUSH_STOP

Alternatively you could just store all other events on the srcpads and free the list.
Comment 4 Thibault Saunier 2013-10-14 20:13:21 UTC 
What would be the advantage of that approach?
Comment 5 Sebastian Dröge (slomo) 2013-10-14 20:15:27 UTC 
You don't have to worry about the list anymore and don't (potentially) send multiple sticky events of the same type after flushing
Comment 6 Sebastian Dröge (slomo) 2013-10-14 20:19:37 UTC 
Also it makes sure that you don't break event ordering. Now you remove the segment. event, and there might be tag events afterwards. So you would now in the future send tag events first from the list, and then a segment event.
Comment 7 Thibault Saunier 2013-10-14 20:28:01 UTC 
I think I did not understand what you have in mind there.
Comment 8 Thibault Saunier 2013-10-14 22:03:16 UTC 

*** This bug has been marked as a duplicate of bug 709868 ***