GNOME Bugzilla – Bug 696631
hlsdemux: unnecessary switching to lowest bitrate
Last modified: 2014-12-30 19:41:15 UTC
i investigated the phenomenon that hls-demux playback tends to switch to the lowest available bitrate which seemed to happen especially on super fast connections. i observed that this happens in the log before the bitrate switches to the lowest available stream: 0:00:10.514954329 2180 0x87f570 INFO hlsdemux gsthlsdemux.c:1268:gst_hls_demux_get_next_fragment:<hlsdemux0> Fetching next fragment http://***:8080/***/***-1_541759.ts ** (gst-launch-0.10:2180): CRITICAL **: gst_fragment_get_total_size: assertion `GST_IS_FRAGMENT (fragment)' failed 0:00:11.626698109 2180 0x87f570 DEBUG hlsdemux gsthlsdemux.c:1244:gst_hls_demux_switch_playlist: Downloaded 0 bytes in 0:00:01.202326000. Bitrate is : 0 0:00:11.627190331 2180 0x87f570 INFO hlsdemux gsthlsdemux.c:1145:gst_hls_demux_change_playlist:<hlsdemux0> Client was on 2085600bps, max allowed is 0bps, switching to bitrate 985600bps then, it downloads the same fragment index again with the lowest bitrate it turns out that hlsdemux actually starts the download of the fragment too early, before it is actually present on the server, hence the 0 byte size.
Does this still happen with 1.0.6 or git master?
i can't test because i don't have the bandwidth on this machine / no gst 1.x on the other machine. i've observed the "Downloaded 0 bytes" message also on the bip-bop-stream on git master (https://devimages.apple.com.edgekey.net/resources/http-streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8) where every fragment should be available all the time. it's probably something else then!
Do you have another link? That one doesn't seem to work anymore.
https://devimages.apple.com.edgekey.net/streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8
hlsdemux has changed a lot since this report. Can you confirm it still fails with git 1.3?
(In reply to comment #5) > hlsdemux has changed a lot since this report. Can you confirm it still fails > with git 1.3? I meant "git or 1.3"
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!