Thank you for the helpful comments.

<> wrote:
> 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
> 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.

<> 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.

Reply via email to