Do you have an uri to share so we can test ? Or the m3u8 file ?

Or alternatively backtraces without optimizations, or you'll have to debug yourself first why those string functions are crashing (which of the pointers is wrong, and why).

the problem does not happen anymore so I cannot reproduce now, I'll have to wait for few days ... it happens periodically

I have no control on the server, anyway when this edge case happen then GStreamer crashs every few minutes so basically is unable to play the hls stream while ffmpeg and flowplayer work. 

Probably the m3u8 file is corrupted and other players redownload it, I remember some 404 and consecutive m3u8 download in the browser developer console.

For your info GStreamer has more delay than flowplayer and ffmpeg too: the server store 2 segments, I suppose GStreamer starts to play from the first one, in ffmpeg you can set live_start_index to start from the last one, this help a lot if hls is a "live" streaming

it probably happens because sometime the m3u8 is a binary file,

for example

curl "<url to m3u8>"

returns
 
Warning: Binary output can mess up your terminal. Use "--output -" to tell 
Warning: curl to output it to your terminal anyway, or consider "--output 
Warning: <FILE>" to save to a file.

this is obvious a server error, but if you try to download the m3u8 again after few milliseconds it works as expected.

Another strage behaviour of this broken server:

it returns something like this as m3u8

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=420000
live2_lq/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=670000
live2_mq/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1100000
live2_hq/index.m3u8

sometime the links to live2_lq/index.m3u8 and live2_mq/index.m3u8 return 404 http error while the hq link is ok

It's not calling into the binary case. gst_hls_src_buf_to_utf8_playlist() runs g_utf8_validate() which would detect this case.

After that, we clearly have gone passed g_str_has_prefix (data, "#EXTM3U")) and g_strrstr (data, "\n#EXT-X-STREAM-INF:") validation, so the file is probably not that corrupted.

So I can only blame the hand written parser that follow this code. If you manage to reproduce, got to frame 6, and and print "data". Attach the output here. We can then plug that data into our unit test and easily reproduce (and fix) that bug.

For the refefence:
 gdb) f 6
 gdb) printf "%s",data

Another note, at the line of the crash, gst_uri_is_valid() returns success, so the data does looks like a valid URI. The code also thinks we have a relative URI. As we crash in malloc, the size passed to malloc should be traced. It also possible that it's some other memory corruption that lead to that ...

here is another crash with hopefully the needed info

+ Trace 238685

g(gdb) printf "%x",field
e0ba0450(gdb)

f 16

+ Trace 238686

It's starting to look bad, the only thing these two have in common is malloc. Looks like memory corruption. We need to produce in valgrind (or similar) to figure out.

Sorry I gave up, I switched to ffmpeg this weekend and now I use GStreamer only for audio and video sinks,

I'll try to find some spare time to provide the needed info but it is quite difficult since the stream is available only during working hours and most of the time hlsdemux hangs (see #797101) so it is a very time consuming task.

As soon as I have some spare time I would like to summarize the steps and the workarounds needed to correctly handle this hls "live" stream in my ffmpeg + gst app, maybe this will help to improve the hls support in GStreamer

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/780.