[Bug 758387] hlsdemux: downloads same fragment of live playlist at different bitrates

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=758387

Thiago Sousa Santos <thiagossantos at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #315955|none                        |reviewed
             status|                            |

--- Comment #5 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
Review of attachment 315955:
 --> (https://bugzilla.gnome.org/review?bug=758387&attachment=315955)

This is a nice idea but how does the application know what are the available
bitrates to make the decision?

It would be better to give the application the measured bitrate as well as a
list of options to select from, with only the bitrate all it can do is just
some window average math or some other heuristic on returning an ideal bitrate
to use. Then adaptive demux would pick the greatest not higher than this limit.
Given a list the applications can actually force some bitrate or have more
information on selecting a bitrate.

Additionally, bonus points for having another signal to allow the application
to select the initial bitrate, but this can be done as a separate work after we
settle on this one.

How to provide the available options? Post a message when parsing the
mpd/playlist/manifest? Pad properties? (Maybe the new stream selection API
already covers providing this list, would be good to check with Edward/bilboed
about it)

::: gst-libs/gst/adaptivedemux/gstadaptivedemux.h
@@ +426,3 @@
+   *
+   * Signal that apps can connect to if they wish to control the
+   * adaptive bitrate control in #GstAdaptiveDemux.

Missing a Since marker, as well as the parameter description have the same
name, looks like one of those should be the return.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.