908902 - Parse and supply metadata of Internet radio streams

Status: NEW

(Core :: Audio/Video: Playback, enhancement, P5)

Description

[Ben Bucksch (:BenB)]

Bug 869725 added support for Shoutcast streams in <audio>. That's fantastic.

To make it really useful, we need the metadata, though, to know the currently played song. This is part of the stream, so JavaScript can't get to it. Parsing it shouldn't be too difficult, if you're in the right place in the stream decoder.

The same should be true for ogg streams, which also support metadata, but of course in a different format.

The information should be passed back to the webpage using a DOM attribute that <audio> sets on its own DOM element, e.g. <audio src="..." trackinfo="Lisa Stransfield - So Natural --- SomaFM - The best songs of the 80s" />
This is trivial to access for the webpage's JavaScript, and gives us a free observer via "DOMAttrModified" event or the new MutationObserver.

Comment 1

[Ben Bucksch (:BenB)]

Chris, Ralph, any takers?

Comment 2

[Timothy B. Terriberry (:derf)]

(In reply to Ben Bucksch (:BenB) from comment #0)
> The same should be true for ogg streams, which also support metadata, but of
> course in a different format.

Metadata in Ogg streams has been exposed to JS since Firefox 18 (see bug 778050, and Ralph's test page: <http://xiph.org/~giles/2012/metadata.html>).

Comment 3

[Mike Kaply [:mkaply]]

> Metadata in Ogg streams has been exposed to JS since Firefox 18 (see bug 778050, and Ralph's test page: <http://xiph.org/~giles/2012/metadata.html>).

That's an individual song, not a stream. Looking at the patch, I'm not sure.

Comment 4

[Timothy B. Terriberry (:derf)]

(In reply to Mike Kaply (:mkaply) from comment #3)
> That's an individual song, not a stream. Looking at the patch, I'm not sure.

Edit the page to point to a stream (you can find some active ones at <http://dir.xiph.org/>) if you don't believe me. Last I checked, it worked fine.

Comment 5

[Mike Kaply [:mkaply]]

> Edit the page to point to a stream (you can find some active ones at <http://dir.xiph.org/>) if you don't believe me. Last I checked, it worked fine.

I believe you. That's awesome.

Comment 6

[Ralph Giles (:rillian)]

You can even listen for 'loadedmetadata' and to know when to call mozGetMetadata() again.

As for taking this bug, consensus on whatwg was that we should replace mozGetMetadata with something unprefixed returning a standard set of keys, e.g. title, artist, album, tracknumber, album art. We could integrate stream metadata from the HTTP 'icy-*' headers into that scheme as well, but not all the keys; probably only a fallback for title/artist make sense. I don't think we should bolt more stuff onto the current framework.

The Media Source Extensions we're implementing will let page content pull the stream over XHR, inspect the headers itself, and then forward to a media element for playback. That's more work, but will let people solve this without platform additions. I don't expect to do more metadata work any time soon.

Comment 7

[Ben Bucksch (:BenB)]

> We could integrate stream metadata from the HTTP 'icy-*' headers into that scheme as well,
> but not all the keys; probably only a fallback for title/artist make sense.

Agreed, title and artist is enough.

But then again, if it's HTTP headers, it would be only one set of tags for the whole stream. I'm talking about Internet radio streams, and getting the artist and title for each song played, when it's played.

> The Media Source Extensions we're implementing will let page content pull the stream over XHR,
> inspect the headers itself, and then forward to a media element for playback. That's more work

Yes, a lot, because then the app has do all the stream handling myself.

Comment 8

[Ralph Giles (:rillian)]

(In reply to Ben Bucksch (:BenB) from comment #7)

> But then again, if it's HTTP headers, it would be only one set of tags for
> the whole stream. I'm talking about Internet radio streams, and getting the
> artist and title for each song played, when it's played.

What formats are you concerned about? Ogg and Opus streams over http work with audio.mozGetMetadata per comment #2. Are you asking about inline id3 packets or icy-metadata interleave in mp3 streaming? Something else?

> Yes, a lot, because then the app has do all the stream handling myself.

Someone has to write code either way. A js library is easier to implement and deploy than new browser features...

Comment 9

[Mike Kaply [:mkaply]]

> icy-metadata interleave in mp3 streaming?

I think. Shoutcast and Icecast MP3 streaming.

Comment 10

[Ralph Giles (:rillian)]

Ok. IIRC stagefright supports this, which is bug 778052 for mp3 metadata support on Android and ffos. Not sure about windows.

Comment 12

[renan]

using the fetch API we could parse the icy-metadata in javascript directly. But the problem is that when fetching with custom header icy-metadata:1. the fetch api returns net::ERR_EMPTY_RESPONSE

here an example of the request/response that throw this error:

curl -v -H "Icy-Metadata:1" http://195.154.185.139/radio/1906/stream/63694 -o toto

> GET /radio/1906/stream/63694 HTTP/1.1
> Host: 195.154.185.139
> User-Agent: curl/7.47.0
> Accept: */*
> Icy-Metadata:1
> 
HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: Icecast 2.4.2
< Date: Sat, 13 May 2017 08:51:45 GMT
< Content-Type: audio/mpeg
< Cache-Control: no-cache
< Expires: Mon, 26 Jul 1997 05:00:00 GMT
< Pragma: no-cache
< Access-Control-Allow-Origin: *
< icy-br:320
< icy-description:La musique venue d'ailleurs
< icy-genre:Electro, House, Techno, Indie, HipHop
< icy-name:Tsugi Radio
< icy-pub:1
< icy-url:http://radio.tsugi.fr
< icy-metaint:16000

Comment 13

[ociebieda]

Shoutcast/Icecast mp3 radio stream metadata is still not working as expected.
Demo test: https://netkoder.dk/test/test0296.html
Explanation how metadata works in Shoutcast/Icecast mp3 radio streams: https://stackoverflow.com/a/4914538
Example of code that retrieves title from such streams: https://stackoverflow.com/q/15803441

Comment 14

[Ralph Giles (:rillian)]

That's correct. HTMLMediaElement.mozGetMetadata() is only implemented for .ogg, .opus, and .flac streams.

You can implement icy-metadata reading for mp3 streams in javascript using the methods suggested in the stackoverflow. If you want to avoid duplicate queries, you can use the MediaSource Extensions API to feed the fetched chunks to a media element, but note that Firefox doesn't support audio/mp3 through MediaSource.addSourceBuffer; you need to remux the stream in mp4 before submitting.

To implement native mozGetMetadata() support for mp3 streams, one could set the Icy-Metadata:1 header on HTMLMediaElement queries where the url ends in mp3, and then add a flag and decoding support to MP3Demuxer.

Comment 15

[Byron Campen [:bwc]]

This sounds like a P5 to me, right?

Comment 16

[Ben Bucksch (:BenB)]

Depends on whether you consider HTML5-compliant Internet radios important or not.
Whether you care to know what song you listen to or not.

Comment 17

[Ralph Giles (:rillian)]

I'm not working on this for the time being. Sorry.

Comment 18

[mprops]

Please reconsider this. It would make internet radio a lot easier to deal with. The metadata is already supplied in the stream.

This would avoid having to find the status page and query it every x seconds (if it's even available, often it's not).

Here's some discussion about it you might find relevant. https://stackoverflow.com/questions/44050266/get-info-from-streaming-radio

Internet radio is a useful medium, and tech like Icecast is still being developed.

Comment 19

[mprops]

I learned there's this project which provides a custom player that can read metadata:

https://github.com/eshaz/icecast-metadata-js