[Bug 657076] New: [baseaudio/ringbuffer] may fail to provide running clock
bugzilla at gnome.org
Mon Aug 22 06:40:49 PDT 2011
GStreamer | gst-plugins-base | unspecified
Summary: [baseaudio/ringbuffer] may fail to provide running
AssignedTo: gstreamer-bugs at lists.freedesktop.org
ReportedBy: mnauw at users.sourceforge.net
QAContact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Created an attachment (id=194363)
ringbuffer: start ringbuffer if needed upon commit
Consider some clip with very little audio (below a typical ringbuffer size).
In this case, while the ringbuffer is allowed to start upon changing to
PLAYING, it will never really start (since no new segment is needed, so no
wait_segment is called, which otherwise starts ringbuffer).
So, no advancing ringbuffer and no advancing clock, and then nothing much
happens really (no video rendering either etc).
Attached patch arranges to start ringbuffer upon commit. While it may be
marginally less optimal (? in some cases ?) it makes sense to get going when
there is something to do (i.e. data) and really arranges for a running clock
which is often claimed to be provided.
Note this is a sort-of counterpart to a recent fix that had to arrange for
providing a running clock when going to PLAYING (after PAUSED) after EOS.
Both seem to stem from no longer starting the ringbuffer upon PLAYING, but only
allowing it to start, and it leads to wondering if that has provided more
benefit (which ?) than issues ...
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs