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 760822 - audiobasesink: consuming too much data after EOS and seek back to 0
audiobasesink: consuming too much data after EOS and seek back to 0
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.6.1
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-01-19 09:26 UTC by Aleksander Wabik
Modified: 2018-11-03 11:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The fix (519 bytes, patch)
2016-01-19 09:33 UTC, Aleksander Wabik
none Details | Review

Description Aleksander Wabik 2016-01-19 09:26:54 UTC
Reproduction steps:

- have a sink working in a push mode
- play some content till EOS
- after EOS, leave the pipeline in playing state for some time (a minute will do good)
- pause the pipeline,
- flushing seek to 0
- unpause the pipeline

Observed effects (bug):
- the audio sink consumes all data that is provided to it immediately,
- if a queue is put before the sink, it will not fill
- if a queue is put before the *video* sink, and the queue before audio sink, and the application unpauses only when both queues fill, it will never happen.

I will try to write a minimized testcase.

The root cause of the problem seems to be handling of the EOS event in audiobasesink. It calls gst_audio_base_sink_drain(), but does not call gst_audio_ring_buffer_pause(). Adding gst_audio_ring_buffer_pause() fixes the problem.

If the sink works in a pull mode, and gst_pad_pull_range() returns EOS, then the bug should not reproduce - then gst_audio_ring_buffer_pause() is called after draining the sink.
Comment 1 Aleksander Wabik 2016-01-19 09:33:48 UTC
Created attachment 319326 [details] [review]
The fix

I attach the simple fix for this issue. I prefer not to put gst_audio_ring_buffer_pause() in gst_audio_base_sink_drain(), because on 1.4.5, drain is used also when handling GAP, so backporting such a fix would not be a good idea.
Comment 2 Vincent Penquerc'h 2016-02-10 17:21:25 UTC
That seems sensible to me.
Hopefully someone more familiar with basesink can say whether they expect side effects.
Comment 3 Tim-Philipp Müller 2016-02-10 17:44:33 UTC
Maybe you could make a small test program using audiotestsrc ! audiosink ?

I'm not sure if we can pause the ring buffer here, don't we have to keep it running so that the audio clock keeps running in case it's the pipeline clock?
Comment 4 GStreamer system administrator 2018-11-03 11:44:07 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/248.