GNOME Bugzilla – Bug 758916
Use common connection-speed range for all elements
Last modified: 2018-11-03 12:31:02 UTC
Currently there there are differences between elements with connection-speed property. There are three ranges in total, 0 to 2147483 mmssrc/4294967 dashdemux,hlsdemux,mssdemux/18446744073709551. Is there a reason having connection-speed not as guint64? Here are all elements with connection-speed property. dashdemux connection-speed : Network connection speed in kbps (0 = calculate from downloaded fragments) flags: readable, writable Unsigned Integer. Range: 0 - 4294967 Default: 0 decodebin connection-speed : Network connection speed in kbps (0 = unknown) flags: readable, writable Unsigned Integer64. Range: 0 - 18446744073709551 Default: 0 hlsdemux connection-speed : Network connection speed in kbps (0 = calculate from downloaded fragments) flags: readable, writable Unsigned Integer. Range: 0 - 4294967 Default: 0 mmssrc connection-speed : Network connection speed in kbps (0 = unknown) flags: readable, writable Unsigned Integer64. Range: 0 - 2147483 Default: 0 mssdemux connection-speed : Network connection speed in kbps (0 = calculate from downloaded fragments) flags: readable, writable Unsigned Integer. Range: 0 - 4294967 Default: 0 playbin connection-speed : Network connection speed in kbps (0 = unknown) flags: readable, writable Unsigned Integer64. Range: 0 - 18446744073709551 Default: 0 rtspsrc connection-speed : Network connection speed in kbps (0 = unknown) flags: readable, writable Unsigned Integer64. Range: 0 - 18446744073709551 Default: 0 uridecodebin connection-speed : Network connection speed in kbps (0 = unknown) flags: readable, writable Unsigned Integer64. Range: 0 - 18446744073709551 Default: 0
Probably just historical reasons. All of those should have G_MAXUINT/G_MAXUINT64 as maximum value. Not sure if it's a good idea to change the type to uint64, that means an ABI break that will cause crashes with older applications that expect the type to be an uint. I'm rather wondering whether this property should just be removed from the adaptive streaming demuxers. I suspect it will usually do more harm than good.
The connection-speed property on the ABR elements is used to provide download bitrate instead of the download rate calculation logic. I was a bit surprised when I first saw this, as I thought it would instead be taken as a hint, and used e.g. to select the initial variant based upon past performance, giving a much better startup experience. I really don't see the point in the current use of the property for ABR elements, but using it as a hint would be handy I think.
At this time this value is very useful for media with m3u8 playlist. If we use with playbin connection-speed=4294967 the max connection speed for hls: It will select the chunk into playlist.m3u8 for the best resolution. Then we have at once a good image with good resolution. Some playlist.m3u8 are even not working very well whitout this setting.
-- 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/142.