Re: [whatwg] Popular Background Geolocation question on StackOverflow

[Andy Valencia]

[Philipp Serafin <phil...@gmail.com>:]
> If this problem is specific to the "track a route" use-case, and the
> use-case is sufficiently widespread, would a dedicated "route recording"
> API make sense?
>
> E.g., a web page could ask the browser to continously record location
> changes and - at some time at the browser's discretion - push a list of
> recorded changes to the page.

Playing audio is already a special case; the tab with the active
 element will almost certainly not have its setTimeout's
honored until it comes back to foreground.  But the "ended" event
will get to run, at least long enough to move to the next track.
In fact, it can XHR and get to run/play-next on the completion.

(But wait, on slower tablets Firefox doesn't allow quite enough
CPU to keep the background mp3 playing.  Oops.)

Or think about the iterations in the space of downloads (XHR,
service worker background fetch, background sync).

There are lots of apps using long-polling which would also like
to have some explicit (standards based) answers to their needs
to run when not the current tab--messaging and telemetry apps,
for instance.

And here we are thinking about a hand crafted solution for GPS backgrounding.

We're all well aware of the behaviors which make browsers adopt such
defensive measures.  Are we looking at enough use-cases to think about some
sort of general authorization for background resource consumption, rather than
continuing the point solution approach?

$0.02,
Andy Valencia

Re: [whatwg] META and bookmarking

[Andy Valencia]

Thank you very much for pointing me at the right bits of existing
standards.

Matthew Wronka's reference of a "canonical relationship" and
RFC6596 is very much on target.  rel=canonical should do as much
as I could hope for in any case.

I of course considered an initial landing page, but UX pushes strongly
where the 99.999% case is not the one which should require the extra
click.  I'll certainly have the canonical link specified, and hope
for the best.  Perhaps even, as you say, submit a ticket to a
browser or two.

Thanks again,
Andy Valencia

[whatwg] META and bookmarking

[Andy Valencia]

I'm in the throes of a media startup, and ran into one of those
issues which runs surprisingly deep.

Like many sites, my front page is a portal which sends the
user on to the actual source of content for that user on that
day.  In my case, it's a particular media server (after choosing
based on current load) plus a session token in the URL.  I've
been researching this, other cases are where the redirect URL reflects the
current day/edition/release.

The problem is if you like the site and decide to bookmark it--
including a home screen bookmark on mobile.  You're off on
a transient URL, which is not the right one to bookmark.  On
a desktop browser you can go into the extended dialog and
hand-modify the URL (some users could, others not so much).
On mobile, it can be difficult--on some devices even impossible.

I'm wondering if a  tag would be appropriate? This
would let a page which knows it's not a good long-term bookmark target to
suggest a better URL to use.  In its absence, of course
the current URL is used.

For security, you could claim that anywhere Bad it would send you
is a place the current page could have already sent you.  If the
page was served under HTTP, I guess a lame ISP could insert themselves.
Possibly recommend ignoring the value from non-HTTPS pages?  That
certainly aligns with Mozilla's stated intentions for future
features.

Thanks,
Andy Valencia

Re: [whatwg] metadata

[Andy Valencia]

I've become aware of quite a bit more metadata support in the world
of web browsers; please consider my old proposal withdrawn.

=== Reporting
> Only "artist" and "title" are required for royalties reporting for
> internet radio.

I'm sorry for a bit of topic drift on this list, and I'm sure requirements
vary by nation.  I do reporting for a local station and among the
requirements I have to meet:
https://www.soundexchange.com/service-provider/reporting-requirements/
This is the last thing I'll say on this tangent.

=== Dynamic versus static metadata

Pretty much all audio formats have at least one metadata format.  While
some apparently can embed them at time points, this is not used by any
players I can find.  The Icecast/Streamcast "metastream" format is the
only technique I've ever encountered.  The industry is quickly shifting
to the so-called "Shoutcast v2" format due to:
https://forums.developer.apple.com/thread/66586

Metadata formats as applied to static information are, of course, of
great interest.  Any dynamic technique should fit into the existing
approach.

You have to draw a distinction between API's concerned with UI/UX
presentation, and those concerned with getting the underlying
information.  MediaMetadata is an example of the former, mozGetMetadata
the latter.  I'm now looking at mozGetMetadata as a starting point,
with a minimal change to add dynamic metadata events.

Of course, mozGetMetadata makes a very nice counterpart to Chrome's
MediaMetadata API for rendering the information to the listener.

=== Processing a stream programatically
> If the same-origin policy stops you, it should also stop a C++
> implementation. It's there for a reason.

This is all framed by techniques exemplified by 
which enjoy permissive origin treatment.  The goal is to glean
the information which is *available anyway*.  Without changing the
protection regime.

=== Non-trivial audio application
> Also royalty reporting is done in a earlier stage, what a listener sees
> is not what is logged/given for royalties reporting.

In addition to the obvious benefits of gleaning metadata and
updating the UI, I'm also interested in non-trivial audio applications
like:
https://en.wikipedia.org/wiki/Broadcast_automation
both static and dynamic metadata sources are very much of interest.
The browser execution environment is an excellent platform for these
sorts of applications.

=== Proposed new API direction

Here's the approach which now makes the most sense to me.

Ultimately, I'd hope that the moz-prefixed mozGetMetadata could indeed
be standardised (to getMetadata).  Keep the same semantics, possibly
formalize some basic fields (artist, title, album, year, ...).  If
one of those receives a value from the underlying media, it'll have
that value.  It's legal to omit fields which have no value.

Then, metadatachange is added.  While an event handler is active,
then on each detected change of metadata a callback occurs.

For the special case of Icecast/Shoutcast where the initial HTTP GET
requires a special header, the change handler must be in place before
the stream is opened.  Thus "

Re: [whatwg] metadata

[Andy Valencia]

Thank you for the helpful comments.

 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.

 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:

 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.

[whatwg] metadata

[Andy Valencia]

What follows is a first pass at addressing a missing ability
when dealing with Internet streams, usually radio ones.
Comments and suggestions are quite welcome; as my first
attempt--ever--at submitting to this group, apologies if
I've made any mistakes in how I've proceeded.

Thanks,
Andy Valencia
Contact: https://vsta.org/contact/andy


Proposal for enhancement to HTML5  element to better support
metadata provided by streams.

# Background

Browsers have an  element which can directly play streaming
URL's.  When the stream is an Internet radio station, the stream
almost certainly offers metadata; typically, the artist and track,
and often an album cover URL as well.  While modern browsers can
play these streams, there is no way to access this metadata.

Media elements in modern browsers _do_ have the notion of metadata,
but in current standards this is limited to static characteristics
such as duration.  When listening to a radio stream, the metadata will
change as successive tracks are played.

# Stream Delivery of Dynamic Metadata

A moderately detailed description of current practices in providing
metadata is provided at:

http://www.smackfu.com/stuff/programming/shoutcast.html

(One detail glossed over in this page is that older streaming servers
start their GET response with "ICY 200 OK" rather than a standard
HTTP response.  This technically means the response is HTTP 0.9
without headers; the headers are present, but must be processed by
the application and trimmed from the start of the media stream
in the GET response.  Apple Safari already declines to play 0.9
media elements within a post-0.9 page, and there are signs that
Chrome will follow suit.  Thus, accomodating this older mode should
be considered optional.)

Newer streaming server versions use a proper HTTP response, with
the documented elements in the HTTP response header.

Because the metadata is encoded in a general attribute=value
format, a wide variety of metadata may be encoded.  By convention,
at least the attributes "StreamTitle" and "StreamUrl" will be
included in the response.  Also by convention, StreamTitle is
structured as "Artist - Track Name".

# API Considerations

While listening to streams with metadata is a compelling application
of web technology, it is probably a tiny percentage of the use
of  elements.  Thus, this proposal describes a mechanism
which leaves the default browser behavior unchanged.  It also
gracefully degrades when presented to a non-implementing
browser, still permitting stream play while in the existing
non-metadata fashion.

This proposal is designed with the current state of streaming,
currently depending on the HTTP Icy-MetaData header element.  However,
this specific detail is abstracted, in recognition that streaming
technology could evolve in the future.  The intention is that this API
will remain stable even if the details of metadata request and
delivery change.

As noted, current HTML5 media elements do have some metadata support.
This API is also structured to permit these existing elements to
participate in this API if desired.

#  element changes

These enhancements are activated when the  element has the
new attribute "dynamicmetadata" present.  Without this attribute,
no metadata request header is added to the stream HTTP request, and no
other attributes of this proposal will be acted upon even if present.

If the server response indicates support for dynamic metadata,
on each metadata update, the  element's attributes are changed
to reflect the latest received metadata.  For each "Attribute=Value"
in the metadata update, an attribute "metaAttribute" with value "Value" will
be added to the  element.  Previous metadata attributes which
are not present in the latest update are left untouched.  The browser
must verify well-formed identifier names for each Attribute, and
quietly reject ill-formed names.  It can also apply checks on the
Value.  (Implementors are reminded that the Value, because it encodes
information such as names, might contain a wide range of character
encodings.)

The  element adds the hook "onmetadatachange", connecting to
a function which is called on each update of metadata.  This
function is called with an event, which includes the attribute
"changed" with a value which is a list of Attribute names which
are present in the update.

# Example code


function new_meta(ev) {
const changes = ev.changed;
if (changes.indexOf("StreamTitle") >= 0) {
const title = player.metaStreamTitle;
const idx = title.indexOf(" - ");
if (idx == -1) {
// "Just a plain old piece of text"
artist.textContent = title;
track.textContent = "";
} else {
//  - 
artist.textContent = title.slice(0, idx);
tr