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 797081 - audioaggregator: Output buffer size should be configurable as fraction
audioaggregator: Output buffer size should be configurable as fraction
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-09-05 10:19 UTC by Sebastian Dröge (slomo)
Modified: 2018-11-03 12:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Dröge (slomo) 2018-09-05 10:19:13 UTC
Similar to how it works in audiobuffersplit, with compensation for rounding errors. This would allow us to output e.g. 30000/1001 audio buffers per second and have them the same size as the video without first going through audiobuffersplit.


Problem is that the property is currently in nanoseconds. We could add a new one and make the old one deprecated, and return rounded nanoseconds from it when reading the old property.

Thoughts?
Comment 1 Nicolas Dufresne (ndufresne) 2018-09-05 12:40:17 UTC
I don't agree with the deprecation part. In my use case, I configure the audio source buffer-time (ms) to match the aggregator buffer duration (ns). Fractions just makes things more complicated for me.
Comment 2 Olivier Crête 2018-09-05 14:08:56 UTC
And 33366667 ns is not good enough?
Comment 3 Sebastian Dröge (slomo) 2018-09-05 14:46:07 UTC
(In reply to Olivier Crête from comment #2)
> And 33366667 ns is not good enough?

No as that will slowly drift. Assuming 48000 kHz and 30000/1001 buffers per second, you need to produce some buffers with 1602 and some with 1601 samples.

(In reply to Nicolas Dufresne (ndufresne) from comment #1)
> I don't agree with the deprecation part. In my use case, I configure the
> audio source buffer-time (ms) to match the aggregator buffer duration (ns).
> Fractions just makes things more complicated for me.

I guess we can leave it around, it's indeed more convenient for some cases.
Comment 4 Tim-Philipp Müller 2018-09-05 14:58:06 UTC
Would it make sense to try and deduct a fraction from the GstClockTime value? We do that for framerates somewhere I think?
Comment 5 Sebastian Dröge (slomo) 2018-09-05 15:35:19 UTC
I'd prefer adding a new property as otherwise it's just guesswork
Comment 6 Nicolas Dufresne (ndufresne) 2018-09-05 15:47:40 UTC
On my side, my objection was strictly on deprecation, or deprecation warning. We should ensure we have really good documentation if we have two properties doing the same thing, but differently.
Comment 7 GStreamer system administrator 2018-11-03 12:09:57 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/483.