Parse and supply metadata of Internet radio streams

NEW
Unassigned
(NeedInfo from)

Status

()

Core
Audio/Video: Playback
--
enhancement
4 years ago
5 months ago

People

(Reporter: BenB, Unassigned, NeedInfo)

Tracking

(Depends on: 1 bug)

24 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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.
(Reporter)

Comment 1

4 years ago
Chris, Ralph, any takers?
Severity: normal → enhancement
OS: Linux → All
Hardware: x86_64 → All
Version: unspecified → 24 Branch
(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

4 years ago
> 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.
(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

4 years ago
> 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.
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.
(Reporter)

Comment 7

4 years ago
> 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.
(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

4 years ago
> icy-metadata interleave in mp3 streaming?

I think. Shoutcast and Icecast MP3 streaming.
Ok. IIRC stagefright supports this, which is bug 778052 for mp3 metadata support on Android and ffos. Not sure about windows.
Depends on: 778052
Duplicate of this bug: 935661
Component: Audio/Video → Audio/Video: Playback

Comment 12

5 months ago
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
Flags: needinfo?(ben.bucksch)
You need to log in before you can comment on or make changes to this bug.