why <streaming>
This commit is contained in:
parent
4fe666580f
commit
8576b212d1
1 changed files with 12 additions and 0 deletions
|
@ -254,6 +254,18 @@ for years, so you don't even need a special software to keep it working.
|
||||||
Of course, nothing prevents a CMS to generate this file dynamically, making this way simpler for users. But we
|
Of course, nothing prevents a CMS to generate this file dynamically, making this way simpler for users. But we
|
||||||
wanted RadioManifest to be deployable as _"just a bunch of static files"_, as a way to increase early adoption.
|
wanted RadioManifest to be deployable as _"just a bunch of static files"_, as a way to increase early adoption.
|
||||||
|
|
||||||
|
=== The `<streaming>` section overlaps too much with /streaminfo.json ===
|
||||||
|
|
||||||
|
Almost. While `/streaminfo.json` is clearly valuable data, we wanted to account for more usecases:
|
||||||
|
- A radio should be able to list more than one URL for streaming. This can be for load balancing reasons, for
|
||||||
|
example. M3U are a simple way to achieve this.
|
||||||
|
- A radio can (and probably should) have not only more URLs for streaming, but actually stream different
|
||||||
|
versions: different qualities, different codecs, etc. It is reasonable that, as a user, you don't really
|
||||||
|
care about all those details: «Just gimme the audio!». However, your client could select the best codec for
|
||||||
|
your usecase. Or, it may let the user explicitly select "low quality, low bandwidth" for users that want to
|
||||||
|
save bandwidth. This is possible with radiomanifest adding multiple `<source>` elements, and is
|
||||||
|
unfortunately not with `/streaminfo.json`
|
||||||
|
|
||||||
|
|
||||||
== Meta
|
== Meta
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue