Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 10 of 19

Hybrid View

  1. #1
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,561

    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,601

    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,561
    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
    Oct 2005
    Location
    Ireland
    Posts
    20,799
    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).

  5. #5
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,799
    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

  6. #6
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,799

    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)

  7. #7
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    7,802
    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

Posting Permissions

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