Feature Request - Icecast Support

[Brahmasmi]

@joeyparrish Would it be possible to put Icecast support on your roadmap?

Shaka is a DASH only player, and with latest patent pool, it is all but impossible for non-behemoths to use DASH.

Thanks.

[joeyparrish]

@Brahmasmi, I'm not sure. Can you provide some docs on Icecast, along with some sample streams? Can you describe in more detail how you want to use Icecast with Shaka Player?

[Brahmasmi]

Icecast is an open source streaming server, used by simple folks.
Documentation on Icecast - http://icecast.org/docs/
Sample streams - http://dir.xiph.org/

Use case - Shaka Player plays live as well as on-demand Icecast streams on modern browsers using modern codecs and containers (opus in webm) with media source extensions (where present, no idea what to do with iOS Safari).

Out of the above, I assume that Shaka does everything except Icecast streams.

A typical usage could be (pseudo-code)
player = shaka.player(srcURL)
player.play()
where srcURL is an Icecast source URL.

(All content beyond this is based on limited to non-existent knowledge)
From what I understand, DASH tried to solve the problem of network tuned content delivery by splitting content into various segments, which were denoted in MPD files. Shaka's current API requires manifest files. Shaka downloads these manifest files, parses it and then plays content based on network conditions and other factors.

Icecast is actually very simple, single bitrate, no segments, and hence there is no MPD file. <start of non-existent knowledge> It is a direct stream, which is fetched using XHR/range-requests <end of non-existent knowledge>.

Usually, simple HTML5 <audio> tags would suffice, except the fact that modern codecs and containers are not supported natively by most browsers. They do, however, support MSE based playback - case in point being Edge's support for opus in webm - https://blogs.windows.com/msedgedev/2016/04/18/webm-vp9-and-opus-support-in-microsoft-edge/.

Exoplayer for Android plays Icecast streams, so it may be possible that @vigneshvg might be able to help us throw more light on how Shaka could support Icecast streams.

If there are queries on the Icecast side, may be @ePirat might be able to help us.

[joeyparrish]

Shaka Player has a plugin system for manifest parsers. You could implement a manifest parser for Icecast (even though it seems to have no manifest). The plugin only has to describe to Shaka Player how to stream that content.

Because Shaka Player is built on the MediaSource Extensions to HTML5 video which are provided by the browser, segments are a core concept for us. That said, anything that MSE will accept is fine, and it doesn't have to be a "segment" per se. We just have to be told what pieces of content to fetch (URL + byte range) and when (what timestamps will be found in each piece of the content). If you can derive that info somehow, that's all we need to drive our streaming engine and MSE.

My team does not have time to develop an Icecast plugin (we are currently focused on HLS), nor can I make any promises about Icecast in the future. But if you want to write an Icecast plugin yourself, we would be happy to offer your support as you learn the plugin interface and figure out how you can map Icecast to it. I would also be happy to review a pull request to accept the Icecast plugin into our sources once you have something working.

Does this help?

[ePirat]

There is really no special requirement for "Icecast streams". There is not even such a thing as an "Icecast stream" technically speaking, as it is just a normal, indefinite HTTP GET request receiving the audio/video data.

Icecast does not support byte-ranges as that makes no sense for live content.

Given that Icecast just provides a single stream, no segments, there is no manifest.

[joeyparrish]

With MediaSource, we must make requests in JavaScript through XHR and feed ArrayBuffers to a MediaSource SourceBuffer. If you can't make byte range requests on Icecast, and you must do an indefinite streaming GET, I don't see any good way to play Icecast through MediaSource as it exists today.

[Brahmasmi]

Thank you @joeyparrish and @ePirat for your insights - I went spelunking to understand whether there is anything that might help us. From what I understand, XHR is being superseded by the Fetch API. There is a streaming response body, which might probably help us.

@jakearchibald - Could you please help us here - from what I understand from https://jakearchibald.com/2015/thats-so-fetch/#streams, the Fetch API has support for streaming response bodies. Would that help us solve the problem at hand - one that Joey has mentioned in the previous comment. For more background, I would request you to please refer to the issue and its comments.

Thanks.

[jakearchibald]

I have a longer post on streams here https://jakearchibald.com/2016/streams-ftw/.

Here's a quick demo where a 3mb resource is fetched in a streaming manner. The response chunks are Uint8Arrays. http://jsbin.com/vuqasa/edit?js,console

Is this what you're looking for?

[joeyparrish]

Since Icecast is based on a "hanging GET" or "long polling" strategy (one, indefinite GET that doesn't terminate), I don't think Shaka Player is a good fit out of the box. Our buffering system and use of MediaSource don't fit well with this. We expect to request multiple chunks, and to stop requesting when our buffer limit is reached.

Using Fetch with streaming may allow you to fake what we're expecting, but at that point, I have to ask: why even use Shaka Player? Our purpose is for adaptive bitrate, and the code is designed around that idea. For a single stream, you could just use Fetch and feed the data to MediaSource directly. If you aren't doing adaptive streaming, MediaSource is actually very simple to use.

[Brahmasmi]

The way I look at it, Shaka seems to be a counterpart to Exoplayer for android. The advantage of using Exoplayer is that it is a composable player, which allows one to build on top of well-tested robust reusable components.

Shaka has well tested components already present, and hence the request. There are a lot of horizontal challenges which have been already tackled, and more importantly, will continue to be tackled in Shaka. From what I can see, https://github.com/google/shaka-player/tree/master/lib/polyfill contains code that is non-trivial to write and maintain. Then there is the player state machine and Google Cast. I hope you would acknowledge that expecting a simple Fetch-linked-to-MediaSource-implementation to match Shaka's features and engineering quality would be a tough ask.

I do not intend to offend you, but could I turn around your question of why Shaka to why not Shaka? If it is simple, then may be, just may be, it can be accomplished within Shaka.

I do understand that Shaka is currently designed and implemented as an adaptive bit-rate javascript player. However, I also understand that there seems to be some kind of composability in Shaka. I base this on https://github.com/google/shaka-player/tree/master/lib/net where the http_plugin allows network based playback using XHR, while data_uri_plugin plays back data URIs.

Unfortunately, I am not native to Javascript and as such, I am in no position to contribute from the code side. Frankly, coming from a strongly typed language, I have a lot of respect for folks who write quality code in javascript.

Having said all of the above, I will completely understand if you do not wish to add Icecast to your roadmap. I can understand that some of the adaptive bitrate design assumptions may be present throughout the code, and the refactoring risk may not be in the best interests of your primary customers. Additionally, the team may be short on time and/or bandwidth or facing non-trivial constraints.

[joeyparrish]

@Brahmasmi, there is nothing offensive about your questions! Please do not worry. I am happy to have a conversation about this. I hope I haven't been rude.

I'm not opposed to Icecast support in any philosophical way. My team is small and has other priorities, so we will not be implementing Icecast ourselves, but we are happy to offer support to anyone in the community who wants to work on Icecast.

If an Icecast plugin can be made to fit the Shaka Player architecture, I would be happy to review a pull request to bring it into Shaka sources. If it can't be made to fit our architecture, then you are always welcome to fork Shaka and rearchitect it to fit your needs. That's the advantage of open source!

I acknowledge that Fetch+MediaSource is nothing like Shaka. It doesn't solve the same problems. I suggested it because it seems that Shaka doesn't solve the problem of Icecast particularly well, and an Icecast player using MediaSource was your stated goal. I thought it might be an alternative worth considering, and it might solve your problem better than Shaka can it its current form.

In response to your comments about composability, Shaka Player's internals are not composable as such. What you're seeing is Shaka Player's plugin architecture. For example, as you pointed out, HTTP network requests are supported via the HTTP plugin. There are also parsing plugins for text streams, such as WebVTT and TTML. Finally, there are manifest parser plugins for things like DASH and HLS.
In this architecture, Icecast support would be theoretically be a new manifest plugin.

However, the rest is not modular. For example, StreamingEngine works one way. It requires a certain kind of data to work, namely a list of independently-fetchable media segments and information about their timestamps. StreamingEngine is core to Shaka Player's design, and as far as I can tell, Icecast cannot directly provide what StreamingEngine needs.

So if Icecast looked trivial to support, I would consider adding to the roadmap for my team. However, it looks highly non-trivial because Icecast's design it as odds with our own.

Your options, in summary:

• Find a clever way to build an Icecast plugin for Shaka Player that feeds our StreamingEngine
  • docs for ManifestParser interface
  • docs for the Manifest structure which feeds StreamingEngine
• Fork Shaka Player to better fit Icecast
  • You may want to focus on modifying or replacing StreamingEngine
• Create something else using MediaSource and Fetch
  • I can provide pointers to MediaSource docs to help with this.

Please let me know if there's anything else I can do to help.

[Brahmasmi]

Thanks Joey for your elaborate explanation. You have not been rude, in fact, you have been very supportive and understanding. You have given this feature request a patient consideration. I was worried that I might come across as offensive, and hence my disclaimer.

From what I understand from your response, Shaka core is completely built on the design assumption of adaptive playback, with some degree of composability in peripheral components. I completely understand that putting Icecast on the roadmap is not feasible for the team. As such, for all practical purposes, this feature request can be closed.

With regards to the options, for someone with no knowledge of production quality javascript, the first option seems most attractive - adapt to the interface and hope for the best. Having said that, the last option is what would be correct, since the core architecture's evolution may not always agree with Icecast and keeping up with the retrofitting would be a maintenance challenge.

Thank you all for your time, patience and help.

[joeyparrish]

We are always happy to help. If you need assistance with Shaka or MediaSource, please let us know, either here or on our users list. Thanks!