GNOME Bugzilla – Bug 679850
Add function to pretty-print durations
Last modified: 2018-11-03 12:15:40 UTC
Something similar to: http://git.gnome.org/browse/totem/tree/src/gst/totem-time-helpers.c#n33 We would also want to be able to force showing the hour item, if the corresponding item has an hour field. eg., progress as I've just started watching a film: 00:00:15/1:25:00 And usefully, print time left: 00:00:15 [===============] -1:24:45 API bikeshedding appreciated.
Hrm, gst_clock_time_format() ? :D (kidding, I think)
Simillar code in buzztard http://buzztard.git.sourceforge.net/git/gitweb.cgi?p=buzztard/buzztard;a=blob;f=src/ui/edit/main-statusbar.c#l91 Although this is not what I spend most of the time on.
Lack of context. 5 year old bug report. Closing.
(In reply to Edward Hervey from comment #3) > Lack of context. Not sure what the "lack of context" was here. It's used in totem's UI, would probably be useful in other situations.
Why a GStreamer API ? Can't GDateTime be used ?
(In reply to Nicolas Dufresne (stormer) from comment #5) > Why a GStreamer API ? Because the way the values are presented and formatted are very idiomatic of media players. > Can't GDateTime be used ? GDateTime isn't for durations, it's for dates and times.
gst_strdup_printf("%" GST_TIME_FORMAT, GST_TIME_ARGS(time)) maybe? What kind of "configuration" would you want for the output? (The Rust ClockTime "pretty-printer" allows to configure the number of sub-second digits but nothing else, would that be what you need? Also omitting seconds, minutes?)
(In reply to Sebastian Dröge (slomo) from comment #7) > gst_strdup_printf("%" GST_TIME_FORMAT, GST_TIME_ARGS(time)) maybe? What kind > of "configuration" would you want for the output? (The Rust ClockTime > "pretty-printer" allows to configure the number of sub-second digits but > nothing else, would that be what you need? Also omitting seconds, minutes?) For totem, it would be: - being able to show the elapsed time as well as the remaining time - omitting (days?) hours, minutes if not present in either elapsed or remaining (eg. a 1h30 minutes film would always show the hours in both strings) - i18n I don't need sub-second precision in the UI, but the code should make sure to take fractional seconds into account when showing both elapsed and remaining.
(In reply to Bastien Nocera from comment #8) > For totem, it would be: > - being able to show the elapsed time as well as the remaining time How would that work API-wise? You can calculate the remaining time yourself from the duration and the position, both of which have queries. > - omitting (days?) hours, minutes if not present in either elapsed or > remaining (eg. a 1h30 minutes film would always show the hours in both > strings) > - i18n This all sounds to me like something that should be in totem instead, or in some GNOME/GTK media widget library.
(In reply to Sebastian Dröge (slomo) from comment #9) > (In reply to Bastien Nocera from comment #8) > > > For totem, it would be: > > - being able to show the elapsed time as well as the remaining time > > How would that work API-wise? You can calculate the remaining time yourself > from the duration and the position, both of which have queries. > > > - omitting (days?) hours, minutes if not present in either elapsed or > > remaining (eg. a 1h30 minutes film would always show the hours in both > > strings) > > - i18n > > This all sounds to me like something that should be in totem instead, or in > some GNOME/GTK media widget library. It's already in totem. It's also in buzztard. It would probably be in nearly every app that ends up using GstPlayer. The goal here was to make it easier for apps, sharing code. If that's not wanted, then please close the bug saying so. Comment 5 said "not enough context" even though there was context in the first few comments.
Yes, I think it's clear what this is about. Someone just has to sit down and think of an API.
-- 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/gstreamer/issues/26.