GNOME Bugzilla – Bug 730225
hlsdemux switch to higher quality don't connect all pads right
Last modified: 2014-11-08 14:14:40 UTC
Created attachment 276633 [details]
adaptive pipeline wrong pipeline
When hlsdemux switch to higher quality hlsdemux start to download new fragments(new quality) really fast
sources from master
gst-launch-1.0 playbin uri="http://playertest.longtailvideo.com/adaptive/bbbfull/bbbfull.m3u8"
attached file i
Created attachment 276634 [details]
pipeline after quality change 2.
I get 2 different pipeline in some situation
after change of quality
What exactly is the problem you're seeing here? In the first pipeline, decodebin has the second group unconnected inside itself... that looks a bit weird but should be correct. When bitrates are switched in hlsdemux, it will create a new group each time.
In common situation hlsdemux download fragments in speed relative to playback.
When hlsdemux switch to higher(different) quality, it start to download new fragments(from better quality) much faster.
It instantly(as fast as possible) download all fragments in sequence order.
I will attach my patch for resolution limit
And you will see what will happen when you change stream qualities.
But If you have different test tools (traffic shaper,..) you can simulate this scenario.
Created attachment 276961 [details] [review]
gst_m3u8_client_get_playlist support for max video width and height
Created attachment 276962 [details] [review]
select stream quality base on video max resolution
Created attachment 276963 [details] [review]
xvimagesink emit window size change events
I made 3 patches for testing of adaptive streaming
Change window resolution to something higher.
then hlsdemux switch to better fragments, you can observer speed up in fragments download( 10 for example and really fast).
And I hope that you will answer my email about HLS/DASH and RESOLUTION extension
How are these patches related to the original problem reported here?
For the original problem, if hlsdemux downloads all fragments as fast as possible until the end after a bitrate switch, that would be a bug. That would mean that the limits in the multiqueues don't kick in for whatever reason... and you should be able to see that from the debug logs.
problem don't change
But it was really hard to reproduce it without traffic shaper and I don't know how to make unit test for this scenario.
My patch added another dimension(max video resolution) for adaptive scenario.
Change of output window is pretty much same as if you get better bandwidth.
Then you can reproduce my bug report
GST_DEBUG="hlsdemux:5" gst-launch-1.0 playbin uri="http://playertest.longtailvideo.com/adaptive/bbbfull/bbbfull.m3u8" 2>dump.log
dump is in attachments
Created attachment 277008 [details]
The problem of the unlimited queues and downloading as fast as possible is now solved in decodebin. Is there anything left to do here?
I still would like to integrate limiter of MAX RESULUTION
at least some support in code
(In reply to comment #14)
> I still would like to integrate limiter of MAX RESULUTION
> at least some support in code
Could you open a bug specific to this issue so we can track it there? Or any other separate issue that you might have.
Anything else related to this one?
I create this bug as I sow wired pipeline graph
but it looks like it is related to this
but that is separate bug
Should we close this bug then?
yes, you can close it