[Bug 742979] adaptivedemux: Adaptive bitrate algorithm does not react to declining bitrate

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=742979
  GStreamer | gst-plugins-bad | git master

--- Comment #2 from A Ashley <bugzilla at ashley-family.net> 2015-01-19 08:33:52 UTC ---
(In reply to comment #1)
> 
> I don't think the buffer_limit mechanism is needed, when the queues are full,
> then pushing the buffers downstream will block and it should stop downloading
> more than the window. This should already be there?

Good point. You are right, there's no need for adaptivedemux to enforce a
download limit.
> 
> Wouldn't the problem be solved by using the same algo as now, but only relying
> on the average download speed of the last "N" fragments instead of the download
> speed of the entire video?

That would be a good start.

> 
> I'm not sure I understand why you want to compare the download time of the next
> fragment to the amount of data that is actually buffered, do you assume that
> fragments have varying lengths? I would have assume that their lengths are
> quite stable.

The problem that I am trying to avoid is underflow, where the decoder runs out
of data.

For example, if fragments are 3 seconds long and there are 3 seconds of video
waiting to be decoded+displayed, adaptivedemux should not select a
Representation that causes it to spend 6 seconds downloading a 3 second
fragment.

adaptivedemux should be able to react to a pending underflow by selecting a
lower bitrate Representation.

An alternative to using a downstream query would be for adaptivedemux to detect
when it had downloaded a fragment slower than realtime and reacting
appropriately by switching to a lower bitrate Representation for the next
fragment.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.