GNOME Bugzilla – Bug 747558
gsthlsdemux.c/gstadaptivedemux.c: Possible Improvement: Variant selection doesn't consider hysteresis
Last modified: 2018-11-03 13:33:48 UTC
When the average bitrate is calculated, this resultant bitrate (when multiplied by bitrate_limit) could be very close to a variant in the m3u8 playlist file. Which could result in the variant selection oscillating between two different variants after each segment is downloaded. In any system which make a decision based on an input switching an output based on the inputs magnitude, it is normal to add hysteresis to the calculation as this will prevent random noise from causing instability. The instability in this cause would be the viewer being able to observe frequent changes in variants when playing back video. A hysteresis variable could be added to the final bitrate value used to select the variant from the playlist. This variable is set to -50kbps when changing download a variant and set to 0 when changing up a variant. This would allow for 50kbps of noise in the final bitrate calculation which would not influence the variant selection when the download rate is near constant.
I think this makes sense. Are you considering writing the patch, as well?
I'm looking at patching 1.4.5. I'll attached it to the issue when it's ready.
It will be better if you patch master, 1.4.5 and master have diverted a lot already and we don't add new features to 1.4 branch, only bugfixes are allowed.
Created attachment 303213 [details] [review] Backport of new variant selection algorithm from master to 1.4.5 These patches backport the new algorithm detailed in https://bugzilla.gnome.org/show_bug.cgi?id=742979 to 1.4.5 The next patch is to add Hysteresis is patched onto these changes.
Created attachment 303214 [details] [review] Add hysteresis to variant selection to avoid noise influencing selected variant
I'm revisiting this for master... Our solution is currently specific to hlsdemux, and I'd like to change it so it can be used in adaptivedemux instead of requiring 3 separate implementations. So, I was thinking along the following lines; - Restore the bitrate averaging logic, which was (I think) mistakenly removed as part of https://bugzilla.gnome.org/show_bug.cgi?id=733959 - Apply a noise filter to the resulting bitrate; if the delta between the newly calculated bitrate and the previous is < some threshold (50 kpbs say), then keep the old bitrate. Our previous solution applies hysterisis when a variant change is in the offing due to the new bitrate. This is why it's hls specific. However, simply applying a noise filter should achieve the same thing I believe. Does anyone have any comments on this approach?
-- 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-bad/issues/236.