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 712782 - Require a feature to display buffered status when using push source
Require a feature to display buffered status when using push source
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
unspecified
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-11-21 03:59 UTC by Justin Kim
Modified: 2014-11-07 05:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
expose read-position as a property (1.80 KB, patch)
2013-11-21 04:38 UTC, Justin Kim
rejected Details | Review

Description Justin Kim 2013-11-21 03:59:12 UTC
The original question was about how to display buffer status. 

http://lists.freedesktop.org/archives/gstreamer-devel/2013-September/042771.html

Then, firstly, I suggested a proposal to accumulate all bytes inside of each element by a certain query. 

http://lists.freedesktop.org/archives/gstreamer-devel/2013-November/043983.html

After prototyping, I found my first suggestion was wrong because it would make big burden to each element.



Finally, I found if the upper layer of gstreamer pipeline has content-length, read-position, and average bitrate, it can estimate the buffer status during playing time. To get these information, it is only required to expose internal monitoring data in case of souphttpsrc. 

QUERY_POSITION is about current playing, read-position is about a position where it downloads. If src provides its read-position, the upper layer can display how much buffer is fulled like youtube player does.

I know more general approach would be better, but I found that other cases like mms  doesn't have similar internal data. It means that it's hard to pursue general way in this step.
Comment 1 Olivier Crête 2013-11-21 04:16:17 UTC
You're probably looking for the Buffering or the buffering_range queries?
Comment 2 Justin Kim 2013-11-21 04:38:56 UTC
Created attachment 260406 [details] [review]
expose read-position as a property
Comment 3 Justin Kim 2013-11-21 04:40:17 UTC
Oops, is it already done?
Comment 4 Justin Kim 2013-11-21 13:03:52 UTC
When I saw Olivier's comment, I was little confused. But my view is slightly different from QUERY_BUFFERING's.

If I am wrong, please correct me.

As I know,  Queue2  element can make response about QUERY_BUFFERING, and it set  data based on itself internal data. 

However, if source element handles or has a kind of buffer inside, this data from Q2 is not fit for displaying buffer status because Q2's data would be in the middle of actual buffered size.
In this reason, I think the read position from source element will be more accurate. In fact, when I implemented the buffered status based on this position property, it was acceptable and I could see the progress bar like youtube's.
Comment 5 Sebastian Dröge (slomo) 2013-11-25 12:44:40 UTC
Comment on attachment 260406 [details] [review]
expose read-position as a property

You can just do a POSITION query on souphttpsrc instead to get this data.

But as Olivier said, you probably want the other data from the buffering query.


Also taking the difference between read position in the source and position in the sink will not work in general. It's very unlikely that you can know both in the same format.