What is the reason for hls? #172

Closed
opened 2026-04-24 23:00:03 +02:00 by adam · 9 comments
Owner

Originally created by @JKamsker on GitHub (Jan 10, 2022).

I am experimenting a bit with my audiobooks and a simple website containing just an tag and found out, that chrome on my pc and mobile are perfectly capable of streaming my audiobooks as they are, without any fancy hls encoding.

They are even able to stream currently required parts and scrubbing through the audio is also pretty smooth.
While scrubbing, the browser produces requests containing Range: bytes=nstart- headers

My question is: Why do we need hls encoding? Can we have an option(like on youtube: original, hq, lq) to just use the original files, when we know that the user device is capable enougth to stream the files?

What i found out about hls:
Pro: It could reduce file size. That reduces transport cost & helps the device actually playing the audio.
Con: Streams need way longer than necessary to start playing and i (like most i think), only use abs in my local network, where i have got gigabit networking.

Even if you were to be connected via cell, an audiobook that's 1Gb in size with 24h playtime, could load 1h worth of data within seconds (42mb)

In addition, conversion seems to be a little bit too buggy at the moment to actually use the feature. (Playing one stream and switching to another causes the webclient to crash/not playing audio)

Originally created by @JKamsker on GitHub (Jan 10, 2022). I am experimenting a bit with my audiobooks and a simple website containing just an <audio> tag and found out, that chrome on my pc and mobile are perfectly capable of streaming my audiobooks as they are, without any fancy hls encoding. They are even able to stream currently required parts and scrubbing through the audio is also pretty smooth. While scrubbing, the browser produces requests containing ``Range: bytes=nstart-`` headers My question is: Why do we need hls encoding? Can we have an option(like on youtube: original, hq, lq) to just use the original files, when we know that the user device is capable enougth to stream the files? What i found out about hls: **Pro:** It could reduce file size. That reduces transport cost & helps the device actually playing the audio. **Con:** Streams need way longer than necessary to start playing and i (like most i think), only use abs in my local network, where i have got gigabit networking. <br/> Even if you were to be connected via cell, an audiobook that's 1Gb in size with 24h playtime, could load 1h worth of data within seconds (42mb)<br/> In addition, conversion seems to be a little bit too buggy at the moment to actually use the feature. (Playing one stream and switching to another causes the webclient to crash/not playing audio)
adam closed this issue 2026-04-24 23:00:03 +02:00
Author
Owner

@advplyr commented on GitHub (Jan 10, 2022):

I think direct streaming if available is something that should be built.
Converting every audiobook to HLS was an easy way to get started, and it worked so well that I haven't felt the need to iterate on it yet. It is also necessary because you can't direct stream every audio file on every device. There are alternatives, but I find HLS easiest to work with and universally supported.

The start time for audio-only HLS transcode is fast. For me a 1GB audiobook takes about 3s to start playing. The transcode could take a minute or two to finish, but you only need a few segments to start playing.

A direct stream would still need to run an FFmpeg command if the audiobook was made up of multiple files. If an audiobook was 20 mp3's then you would concatenate them. Did you have another idea on how to direct stream multiple files?
An audiobook that is a single audio file wouldn't require anything extra.

In addition, conversion seems to be a little bit too buggy at the moment to actually use the feature. (Playing one stream and switching to another causes the webclient to crash/not playing audio)

I'm not sure what you mean here, I haven't experienced this bug. Can you provide more details?

@advplyr commented on GitHub (Jan 10, 2022): I think direct streaming if available is something that should be built. Converting every audiobook to HLS was an easy way to get started, and it worked so well that I haven't felt the need to iterate on it yet. It is also necessary because you can't direct stream every audio file on every device. There are alternatives, but I find HLS easiest to work with and universally supported. The start time for audio-only HLS transcode is fast. For me a 1GB audiobook takes about 3s to start playing. The transcode could take a minute or two to finish, but you only need a few segments to start playing. A direct stream would still need to run an FFmpeg command if the audiobook was made up of multiple files. If an audiobook was 20 mp3's then you would concatenate them. Did you have another idea on how to direct stream multiple files? An audiobook that is a single audio file wouldn't require anything extra. > In addition, conversion seems to be a little bit too buggy at the moment to actually use the feature. (Playing one stream and switching to another causes the webclient to crash/not playing audio) I'm not sure what you mean here, I haven't experienced this bug. Can you provide more details?
Author
Owner

@mx03 commented on GitHub (Jan 10, 2022):

In addition, conversion seems to be a little bit too buggy at the moment to actually use the feature. (Playing one stream and switching to another causes the webclient to crash/not playing audio)

Had the same problem serveral times. Currently i dont have 2 audiobooks i hear, but next time i make an issue.

A direct stream would still need to run an FFmpeg command if the audiobook was made up of multiple files. If an audiobook was 20 mp3's then you would concatenate them. Did you have another idea on how to direct stream multiple files?

JS Player with playlist logic. I would prefer that too, but the current solution with hls is easier to start with, like you said.

One big problem with direct streaming without hls, if you have a audiobook in one file with chapters, it trys to download the hole file even if you play only 20 minutes (with a 2gb audiobook not so great, at least if its not the intranet).
Thats the default behavior, alternative buffering the data itself would solve that problem, but then buffer seeking must developed.

@mx03 commented on GitHub (Jan 10, 2022): > In addition, conversion seems to be a little bit too buggy at the moment to actually use the feature. (Playing one stream and switching to another causes the webclient to crash/not playing audio) Had the same problem serveral times. Currently i dont have 2 audiobooks i hear, but next time i make an issue. > A direct stream would still need to run an FFmpeg command if the audiobook was made up of multiple files. If an audiobook was 20 mp3's then you would concatenate them. Did you have another idea on how to direct stream multiple files? JS Player with playlist logic. I would prefer that too, but the current solution with hls is easier to start with, like you said. One big problem with direct streaming without hls, if you have a audiobook in one file with chapters, it trys to download the hole file even if you play only 20 minutes (with a 2gb audiobook not so great, at least if its not the intranet). Thats the default <audio src="streamurl"> behavior, alternative buffering the data itself would solve that problem, but then buffer seeking must developed.
Author
Owner

@JKamsker commented on GitHub (Jan 11, 2022):

because you can't direct stream every audio file on every device.

Id use the plain file where possible and only fall back to hls if necessary. Hopefully its detectable if a player can play the files or not.
Pseudo logic:

if(canPlay(raw_music)){
 play(raw_music)
}else{
 play(Convert(raw_music))
}

My NAS, where abs runs, isn't exactly what one would call powerful or optimized for audio processing.
My phone or pc are way better suited for smth like that.

For me a 1GB audiobook takes about 3s to start playing.

3s is subjective. Atleast for me it was haha. Felt like an eternity while testing haha
Thing is, it loads and just doesn't stop loading when running into said bug.
You wouldn't notice it until you look at the developer shell.

Did you have another idea on how to direct stream multiple files?

Metadata + some playlist logic in js maybe? Working on a PoC, dunno if i can make it (not experienced in js)
Should be rather simple. The tricky thing would be to preload some of the upcoming tracks in advance

One big problem with direct streaming without hls, if you have a audiobook in one file with chapters, it trys to download the hole file even if you play only 20 minutes (with a 2gb audiobook not so great, at least if its not the intranet).

Can't confirm. The default player only loads what it needs. Im using the plain default nginx server in docker. Its fast and it supports ranging.
image
image

I'm not sure what you mean here, I haven't experienced this bug. Can you provide more details?

I will open another issue

@JKamsker commented on GitHub (Jan 11, 2022): > because you can't direct stream every audio file on every device. Id use the plain file where possible and only fall back to hls if necessary. Hopefully its detectable if a player can play the files or not. Pseudo logic: ``` if(canPlay(raw_music)){ play(raw_music) }else{ play(Convert(raw_music)) } ``` My NAS, where abs runs, isn't exactly what one would call powerful or optimized for audio processing. My phone or pc are way better suited for smth like that. > For me a 1GB audiobook takes about 3s to start playing. 3s is subjective. Atleast for me it was haha. Felt like an eternity while testing haha Thing is, it loads and just doesn't stop loading when running into said bug. You wouldn't notice it until you look at the developer shell. > Did you have another idea on how to direct stream multiple files? Metadata + some playlist logic in js maybe? Working on a PoC, dunno if i can make it (not experienced in js) Should be rather simple. The tricky thing would be to preload some of the upcoming tracks in advance > One big problem with direct streaming without hls, if you have a audiobook in one file with chapters, it trys to download the hole file even if you play only 20 minutes (with a 2gb audiobook not so great, at least if its not the intranet). Can't confirm. The default player only loads what it needs. Im using the plain default nginx server in docker. Its fast and it supports ranging. ![image](https://user-images.githubusercontent.com/11245306/148854113-c5e6ee03-490d-45cc-a60c-9a728527a155.png) ![image](https://user-images.githubusercontent.com/11245306/148854158-a57c8935-037f-4103-9666-a0a13a56a3de.png) > I'm not sure what you mean here, I haven't experienced this bug. Can you provide more details? I will open another issue
Author
Owner

@mx03 commented on GitHub (Jan 11, 2022):

If you have a 1gb Audiofile with default audio tag and you start playing it downloads the whole file and don't stop if it's 30minutes ahead.
The seeking with content range is no problem nowadays.

@mx03 commented on GitHub (Jan 11, 2022): If you have a 1gb Audiofile with default audio tag and you start playing it downloads the whole file and don't stop if it's 30minutes ahead. The seeking with content range is no problem nowadays.
Author
Owner

@JKamsker commented on GitHub (Jan 11, 2022):

What do you mean with default audio tag?
It works for me with m4a, m4b and mp3 files

@JKamsker commented on GitHub (Jan 11, 2022): What do you mean with default audio tag? It works for me with m4a, m4b and mp3 files
Author
Owner

@mx03 commented on GitHub (Jan 11, 2022):

Oh yes you're right i had this problem one or two years ago that it prefetch the whole file, but seems its fine now.

@mx03 commented on GitHub (Jan 11, 2022): Oh yes you're right i had this problem one or two years ago that it prefetch the whole file, but seems its fine now.
Author
Owner

@JKamsker commented on GitHub (Jan 11, 2022):

Oh cool! Maybe this case could be detected beforehand?

@JKamsker commented on GitHub (Jan 11, 2022): Oh cool! Maybe this case could be detected beforehand?
Author
Owner

@advplyr commented on GitHub (Mar 6, 2022):

In v1.7.2 with experimental features on the web app will direct play audiobooks.
If direct play fails it should gracefully fall back to hls stream. So far my tests are working well, next it will be moved to the mobile app.

@advplyr commented on GitHub (Mar 6, 2022): In [v1.7.2](https://github.com/advplyr/audiobookshelf/releases/tag/v1.7.2) with experimental features on the web app will direct play audiobooks. If direct play fails it should gracefully fall back to hls stream. So far my tests are working well, next it will be moved to the mobile app.
Author
Owner

@advplyr commented on GitHub (Apr 24, 2022):

Direct play is now fully supported in the web app and the android app.
Will soon be implemented for iOS.

@advplyr commented on GitHub (Apr 24, 2022): Direct play is now fully supported in the web app and the android app. Will soon be implemented for iOS.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#172