GNOME Bugzilla – Bug 745905
hlsdemux: General Stream error due to bitrate change before last segment
Last modified: 2015-03-27 20:39:18 UTC
In some hls playlists, when a bitrate change happens right before the last segment, general stream error is triggered instead of EOS. This seems to be a race condition and doesn't happen all the time. And, it is especially prominent if the last segment has a duration that is quite small for example in the order of 10s of milli seconds.
Here is the link to the truncated logs - https://www.dropbox.com/s/tjg5jyol4muxlyw/truncated_log1.txt.tar.bz2?dl=0
Did you try with git master? I have the impression this has already been fixed in master. As you pointed out, rhe problem is that hlsdemux decides to switch pads *after* the last segment, so it switches pads just to push EOS on that pad and that leads to an error. Please try with latest master to confirm this has already been fixed.
Hi Thiago, I checked out master and there has been a ton of changes . Do you know which patch in master would fix this issue? I am using a slightly older version of hlsdemux which doesn't have the adaptive demux base class... Thanks
It's not a few patches you can cherry-pick, please could you test master as is? As you say, there have been many changes, many of which are related or dependent on other changes.
I tested with master and I see the same error. gst-play-1.0 http://redacted_url.m3u8 Now playing http://redacted_url.m3u8 0:00:02.634374000 4184 0x7f910a844850 ERROR default audio-info.c:277:gboolean gst_audio_info_from_caps(GstAudioInfo *, const GstCaps *): no rate property given 0:00:00.0 / 0:00:30.1 0:00:04.007687000 4184 0x7f910b8a6400 ERROR default audio-info.c:277:gboolean gst_audio_info_from_caps(GstAudioInfo *, const GstCaps *): no rate property given 0:00:04.9 / 0:00:30.1 0:00:14.569775000 4184 0x7f910a94f2d0 ERROR default audio-info.c:277:gboolean gst_audio_info_from_caps(GstAudioInfo *, const GstCaps *): no rate property given 0:00:14.9 / 0:00:30.1 0:00:22.448887000 4184 0x7f910bb6b230 ERROR default audio-info.c:277:gboolean gst_audio_info_from_caps(GstAudioInfo *, const GstCaps *): no rate property given 0:00:19.9 / 0:00:30.1 0:00:31.723933000 4184 0x7f910d00ab70 ERROR default audio-info.c:277:gboolean gst_audio_info_from_caps(GstAudioInfo *, const GstCaps *): no rate property given 0:00:29.8 / 0:00:30.1 ERROR GStreamer encountered a general stream error. for http://redacted_url.m3u8 ERROR debug information: gstdecodebin2.c(4331): gboolean gst_decode_bin_expose(GstDecodeBin *) (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0: all streams without buffers Reached end of play list. I am on Mac OSX Yosemite. Do you need me to turn on specific logs to look at?
GST_DEBUG=6 please
Here you go... https://www.dropbox.com/s/uvwr7l937qfqchx/general_stream_error_master_full_redacted.txt.tar.bz2?dl=0
Can you confirm whether 'http://redacted_url/4200k_1920x1080_h264_4200_aac_128_6.ts' should be the last fragment on the stream or is there a next one?
Created attachment 300415 [details] [review] adaptivedemux: do not try to advance fragment if there is none Can you try this patch for gst-plugins-bad to confirm it fixes your issue, please?
The patch is for git master.
Yeah. I can confirm that _6.ts is the last segment in all of the variant playlists. I will try the patch and get back to you shortly. Thanks for your help.
Hi Thiago. That patch works great with master. Without the patch, I got the error reported 25% of the time. With the patch, I never got the error reported. I tried numerous times (30-40) to confirm this since this is a race condition and not always reproducible. Now, I need to port this back to 1.4.0 for my purposes. I will ping you if I get stuck. Any pointers appreciated. Thanks -Vijay
Fixed. commit 66b01c9a0c8a9d6b5eff7199042fbdf8b5cf523c Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Fri Mar 27 00:27:34 2015 -0300 adaptivedemux: do not try to advance fragment if there is none It might return OK from subclasses and it could cause a bitrate renegotiation. For DASH and MSS that is ok as they won't expose new pads as part of this but it can cause issues for HLS as it will expose new pads, leading to pads that will only have EOS that cause decodebin to fail https://bugzilla.gnome.org/show_bug.cgi?id=745905 master and 1.4 have diverged a lot in the DASH/HLS/MSS support. I'd recommend using the master version of those if possible. You can find the patches in master with something like git log 1.4.0..master gst-libs/gst/adaptivedemux ext/dash/ ext/hls ext/smoothstreaming If you want to merge it all. If you just need this fix the rationale is to only attempt to do a bitrate switch if there is really another segment to be used.
Okay. Thanks for the tip on extracting the patches for those plugins. I do want to move to master but I can't do it right away. I will try to follow your logic and see if I can fix it on 1.4.0 as well.