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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #6 from A Ashley <bugzilla at ashley-family.net> ---
(In reply to Thiago Sousa Santos from comment #5)
> Review of attachment 315955 [details] [review]:
> 
> This is a nice idea but how does the application know what are the available
> bitrates to make the decision?
> 

Yes, that would be an improvement.

GstAdaptiveDemux is already posting "adaptive-streaming-statistics" messages.
It could post a message every time a manifest is successfully parsed. Currently
GstAdaptiveDemux does not have visibility of any of the information about the
available representations. Either each demux element would be required to
implement sending this message, or a new API would be required to allow
GstAdaptiveDemux to query the representations that are available in the demux
element.

Doing it in each element seems to go against DRY, but has the advantage that
each demux could provide additional format-specific information.

> 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.
> 

I am wondering if it might be better to have the signal handler to be passed an
identifier of the current representation, rather than the bitrate of the
current representation.

That, coupled with a message describing the available representations, should
allow for the case you describe, without having to enumerate all
representations in every call to the signal handler.

> 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.
> 

Yes, that should be fairly easy to do. Might even be able to use the same
signal.

> 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)
> 
Is there a BZ ticket for that?

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