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 652404 - multifdsink: buffers-queued calculation is wrong in pipeline with both audio and video
multifdsink: buffers-queued calculation is wrong in pipeline with both audio ...
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.34
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-06-12 18:00 UTC by Nicola
Modified: 2011-06-30 16:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Nicola 2011-06-12 18:00:04 UTC 
In a pipeline with both audio and video such as

video ! queue mux. ! audio ! queue ! mux. muxer name=mux ! multifdsink

the calculation the buffers-queued property quickly change from 1 to say 65, 97 and so on while the difference between bytes-to-serve and bytes-served remain constant so the client is actually consuming the whole stream.

In a video only pipeline the property works correctly
Comment 1 David Schleef 2011-06-30 06:23:30 UTC 
This sounds completely normal.  buffers-queued has no relation to bytes-to-serve or bytes-served.  What exactly is the problem?
Comment 2 Nicola 2011-06-30 12:15:18 UTC 
David, maybe I'm misunderstanding the buffers-queued usage. I think if buffers-queued return 20 mean that one of the client connected to multifdsink has 20 buffers not yet consumed/received. This seems to be true for a video only pipeline, if i add the audio i see buffers-queued return for example 97 but the client is receiving audio/video in real time so it is consuming all the buffers and buffers-queued should be 1,

I hope my explanation is clear enough, sorry for my english
Comment 3 David Schleef 2011-06-30 16:46:06 UTC 
(In reply to comment #2)
> David, maybe I'm misunderstanding the buffers-queued usage. I think if
> buffers-queued return 20 mean that one of the client connected to multifdsink
> has 20 buffers not yet consumed/received.

No, this is not correct.  buffers-queued is the number of buffers queued in the multifdsink based on the various timing configuration.  It has nothing to do with clients, other than that a late client may cause this to be momentarily higher than without.