GNOME Bugzilla – Bug 730192
dashdemux: max-bitrate is not applied
Last modified: 2018-11-03 13:23:25 UTC
Created attachment 276603 [details] [review] Proposed solution max-bitrate paramenter is not used in dashdemux adaptation logic. I think it's supposed to set an upper limit to the estimated channel bitrate used for finding the most appropriate representation during playback. This way dashdemux would never select representations with bitrate higher than "max-bitrate".
Not sure this is correct, the description of that property talks about the decoder bitrate... which is something different than the download bitrate. Thiago, what would be correct here? Also if this should be the download bitrate, the property should be 0 (i.e. unset) by default and called connection-speed. As that's what decodebin expects.
Also, my previous patch would only work if there is both audio+video in a single adaptation set. It would not make sense in case of separate streams for audio and video because the 'connection-speed' limit would apply on each of them indipendently.
I tried to track back where this was used but I couldn't find anything in GStreamer sources, maybe in the original repository but I didn't look there. The thing is: this was never used in the code. I think it was meant to be just like "connection-speed", a cap limit to the to allow only selecting bitrates below the desired level. As said above, the problem with dashdemux (and also mssdemux) is when audio and video are downloaded separately, so you need some strategy to sum the total "connection speed" and decide on how to limit it. Any ideas on how to do it?
Yes. I wrote some code to do this but it's unfinished and therefore also untested. What I did is I tried to calculate the total bandwidth available by summing the bandwidth estimated for each active stream. Then I estimated how much it was bigger compared to the desired "connection-speed" in %. Once i have the % (ranging from 0 to 1) i think i can apply it to each stream indipendently because it's the same as 'bandwidth-usage'. Basically it represents the desired bandwidth-usage calculated comparing how much bandwidth is available against how much the user wants to use. Unfortunately I have no idea when i can finish this atm but i hope to do it.
The spec does not mention anything about that? Maybe order the audio and video bitrates and assign e.g. a percentage to them... and then select the audio with the nearest percentage to that of the video. Or allow 90% of the bitrate for video, and then choose audio for the other 10%
FWIW the current code has: GST_DEBUG_OBJECT (stream->pad, "Trying to change to bitrate: %" G_GUINT64_FORMAT, bitrate); if (active_stream->mimeType == GST_STREAM_VIDEO && demux->max_bitrate) { bitrate = MIN (demux->max_bitrate, bitrate); }
-- 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/147.