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 678329 - Setting ring-buffer-max-size on playbin2 degrades playback
Setting ring-buffer-max-size on playbin2 degrades playback
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.36
Other Windows
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-06-18 14:48 UTC by Xavi Artigas
Modified: 2014-11-24 14:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Playback tutorial 3 from the GStreamer SDK (5.15 KB, text/plain)
2012-06-18 14:48 UTC, Xavi Artigas
Details
Media details (1.59 KB, text/plain)
2012-06-19 14:14 UTC, Xavi Artigas
Details

Description Xavi Artigas 2012-06-18 14:48:38 UTC
Created attachment 216682 [details]
Playback tutorial 3 from the GStreamer SDK

When setting the Download flag on playbin2 and limiting the ring-buffer-max-size, playback is interrupted constantly by buffering messages.
The network is fast enough to play flawlessly if ring-buffer-max-size is disabled.
Find attached sample code (taken from docs.gstreamer.com).
Note that the ranges returned by the Buffering Query also look wierd: sometimes the current position is completely outside the dowloaded area.
Comment 1 Sebastian Dröge (slomo) 2012-06-18 14:54:38 UTC
As mentioned on IRC this does happen without limiting the ringbuffer size too... it's just more noticeable with limiting it.
Comment 2 Wim Taymans 2012-06-18 14:59:47 UTC
-  g_object_set (pipeline, "ring-buffer-max-size", (guint64)2000000, NULL);

The ringbuffer max-size is smaller than the buffer size? this is expected then...
Comment 3 Xavi Artigas 2012-06-18 15:11:05 UTC
Well spotted. Setting a bigger ring-buffer-size removes the continuous buffering.
However, two issues remain:
1. The current position still moves outside the downloaded area (BYTES / TIME discrepancies?)
2. When not limiting the ring-buffer-size (and the network is slow), it goes to buffering even when, apparently, there's still downloaded data available (again, this might be a discrepancy between the BYTES format used for the buffering query and the TIME format used for position queries)
Comment 4 Wim Taymans 2012-06-19 13:30:08 UTC
(In reply to comment #3)
> Well spotted. Setting a bigger ring-buffer-size removes the continuous
> buffering.
> However, two issues remain:
> 1. The current position still moves outside the downloaded area (BYTES / TIME
> discrepancies?)

I think so. what format?

> 2. When not limiting the ring-buffer-size (and the network is slow), it goes to
> buffering even when, apparently, there's still downloaded data available
> (again, this might be a discrepancy between the BYTES format used for the
> buffering query and the TIME format used for position queries)

Yes, likely
Comment 5 Xavi Artigas 2012-06-19 13:48:20 UTC
(In reply to comment #4)
> I think so. what format?

I do not understand the question. The buffering query is made in GST_FORMAT_PERCENT and the position/duration query in GST_FORMAT_TIME. The code is attached.
Comment 6 Wim Taymans 2012-06-19 13:57:10 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > I think so. what format?
> 
> I do not understand the question. The buffering query is made in
> GST_FORMAT_PERCENT and the position/duration query in GST_FORMAT_TIME. The code
> is attached.

The container and codec that you used.
Comment 7 Xavi Artigas 2012-06-19 14:14:54 UTC
Created attachment 216752 [details]
Media details
Comment 8 Xavi Artigas 2012-06-19 14:15:31 UTC
The media is a Webm with Vorbis/VP8
Comment 9 Tim-Philipp Müller 2013-02-28 15:30:52 UTC
Does this still happen with 1.x ?

Note that there are known issues with queue2 that are only fixed post-0.10.36 (not even sure all were fixed in 0.10 git).
Comment 10 Tim-Philipp Müller 2014-11-24 14:12:20 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!