Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 2 12 LastLast
Results 1 to 10 of 19
  1. #1
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,640

    HLS, DASH, MPD and LMS future version

    Something I was wondering after the extensions I proposed for HTTP streaming: the community has done a good job keeping LMS up-to-date with evolving online streaming services and somewhat associated protocols: HTTPS is the new HTTP, mp4/aac is the new mp3, we have added ogg, opus, ogg/flac.

    I know that @bpa you have created the playHLS plugin and I think I've understood you're working to update it for recent LMS versions. I was wondering if we should not integrate that directly as a new set of ProtocolHandlers, core tor LMS, so that it becomes "natural" for future plugins to depend on these and the work would be much simplified as the main task would then be to search and set the link to the hls, dash, mpd source (sorry I'm mixing a bit different things here I know) rather than re-inventing the wheel or relying on the user to install playHLS.
    LMS 8.2 on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  2. #2
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,629

    HLS, DASH, MPD and LMS future version

    Ahhh.... another hot topic I personally was happy somebody else took
    care of :-).

    But as much as I tried to avoid it (lack of understanding and time to
    learn to understand) I think this would indeed be a great addition.

    Now... just to show how ignorant I was: today I looked into PlayHLS for
    the first time. And I was surprised that it did NOT use ffmpeg. I always
    thought that's what it did...

    So my first question would be: would it make sense to use ffmpeg to
    simplify the LMS side of things? It's a monster, and it might require a
    lot of tweaking to make it a lean and clean addition. But would it
    simplify things? With multi-core becoming the norm having a helper do
    the heavy lifting instead of massaging it in to LMS might be a
    reasonable approach?

  3. #3
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,640
    Quote Originally Posted by mherger View Post
    Ahhh.... another hot topic I personally was happy somebody else took
    care of :-).

    But as much as I tried to avoid it (lack of understanding and time to
    learn to understand) I think this would indeed be a great addition.

    Now... just to show how ignorant I was: today I looked into PlayHLS for
    the first time. And I was surprised that it did NOT use ffmpeg. I always
    thought that's what it did...

    So my first question would be: would it make sense to use ffmpeg to
    simplify the LMS side of things? It's a monster, and it might require a
    lot of tweaking to make it a lean and clean addition. But would it
    simplify things? With multi-core becoming the norm having a helper do
    the heavy lifting instead of massaging it in to LMS might be a
    reasonable approach?
    Yes, that's a good question. My concern would be to make it work for all the divers platforms, although it's true that ffmpeg is very much multi-platform. My approach with mp4/aac was to make it fully internal to LMS as you know, now I'm not sure it's scalable and more CPU efficient. Between @bpa and myself, I think we have a lot of the hls/dash/mpd/mpeg-ts and mp4/aac/adts unwrapping code but the approach is absolutely up for debate.
    LMS 8.2 on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  4. #4
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    8,005
    Quote Originally Posted by mherger View Post
    Ahhh.... another hot topic I personally was happy somebody else took
    care of :-).

    But as much as I tried to avoid it (lack of understanding and time to
    learn to understand) I think this would indeed be a great addition.

    Now... just to show how ignorant I was: today I looked into PlayHLS for
    the first time. And I was surprised that it did NOT use ffmpeg. I always
    thought that's what it did...

    So my first question would be: would it make sense to use ffmpeg to
    simplify the LMS side of things? It's a monster, and it might require a
    lot of tweaking to make it a lean and clean addition. But would it
    simplify things? With multi-core becoming the norm having a helper do
    the heavy lifting instead of massaging it in to LMS might be a
    reasonable approach?
    I think the earlier PlayHLS plugin used ffmpeg while the new improved PlayHLS V2 does not.

    Sent from my Pixel 3a using Tapatalk

  5. #5
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,870
    Lots of points brought up in the post and may need separate posts to isolate the key points. It'll be a bit of brain dump so some time to write - I'll post later this evening.

    First current status.

    There are two version of PlayHLS V1.* and V2.*.

    PlayHLS V1.* uses ffmpeg and so can handle most HLS streams. It is in stadard 3rd party repo.
    PlayHLS V2.* is an allPerl LMS implementation. To get V2 need to add private repo.

    The V1 solution was quick and dirty and a fallback for stream V2 cannot handle.
    The V2 can only handle HLS V3 playlist and cannot handle fMPEG4 stream (i.e. support PackedMP3, PackedAAC, MPEG2-ts MP3, AAC but not AC3)

    The V1 solution require ffmpeg (right build with right options) for the platform and outputs Flac/PCM/MP3. So greater load on server and network. No metadata - cover images, artist, track data.
    The V2 solution all Perl in LMS. No unnecessary transcoding of MP3 or AAC - passed straight to player. Metadata support with proprietary extension (e.g. iHeart radio covert art and track details)

    I have nearly completed a V3 of PlayHLS which support fMPEG4 and HLS V7 variants. To test I am scouring internet for streams with "interesting" interpretations of HLS as it is a not a proper standard.
    I have recently come across some issues in LMS which made me wonder about whether changes to LMS are needed or rewrite (again) part of PlayHLS.
    For example, m3u8 playlist for mixcloud video podcast of say 3 hours long typically has 2 lines per 6 sec segment which means about 1800 lines of text so playlist can be big 80k is frequent. Because these m3u8playlist can be very big - server often gzip them LMS currently has a limit of playlist of 128k and does not support gzipped playlist (i.e plugin has a hack to unzip).

  6. #6
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,870
    For context re PlayHLS V3.

    PlayHLS V3 support HLS V7 server which has variant. The plugin tries to select the best variant for SB player (i.e. 2 channel audio). If this is a MPEG-4 stream with two track video & audio - the plugin will play the audio track.

    This is relevant to stream such as https://live.rte.ie/live/a/channel3/news.isml/news.m3u8 which is a video channel but has an audio only variant so network load can be minimised.

    Mixloud live streams as HLS / fMPEg4 - so audio has to be played but not video.

    A stream such below is very awkward as it has multiple languages (en, fr, de,es) and stereo / surround option but no way to identify how many channels until audio sample are examined (i.e should all tracks be opened/fetched and tested to find 2 channel one)
    https://bitdash-a.akamaihd.net/conte.../playlist.m3u8

    HLS implementation is also a bit of the "wild west". This Brazilian stream plays OK on all HLS players (e.g. ffplay) but it does not obey HTTP header Content-Length (i.e HLS m3u8 playlist is cut off by LMS). It used to play on LMS 7.9.2 but not now - I don't know whether stream has changed or LMS.
    http://1192747t.ha.azioncdn.net/prim.../playlist.m3u8
    Last edited by bpa; 2021-05-02 at 06:51. Reason: mixcloud typo

  7. #7
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,870

    HLS & DASH Technical background.

    This is just background maybe useful in discussion.

    Technical Summary
    HLS is closer in function to HTTP in that it can carry many formats. Currently LMS support HTTP/AAC, HTTP/MP3, HTTP/Streaming MPEG4, HTTP/OGG-Flac etc. HLS supports MP3, AAC, AC3 and MPEG4 but in other carrier formats Packed-MP3, Packed-AAC, MPEG2-TS for MP3, AAC and AC3 and fMPEG-4 (fragmented MPEG-4 like used in DASH). HLS MPEG2 stream can also have video track (typically DVB-S or DVB-T in origin) but use is small.

    DASH & HLS are chunked HTTP which uses lots of HTTP GET of small "files" typically 3-10 secs duration. Technically have the capability to change bit rate of the stream dynamically to cope with network load (i.e. no "buffering" messages but poorer quality as seen in streaming Video services). Client selects most appropriate services (e.g. bit rate, number of channels) to playback. The client are supposed to report some network stats back to server while playing. They have support for ads to be inserted into the stream.

    DASH is an ISO standard (with ETSI ) so it is committee run and seems to evolve slowly. It has lots of support docs and reference client implementations. MPD is the top level file of DASH which has list all the "Representations" (i.e. different bitrates) available for the same service. The naming of each segment to be fetched is generated by a formula. Live streams are called "dynamic". I think metadata is mainly in MPEG-4 segments but have little experiences of DASH streams except for BBC. DASH MIME type is application/dash+xml

    HLS is Apple proprietary which is mirrored in a IETF RFC draft standard. It evolves at the speed of Apple to suit Apple. No open reference client implementation so many "poor" server implementations. Many servers are HLS V2 or V3 but newer ones are V7. HLS has M3U8 playlists but they can be Master Playlist and Media Playlists with same syntax but distinguished by content. A HLS stream can be played using either a Master or Media playlist. Master Playlist has "Variants" which functionally are the same as DASH "Representations - each variant will result in one Media Playlist URL. The naming of the segments is detailed in the M3U8 Media Playlist which is either read once for non-live programs so Media Playlist file can be very big. Live HLS stream require the M3U8 Media Playlist to be read repeatedly at about 3xsegment duration intervals to find new segment to play. HLS can support AAC and MP3 metadata in the format of IDV3.2 tags as well as tagging each segment in Media Playlist. Metadata often breaks the Apple standard with proprietary formats (i.e. iHeart streams). Official HLS MIME type is application/vnd.apple.mpegurl but sometime badly setup stream use the suffix m3u8 and MIME type audio/mpegurl or audio/x-mpegurl which means it is ambiguous with normal m3u playlist.

    Why use Chunked HTTP & Which format is most popular

    Chunked HTTP is more efficient for service provider (especially when served through a CDN) - bandwidth can be managed and better support for commercial issues such as ad insertions and time synchronisation. Better user experiences - fewer "rebuffering" events replaced by poorer quality.

    HLS has most services as it has been incrementally developed and pushed by Apple. Older HTTP/AAC & HTTP/MP3 services easily migrated to HLS with either packed or MPEG2 formats (possibly adapted from DAB/DVB sources). No change in backend. Apple promotes HLS and as Apple is a big content provider, HLS is a near prerequisite to maintain listenership. DASH is available for most browsers but not sure about media players.

    With HLS V7 and the support of fMPEG4. Server implementation can generate the same set of source files for both HLS and DASH. Whether HLS or DASH is used has little technical difficulty for new content providers (i.e. MPEG4 - no history or MP3 or AAC) in particular video - HLS seems to be playing catch up to support fMPEG4 which was already defined for DASH. Choice of HLS or DASH may depend on commercial terms and also listenership (i.e. what does their favorite media player support)

  8. #8
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,870
    On the general point should HLS & DASH be part of LMS ? I think HLS & DASH usage will increase and so HLS/DASH should become part of "standard" LMS. availability of HLS stream now appear often (e.g. radio France, iHeart, mixcloud) and can have advantages than usual MP3/AAC alternatives - better quality, metadata. Standard HLS also enables Tune-in search to return HLS streams as part of search.

    The followup questions are then: (i) How should it be implemented and (ii) when.

    How to implement
    HLS and DASH could be implemented as plugins which are part of standard LMS like Extensions or InternetRadio but which are not in core LMS. Using standard APIs, the plugins will have own ProtocolHandler, ScanUrl and ScanStreaming etc. routines and provide metadata.

    If the HLS / DASH support was part of core LMS I expect there could be code sharing on the MPEG-4. Beyond that, I haven't thought about putting all of HLS into core LMS and what advantages/simplifications could arise (e.g. would mixcloud be simpler if PlayHLS is a plugin or core LMS ?). As chunked HTTP is different to current streaming: lots of small GETs - many requests/responses vs. one Get - one request & one response. I think the LMS core changes would need to evolve in the same way the 8.* changes for MPEG4 took a few iterations to get the "right" API but I don't have any feel for what is the right API.

    Current plugin implementation of MPEG2-ts is bad (first attempt - didn't really "get" MPEG2-ts). It needs to be rewritten - however it works and is adequate.

    Why delay HLS as part of LMS core
    HLS implementions are inconsistent - many are good but not all. Metadata have custom formats, Master playlist have errors in variants Bandwidth and Codecs so choice of variant to be used can be wrong. Audio channel (e.g 1, 2, 5.1) often not clear/defined. Many HLS players examine audio data from all variants and check the stream before deciding which variant to play. Some HLS services have MIME type for m3u and not m3u8 and vice versa

    There are HLS features which are starting to be used and the current plugin ignores them quietly - not sure if they have to implemented properly.
    Some HLS stream have indicated time stamps for live streams, discontinuity etc. - my plugin ignores these at the moment but may be important (e.g. resync a news feed with a time clock).
    There can be many Representation / Variants of the same streams (e.g. stereo/surround, language, quality, audio only) - should "best match" be chosen or present a playlist of all the options.
    With many new HLS/DASH "audio" services there is video content. No proper experience of playing just audio from these tracks so not sure of there are potential issues.

    Summary
    Answering the questions asked in the first post.

    Being pragmatic I think PlayHLS V3 (after more testing and initially some small LMS changes such as playlist gzip support) could/should becomes a standard part of LMS. HLS included as standard plugin would simplify some users options (e.g radio France) and Tune-in returning HLS stations as part of the standard search.

    For problem streams (e..g. AC3), users could still override by a PlayHLS V1 with ffmpeg.

    I'm not sure of the shortcomings of an LMS standard PlayHLS plugin vs LMS core code. I worry that HLS has a lot of legacy streams which have proprietary tweaks (e.g iHeart). Supporting these tweaks as part of core LMS seems odd but support is necessary for good user experience. I feel a plugin would be easier to incrementally (or experimentally) add functionality without altering core LMS. I'd hope these legacy stream could become more standard over time.

    A similar PlayDASH plugin would also be relatively easy to develop although at the moment it hasn't the same urgency as HLS.

    The plugin approach buys time to consider whether & how best to add chunked HTTP support to LMS core. More users of HLS will show up what's needed / wrong with plugin implementation.

  9. #9
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,870
    Sorry for the dump of posts but HLS has been in my head for the last month or two and it'll be gone once I stop working on the plugin.

  10. #10
    Senior Member
    Join Date
    May 2009
    Location
    Clacton-on-Sea, Essex. UK
    Posts
    680

    HLS v2 preventing Spotty playlists from being found

    This may or may not be relevant/useful! I'm running the latest version of Windows 10 with all current updates and the latest LMS nightly 8.2. Have only ever been able to get PlayHLS v2.7 even though there's a v2.8 available somewhere (maybe Linux only?). With PlayHLS v2.7 Spotify playlists are not found and scanning generally appears curtailed. I haven't investigated, it was just easier and quicker to uninstall PlayHLS and rescan. Over time I have made several attempts to use PlayHLS v2.7, originally with LMS 7.9 and with new Windows 10 installs so this for me is a longstanding problem. I haven't investigated any further because I'm not sure how relevant HLS is for me but it appears there is something interfering with LMS scan.
    2 x Touch
    2 x Radio
    2 x Boom
    1 x Intel-NUC server/squeezelite running LMS 8.20 (from nightlies) on Windows 10
    1 X Odroid-XU4 server/squeezelite running LMS 7.91 on Ubuntu 16.04
    1 x iMac server running macOS Big Sur
    WaveIO USB into Lavry DA-10 DAC
    Starfish Pre-amp : Based on NAIM NAC 72
    Heavily modified NAIM NAP 250 Power-amp
    Focal Electra 1027 Be II Speakers

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •