Thank you for the helpful comments. <phi...@foolip.org> wrote: > http://www.smackfu.com/stuff/programming/shoutcast.html isn't detailed > enough to get interoperable implementations, in particular the metadata > keys would have to be defined.
Note that mp3, flag, ogg, and wav all have entirely open ended container formats for their metadata. The framework as used by Shoutcast and Icecast is similarly extensible, although StreamTitle and StreamUrl are the obvious low-hanging fruit. I've reached out to the Icecast folks to see if there's interest in, say, an informational RFC. > Second, as already outlined above, one needs to be able to get the > current metadata somehow. I think that a mediaElement.getMetadata() > method that returns a > https://wicg.github.io/mediasession/#the-mediametadata-interface > instance would make sense, and then the metadatachange event could > be a simple event with no extra information on it. Ok. Note that this data structure suffices to encode the baseline information from Shoutcast/Icecast. It does not, for instance, encode "Label", needed to do licensing reporting in the USA. "Year" is another datum often of interest. But "good enough" as a starting point is fine by me. I'm assuming getMetadata() is based on the older mozGetMetadata() API? That API appears to auto-populate from the various supported audio file headers. So adding "dynamicmetadata" is just another way for those fields to be populated. (I'm going to look at submitting an edit to the metadata container so it can handle extension information, something along the lines of the "X-" prefix in RFC-822 headers. That would be orthogonal to this work.) > In order to make progress, there needs to be implementer interest. Yes; I have no doubt there's many more ideas to lob at browser implementors than they could ever cook up (even if vetted to just the "good ones"). However, as a long-time C dev with a touch of C++, I'm counting on doing an implementation for at least one major browser if I get to rough consensus. I know, it doesn't guarantee they'll accept my submission. <ann...@annevk.nl> wrote: > Demonstrating there's interest in this through a popular JavaScript > library or two would help a lot. If I could do this in Javascript, I would. Multiple issues: <audio> and src= run at the full efficiency of platform audio streaming. But you don't get to see the bytes. You can do the fetch yourself and look at the partial data in responseText (remember, it's an ongoing stream). But responseText keeps growing, requiring you to periodically reset the connection. Hard to maintain a listening experience. What to do with the bytes after peeling out the mdatadata? A local URL is based on a Blob, which is immutable, so no good way to tack on newly arrived data. You can run your own ogg/flac/mp3/wav decoder, but you'll come up short of platform efficiency. Probably a non- starter for mobile. The new ReadableStream mechanism to feed fetches out of a Service Worker is either a solution, or at least pretty close. (I can't quite convince myself it's actually mutable in the way needed to endlessly append stream data as it arrives.) But the overarching issue is that you're doing JS-initiated network operations, and origin policy is going to stop you. You can claim Shoutcast/Icecast should give permissive origins, but they don't, and since an admin-ish interface is also multiplexed at the host, probably shouldn't. I'll rework my submission based on these comments, thanks again.
