GNOME Bugzilla – Bug 700487
[dashdemux]: Getting max-buffering-time property returns incorrect value and modifies property value.
Last modified: 2013-07-11 14:49:29 UTC
In the dashdemux, the max-buffering-time property is intended to be in seconds, but the code returns the stored value (which has been multipled by GST_SECOND), generating an absurd return value when inspected. Worse, every time the value is retrieved, it is multiplied by GST_SECOND again. How to reproduce: Run gst-inspect dashdemux. Observe value much larger than DEFAULT_MAX_BUFFERING_TIME A short patch to remedy this issue is attached.
Created attachment 244471 [details] [review] It appears I failed on this attachment as well. Remedy that.
Bump.
Comment on attachment 244471 [details] [review] It appears I failed on this attachment as well. Remedy that. Thanks for the fix, pushed.
commit 3d50af3e4bf1165be7201cb145b94fa908adc009 Author: Arthur Shipkowski <art@videon-central.com> Date: Mon May 6 16:56:01 2013 -0400 dashdemux: Fix issue with get returning a value for max-buffering-time It was not properly divided by GST_SECONDS. Also fix issue with max-buffering-time being multiplied by GST_SECONDS every time the property is retrieved. https://bugzilla.gnome.org/show_bug.cgi?id=700487
Out of curiosity - is there a reason "max-buffering-time" is in full seconds? If not, maybe it should be milliseconds, so that one can also specify 2.5s or so?
I don't know. I agree that it should use a better granularity. Also, the property seems unused in the code. It is in -bad, so we can still change that, right?
(In reply to comment #6) > Also, the property seems unused in the code. It is in -bad, so we can still > change that, right? Actually, my fix for https://bugzilla.gnome.org/show_bug.cgi?id=701404 adds the code to use this property.