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 548394 - basesink should ignore EOS during flushing
basesink should ignore EOS during flushing
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.10.21
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-08-19 07:54 UTC by Jason Zhao
Modified: 2008-08-19 08:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gstbasesink.c patch (965 bytes, patch)
2008-08-19 07:59 UTC, Jason Zhao
committed Details | Review

Description Jason Zhao 2008-08-19 07:54:21 UTC
When pipeline playback is near the end, basesink is pending on gst_base_sink_wait_eos. At that time, if users do seek, basesink will received Flush_start and Flush_stop event, at Flush_start event handler, it will clear all eos flags and unblock waiting eos. But at gst_base_sink_render_object(), after it unblocked from bclass->event(), it will still set eos as TRUE, that will cause pipeline can not work well, even new data coming, it will be dropped.

So add checking for flushing, if is flushing, ignore this EOS.

Changed files:
gstbasesink.c

Motorola would like to contribute Gstreamer patch to the Gstreamer open source
community project. Please find attached the patch applicable for Gstreamer. For
any questions, please feel free to contact (Zhao Liang "e3423c@motorola.com",
Shi Ling "w20230@motorola.com").
Comment 1 Jason Zhao 2008-08-19 07:59:45 UTC
Created attachment 116935 [details] [review]
gstbasesink.c patch
Comment 2 Wim Taymans 2008-08-19 08:54:43 UTC
Thanks, I slightly modified the patch to drop _all_ events in this case since it is possible that the segment event also causes a release of the PREROLL_LOCK.

Ideally, the subclass doing the _wait_eos() call should have returned FALSE from the event handler if after releasing the PREROLL_LOCK the sink is flushing.

        Based on patch by: Jason Zhao <e3423c at motorola dot com>

        * libs/gst/base/gstbasesink.c: (gst_base_sink_render_object):
        When the subclass event handler releases the PREROLL_LOCK, we could be
        in the flushing state and we have to ignore the event. Fixes #548394.