Add HLS support
This request originates with Forum thread "m3u8 stream will not play", however, there are 2 separate parts to this request and addressed by this patch:
1) Add ability to both read and optionally save playlists in extended m3u format (includes loading & saving of additional metadata). See https://docs.fileformat.com/audio/m3u/
2) Attempt to add ability to play HLS (HTTP Live Streaming) streams. See https://en.wikipedia.org/wiki/HTTP_Live_Streaming
The proposed patch should handle #1 and recognize & enable support for #2 via ffaudio/ffmpeg, which recognizes this format by content. This patch recognizes these as streams and not playlists, resulting in them being added as a single playlist item (which should then be picked up by ffaudio) rather than as a playlist. However, additional work may be needed in the case of Audacious to prevent occasional pcm buffer underruns since these streams are composed of chunks each lasting only a few seconds and each chunk represented by a separate URL. The reason for this playlist-like "chunking" is to enable dymanic ("adaptive") bitrates over varying quality of internet connections. Since ffmpeg supports HLS, I would expect it to be capable of the necessary one+ chunk lookahead buffering necessary to prevent underruns, but ffmpeg with Audacious defaults doesn't seem to always handle it perfectly. I only discovered this issue when converting this patch to Audacious as I am using it w/o this issue (as of recent times / ffmpeg versions) in "some other code" of mine which does some other buffering and separate reader/writer threading stuff needed for video-capability. This is why I'm not submitting this as a standalone pull request, as it will likely require some additional work on your part elsewhere in Audacious (ie. ffaudio?).
HLS is becoming more popular as a streaming format probably due to it's adaptive bitrates and because it originated with Apple.
Test streams: https://ottverse.com/free-hls-m3u8-test-urls/
#1 Updated by John Lindgren over 1 year ago
I added the HLS stream detection. Thanks!
I think the rest of the extended M3U needs more work, since right now the metadata that gets read will be lost as soon as the playlist is refreshed.
(There's not currently a good way to handle metadata that comes from the playlist vs. the song file.)
#2 Updated by Jim Turner over 1 year ago
Thanks! I lightly tested w/the forum poster's stream, and a non-HLS extd-m3u playlist and it seems to work (except for the buffer-underrunning audio-issue I mentioned - NOTE: raising the audio buffering does not seem to affect).
Now, as far as the extended-m3u metadata issue, I had that working in some other code, so I have now merged that here in the attached patch for playlist-data.cc that seems to address the metadata-refresh issue here now too (Note: the playlist metadata tags are overwritten by metadata embedded in the entry IFF the entry has metadata (which is what I would expect to happen, especially if the entry is a streaming station). Please review before closing out this issue!
Also see and close out as dup. my (still open) previous request regarding this issue: Feature #875, which I did not remember until after I filed this one, which also includes now outdated patches similar to these.
#3 Updated by John Lindgren over 1 year ago
- % Done changed from 0 to 100
- Category set to plugins/m3u
- Subject changed from Add extended-M3U playlist & HLS support to Add HLS support
- Affects version 4.2 added
This patch (playlist-data.cc.diff) introduces a new bug: if I edit the tag of a playlist entry and clear e.g. the Title field, then Save, my changes are not reflected in the playlist. The old title is still displayed until I remove and re-add the playlist entry.
My comment from #875 still applies:
We need a way (for example, a flag in the Tuple class) to mark info that came from a playlist (cuesheet or extended M3U) rather than from the audio file itself.
Let's continue the extended M3U discussion under the original ticket (#875). I'll mark this one as complete. Thanks again for the HLS patch.