GNOME Bugzilla – Bug 780559
HLS m3u8 / decodebin fails on custom playlist
Last modified: 2017-03-27 02:06:20 UTC
Created attachment 348736 [details] Twitch HLS playlist I could not track down which component actually fails here. I'm trying to playback a HLS stream with gst-play-1.0. This is a playlist from Twitch.tv. You need an application token and use their API to get the playlist - which is only valid for a certain amount of time which makes it a little inconvenient. However gst-play-1.0 fails very quickly with the following error: $ gst-play-1.0 broken.m3u8 [..] WARNING No decoder available for type 'text/uri-list'. WARNING debug information: gsturidecodebin.c(938): void unknown_type_cb(GstElement *, GstPad *, GstCaps *, GstURIDecodeBin *) (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0 ERROR Your GStreamer installation is missing a plug-in. for file:///Users/fzwoch/code/broken.m3u8 ERROR debug information: gsturidecodebin.c(1005): void no_more_pads_full(GstElement *, gboolean, GstURIDecodeBin *) (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0: no suitable plugins found: gstdecodebin2.c(4600): gboolean gst_decode_bin_expose(GstDecodeBin *) (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0: no suitable plugins found: Missing decoder: text/uri-list (text/uri-list) Reached end of play list. I noticed that in the playlist file one of the first entries is a custom #EXT-X-TWITCH-INFO line. I tried removing that line and the HLS stream played just fine. The attached playlist probably won't work anymore due to the session expired - but can be still value for testing as gst-play-1.0 at least tries to play the modified playlistthe stream does not error out immediately. Do I need special handling for this type of playlist or is this a bug?
Created attachment 348737 [details] [review] typefind: Expand the search range for HLS detection HLS files can have arbitrary extra tags in them, and those can be quite long lines. We need to search further than 256 bytes sometimes just to get past the first few lines of the file.
The 2nd line in the file, the #EXT-X-TWITCH-INFO line is 380 bytes long, and so our typefind function never detects this as an HLS file - because it's only checking the first 256 bytes arbitrarily. Here's a PoC fix. A better one might be to rewrite that typefind function to check (for example) the first 5 or so *lines* in the input for known HLS tags. Since the typefind function short-circuits if the file doesn't start with #EXTM3U, it should still quite quickly fail on other inputs.
Thanks, the POC fix works for GStreamer 1.10.4. (I haven't had a test setup for 1.11.x up and running). The stream now runs just fine.
Created attachment 348761 [details] [review] typefind: Expand the search range for HLS detection HLS files can have arbitrary extra tags in them, and those can be quite long lines. We need to search further than 256 bytes sometimes just to get past the first few lines of the file. Make the limit 4KB, which matches a typical input block size and should hopefully cover every crazy input.
Thanks. I've pushed that to both 1.11 and 1.10. If someone wants to improve it in the future, they can - but since it short circuits quickly on any input that doesn't start with #EXTM3U I think it's OK to continue being a bit inefficient. I expanded the search limit to 4KB which is hopefully enough for any future crazy input.