[Bug 742141] pulsesink: writeable size will increase bigger than total buffer size if no data feed to pulse.

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sun Jan 11 07:47:19 PST 2015


https://bugzilla.gnome.org/show_bug.cgi?id=742141
  GStreamer | gst-plugins-good | 1.4.1

--- Comment #11 from kevin <kevinbing.song at gmail.com> 2015-01-11 15:47:13 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > Audio pipeline and video pipeline can't totally decoupled. Demuxer will be
> > blocked when video pipeline is full of buffers, so audio pipeline will no
> > buffer if pulse buffered all audio data. The reason of pulse buffered all audio
> > data is the writable size is very large.
> 
> Thats why one should place a multiqueue after the demuxer. decodebin/playbin do
> that already. The queues will provide a thread-boundary, that is each stream
> will run in a separate thread.

I know there is multiqueue after demuxer. But the queue will full (10M bytes)
as demuxer will continue push buffer to it. And then video pipeline (from
demuxer video pad to video sink) will full with video buffer, and then demuxer
blocked on video pad push.
Demuxer only has one thread, so demuxer don't push audio buffer until video
pipeline has room to push one video buffer.

-- 
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 mailing list