Hello Torben,
Any chance of HLS/HTTP audio streaming for version 6?
For what I see at this point only ICEcast and SHOUTcast are supported in the encoder.
Info on Apple HLS: https://developer.apple.com/streaming/
Thank you.
Hi Joris,
actually Shoutcast and Icecast are http Streaming Server and I don’t have any Problem with playback in pure html5 Audio on any mobile device (apple or others) or even just link to the stream address. I use them for mp3 and aac+ Streaming and both work like a charm.
As far as I know HLS is only used for Video Streaming and since mAirList is no Video Playout/ Streaming, there is no Need for HLS Support.
I use Icecast for http Audio Streaming and NGINX for HLS Streaming but the Input for NGINX is OBS not mAirList, as I want to have Video with it. The downside of HLS is, that you a quit a bit of latancy, like 30 seconds, while the pure http stream on Icecast is almost realtime.
Best Regards
Malte
[quote=“shorty.xs, post:2, topic:11056”]Hi Joris,
actually Shoutcast and Icecast are http Streaming Server and I don’t have any Problem with playback in pure html5 Audio on any mobile device (apple or others) or even just link to the stream address. I use them for mp3 and aac+ Streaming and both work like a charm.
As far as I know HLS is only used for Video Streaming and since mAirList is no Video Playout/ Streaming, there is no Need for HLS Support.
I use Icecast for http Audio Streaming and NGINX for HLS Streaming but the Input for NGINX is OBS not mAirList, as I want to have Video with it. The downside of HLS is, that you a quit a bit of latancy, like 30 seconds, while the pure http stream on Icecast is almost realtime.
Best Regards
Malte[/quote]
Hi Malte,
Thanks for the reply. HLS multi-bitrate streaming can also be used for audio-only streaming.
The big downside of ICEcast or SHOUTcast is the fact that it can only be one fixed bitrate at a time. So if a listener has got an bad connection, the stream will be buffering a lot…
[quote=“joris22, post:3, topic:11056”]Thanks for the reply. HLS multi-bitrate streaming can also be used for audio-only streaming.
The big downside of ICEcast or SHOUTcast is the fact that it can only be one fixed bitrate at a time. So if a listener has got an bad connection, the stream will be buffering a lot…[/quote]
Yes you need to handle different bitrates through different Mount Points on Icecast. You can handle this by browser and OS detection in your webplayer. That is what I will do shortly. All mobile devices will get the 32k AAC+ stream, it can pass EDGE bandwidht easy and the Audio Quality is still good enough for These small Speakers or cheap headphones they are used with.
But I think bandwidth on Audio only streams, today is your smallest Problem. Up to now I have the 192k mp3 stream running even for mobile devices, except they use tuneIn.
Don’t have any complain from users. Roaming from one mobile base to another is always an issue and not related to bandwidth. Same as switching the modes from EDGE to 4G and vice versa.
Never the less it should be possible to grab your HQ Audio Stream pass it through ffmpeg for transcoding to various bitrates and feed it back to nginx as a HLS stream. As you would do with a Video Stream, any other streamserver like wowza or what ever supports Adaptive HLS Streaming should work in a similar way.
Here is an Icecast/ Nginx/ ffmpeg example.
http://code.steadman.io/blog/using-nginx-icecast-and-mpc-to-create-a-cross-platform-radio-station/
Combining it with this Tutorial for adaptive Video Streaming, it should pretty much do what you want.
https://licson.net/post/setting-up-adaptive-streaming-with-nginx/
Even though I still think it doesn’t make sense.
Is there any Palyer available that can handle adaptive Streaming for Audio only? Never stumbled upon one yet.
[quote=“shorty.xs, post:4, topic:11056”][quote=“joris22, post:3, topic:11056”]Thanks for the reply. HLS multi-bitrate streaming can also be used for audio-only streaming.
The big downside of ICEcast or SHOUTcast is the fact that it can only be one fixed bitrate at a time. So if a listener has got an bad connection, the stream will be buffering a lot…[/quote]
Yes you need to handle different bitrates through different Mount Points on Icecast. You can handle this by browser and OS detection in your webplayer. That is what I will do shortly. All mobile devices will get the 32k AAC+ stream, it can pass EDGE bandwidht easy and the Audio Quality is still good enough for These small Speakers or cheap headphones they are used with.
But I think bandwidth on Audio only streams, today is your smallest Problem. Up to now I have the 192k mp3 stream running even for mobile devices, except they use tuneIn.
Don’t have any complain from users. Roaming from one mobile base to another is always an issue and not related to bandwidth. Same as switching the modes from EDGE to 4G and vice versa.
Never the less it should be possible to grab your HQ Audio Stream pass it through ffmpeg for transcoding to various bitrates and feed it back to nginx as a HLS stream. As you would do with a Video Stream, any other streamserver like wowza or what ever supports Adaptive HLS Streaming should work in a similar way.
Here is an Icecast/ Nginx/ ffmpeg example.
http://code.steadman.io/blog/using-nginx-icecast-and-mpc-to-create-a-cross-platform-radio-station/
Combining it with this Tutorial for adaptive Video Streaming, it should pretty much do what you want.
https://licson.net/post/setting-up-adaptive-streaming-with-nginx/
Even though I still think it doesn’t make sense.
Is there any Palyer available that can handle adaptive Streaming for Audio only? Never stumbled upon one yet.[/quote]
Thanks again for you reply! I will definitely look into the links you provided.
I am aware of the fact that bandwidth shouldn’t be a big issue. But, I think HLS is a very nice method. Even for audio only streams.
JW Player for example has got an HLS audio only feature: https://support.jwplayer.com/customer/portal/articles/1430255-audio-only-streaming
This piece of software does what I want to achieve. But it will be very nice if mAirlist supports it directly…
Well in general I prefer to have things like transcoding, located somewhere in a datacenter, as close as possible to the distribution server.
This is the reason why I use Liquidsoap for transcoding our mobile stream, just as an example.
But I’m also aware that I sometimes do things totally different than usual or most other do it.
I just got in mind, that there was another thread discussing the use of ffmpeg as an encoder option, I guess it was for mAirList 6. If Torben goes into that, maybe it is possible to use ffmpegs command line options to directly stream from there instead of piping Audio back. In this case it could be possible to source your multiple bitrate HLS stream, if you know the command lines paramters to use on ffmpeg.
EDIT: Sorry, I mixed that up. The Topic was not about ffmpeg, but FDKAAC. https://www.mairlist.com/forum/index.php/topic,9100.msg60333.html#msg60333
If you can find a binary (ffmpeg or whatever) that accepts raw PCM data via stdin, and then handles the HLS streaming part on its own, it should be possible to use that with mAirList via the “record to file” interface and a custom format. (mAirList will think you are writing to a file, but doesn’t actually care if it’s streamed instead.)
Hi Torben
Please advise advice how we can use mAirlist for adaptive HLS/DASH for audio streaming.
Thanks
If u are using a Streamserver, look at AzuraCast.
It includes Liquidsoap and provides HLS-Streaming.
Its not nessesary to implate HLS on mAirList. Its easier to manage the HLS Technologie by the Streamserver at the real Endpoint of each listener.
Thanks TomJumbo83.
Might use OBS and send an SRT stream to server