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 636886 - baseaudiosink: no running clock when eos leads to hang in PLAYING
baseaudiosink: no running clock when eos leads to hang in PLAYING
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 0.10.33
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-12-09 15:57 UTC by Mark Nauwelaerts
Modified: 2011-03-04 13:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test clip to reproduce (613.11 KB, video/quicktime)
2010-12-09 15:57 UTC, Mark Nauwelaerts
  Details
baseaudiosink: start ringbuffer upon going to PLAYING and already EOS (1.79 KB, patch)
2011-03-03 18:19 UTC, Mark Nauwelaerts
none Details | Review
baseaudiosink: start ringbuffer upon going to PLAYING and already EOS (2.99 KB, patch)
2011-03-04 12:29 UTC, Mark Nauwelaerts
committed Details | Review

Description Mark Nauwelaerts 2010-12-09 15:57:45 UTC
Created attachment 176136 [details]
Test clip to reproduce

In particular, that can make things hang when pause/playing when audiosink reached EOS.

For example, consider a mov clip with 8s of audio and 10s of video (evidently, the difference can also be more or less).  If playback is paused after audiosink receives and renders eos, then the ringbuffer is not started upon playing.  As such, there is no advancing clock, and rendering of video will wait indefinitely.

Although gst_base_audio_sink_drain tempers this in general (by delaying eos rendering), it need not handle all cases.  In particular, due to the edit list / segment handling in qtdemux, it may send "unequal segments" to audio and video branches (as opposed to other demuxers, where it is usually the same plain segment).

Not quite sure how to fix.  As the audiosink claims to provide a clock, it should presumably arrange for a running one, e.g. if it has ever seen some data and/or eos.  Or alternatively should not claim to provide a clock when it won't be coming up with a running one.

Attached test clip has characteristics as decribed above and can be used to reproduce (e.g. using the test app in bug #633700).
Comment 1 Sebastian Dröge (slomo) 2010-12-18 13:44:48 UTC
Some time ago I changed baseaudiosink (or was it basesink) to only provide the audio clock in PAUSED/PLAYING and to notify about it not working when going back to READY. IIRC Wim reverted these changes because of performance reasons... but would they help here?
Comment 2 Mark Nauwelaerts 2010-12-20 11:24:00 UTC
Having a really running/advancing clock in PLAYING should handle this (so whatever helps to arrange that ...)
Comment 3 Mark Nauwelaerts 2011-03-03 18:19:24 UTC
Created attachment 182387 [details] [review]
baseaudiosink: start ringbuffer upon going to PLAYING and already EOS

Appears to fix it and also make sense ...
Comment 4 Mark Nauwelaerts 2011-03-04 12:29:13 UTC
Created attachment 182454 [details] [review]
baseaudiosink: start ringbuffer upon going to PLAYING and already EOS

Next version, eliminate some obsoleted stuff as well.
Comment 5 Mark Nauwelaerts 2011-03-04 13:13:48 UTC
commit ba2e500bd992d8ad7db0da923801964964835967
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Thu Mar 3 19:14:38 2011 +0100

    baseaudiosink: start ringbuffer upon going to PLAYING and already EOS
    
    ... otherwise we may end up without running clock in PLAYING.
    
    Fixes #636886.