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 test pipeline gst-launch-1.0 playbin uri="http://playertest.longtailvideo.com/adaptive/bbbfull/bbbfull.m3u8" And sometimes 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 gst-launch-1.0 playbin uri="http://playertest.longtailvideo.com/adaptive/bbbfull/bbbfull.m3u8" 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] log file
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 https://bug730225.bugzilla-attachments.gnome.org/attachment.cgi?id=276961 at least some support in code https://bugzilla.gnome.org/show_bug.cgi?id=730068
(In reply to comment #14) > I still would like to integrate limiter of MAX RESULUTION > https://bug730225.bugzilla-attachments.gnome.org/attachment.cgi?id=276961 > at least some support in code > > https://bugzilla.gnome.org/show_bug.cgi?id=730068 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 https://bugzilla.gnome.org/show_bug.cgi?id=731404 but that is separate bug
Should we close this bug then?
yes, you can close it