Re: [whatwg] Is the "document" identifier defined in the standards?

[Domenic Denicola]

From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Kevin Chen

> But I do not see a guarantee within the standards that the browser will 
> provide an object called "document" containing the current document object 
> (irrespective of the fact that this does seem to be the case in practice).

This is specified at https://html.spec.whatwg.org/#window as

> [Unforgeable] readonly attribute Document document;

and if you click on "document" there it takes you to 
https://html.spec.whatwg.org/#dom-document-2 which says

> The document IDL attribute, on getting, must return this Window object's 
> associated Document.

[whatwg] Is the "document" identifier defined in the standards?

[Kevin Chen]

Hello,
Looking through the DOM and HTML standards I have seen several implicit 
references to the current document object using the identifier "document". But 
I do not see a guarantee within the standards that the browser will provide an 
object called "document" containing the current document object (irrespective 
of the fact that this does seem to be the case in practice). So I'm wondering 
if this convention actually is codified as a standard, or whether it remains a 
de facto standard only.

Thanks for your answers.-Kevin

Re: [whatwg] metadata

[Silvia Pfeiffer]

On Mon, Apr 24, 2017 at 5:04 AM, Kevin Marks  wrote:
> On Sun, Apr 23, 2017 at 5:58 PM, Andy Valencia
>  wrote:
>> === 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.
>
> There are lots of models for dynamic metadata - look at soundcloud
> comments at times, youtube captions and overlays, Historically there
> have been chapter list markers in MPEG, QuickTime and mpeg4 (m4a, m4v)
> files too.

A different method is used on the Web for dynamic metadata: TextTracks
have been standardised to expose such time-aligned metadata. I don't
think this is the core of the discussion here though.

Cheers,
Silvia.

Re: [whatwg] metadata (and royalty reporting for some weird reason)

[Delfi Ramirez]

Hi all: 

* I agree with the exposure of  issues Andy presents. I do sympathize
with his approach, too.

* getMetadata sounds reasonable to me. The choice that a final
user/client of a web service, or a streaming service, can add some data
sounds reasonable to me. And I am not meaning the user/client as human
being here. Machine talks ( streams) to a machine using a browser based
solution, being precise.
* Voice is de facto the new way human beings browse the web. Humans
search for things and interests out of work with her/his voices
commands. These voices have and hold meta-data. And I do not mean any
karaoke silly scenario, being more precise.

* Concerning to all servers, radio/stations and other initial
committers.
* I am not pretty we should lay on them the responsibility to add or
remove metadata
* there was an issue, citing by memory an example,  with that
Soundcloud music browser based platform on the treatment of its
meta-data, while streaming audio, I guess.
(http://preview.tinyurl.com/issue-metadata ) _"In fact SoundCloud was
initially started with the mission to be the world's largest database of
sounds and it seems as if it never properly adapted their architecture"_
* The example of Soundcloud looks to me what a browser based software
( radio service or music service) offers streaming its data, and may
take real advantage of any future API enhancement or the  tag we
are trying to improve in this written talk.
* the link provided before is another solution built by two mates who
are, maybe, as much experienced dealing with  files as Roger is.
https://www.orfium.com/press/ 
*  I wonder , Shall not be profitable or interesting to ask those
engineers, to know a bit of their browser based service solution?
* Returning to the technical aspects, and according with
Andy,considering a  getMetadata() class is a plus

Cheers

---

Delfi Ramirez -- At Work

My digital signature [1]

0034 633 589231
 del...@segonquart.net [2] 

twitter: @delfinramirez [3]
 IRC: segonquart
 Skype: segonquart [4]

http://segonquart.net

http://delfiramirez.info
 [5]

On 2017-04-23 20:55, Roger Hågensen wrote:

> On 2017-04-23 18:58, Andy Valencia wrote: 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.

That has nothing to do with a web browser or related standards.

That type of reporting is done at the admin side of a streams server via
listener/performance logs.
Icecast do these, and AFAIK so can Shoutcast v2. And in any case most
streaming service providers use Centovacast which has it's own
performance log.

A radio broadcaster can also choose (and it's probably better) to log
locally in the radio software they use. There is a lot of radio software
out there and even the more crappier ones let you do song logs.

Also note that it is possible to pay a extra yearly fee to avoid the
reporting for smaller stations.

Also note that services like StreamLicensing.com do all the reporting
for you it is fully automated and do Total Listener Hour calculations
for you. And they do fetch stats directly from a Shoutcast v1 or v2 or
KH-Icecast server, although not in an ideal way. They are for US based
radio station only though and only handle the royalty reporting/paying,
the rest you have to handle yourself. For Canada SoniXCast.com might be
a good all in one solution (royalties/streaming/website hosting).

Also you say a local station. IF you are local (is it DAB/DAB+/DRM or
something else? Is it simulcast FM and Internet? Over-The-Air stations
that also broadcast via the internet has to follow different rules than
internet only stations. And there is no "local" station on the internet,
anyone anywhere in the world can tune in. Unless it's gated behind a
paywall or similar.

> 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

Chrome had that issue (forgot which version maybe Chrome v55) but added
some workaround code so old Invalid Shoutcast v1 HTTP responses will
work in both Chrome and Firefox (which has a different workaround), also
most streaming providers has a port 80 proxy option available which will
make the stream work with Chrome 55.

And never heard of StreamCast, all I see is a (dead?) project on
sourceforge.
If you are talking about the Shoutcast metadata then that is Shoutcast
v1 only (and slightly changed for Shoutcast v2 streams but you need a
Shoutcast v2 stream source software that support this, most still sue
the v1 

Re: [whatwg] metadata

[Kevin Marks]

On Sun, Apr 23, 2017 at 5:58 PM, Andy Valencia
 wrote:
> === 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.

There are lots of models for dynamic metadata - look at soundcloud
comments at times, youtube captions and overlays, Historically there
have been chapter list markers in MPEG, QuickTime and mpeg4 (m4a, m4v)
files too.

Re: [whatwg] metadata (and royalty reporting for some weird reason)

[Roger Hågensen]

On 2017-04-23 18:58, Andy Valencia wrote:

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.


That has nothing to do with a web browser or related standards.

That type of reporting is done at the admin side of a streams server via 
listener/performance logs.
Icecast do these, and AFAIK so can Shoutcast v2. And in any case most 
streaming service providers use Centovacast which has it's own 
performance log.


A radio broadcaster can also choose (and it's probably better) to log 
locally in the radio software they use. There is a lot of radio software 
out there and even the more crappier ones let you do song logs.


Also note that it is possible to pay a extra yearly fee to avoid the 
reporting for smaller stations.


Also note that services like StreamLicensing.com do all the reporting 
for you it is fully automated and do Total Listener Hour calculations 
for you. And they do fetch stats directly from a Shoutcast v1 or v2 or 
KH-Icecast server, although not in an ideal way. They are for US based 
radio station only though and only handle the royalty reporting/paying, 
the rest you have to handle yourself. For Canada SoniXCast.com might be 
a good all in one solution (royalties/streaming/website hosting).


Also you say a local station. IF you are local (is it DAB/DAB+/DRM or 
something else? Is it simulcast FM and Internet? Over-The-Air stations 
that also broadcast via the internet has to follow different rules than 
internet only stations. And there is no "local" station on the internet, 
anyone anywhere in the world can tune in. Unless it's gated behind a 
paywall or similar.




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


Chrome had that issue (forgot which version maybe Chrome v55) but added 
some workaround code so old Invalid Shoutcast v1 HTTP responses will 
work in both Chrome and Firefox (which has a different workaround), also 
most streaming providers has a port 80 proxy option available which will 
make the stream work with Chrome 55.


And never heard of StreamCast, all I see is a (dead?) project on 
sourceforge.
If you are talking about the Shoutcast metadata then that is Shoutcast 
v1 only (and slightly changed for Shoutcast v2 streams but you need a 
Shoutcast v2 stream source software that support this, most still sue 
the v1 method even with v2 servers).
Icecast uses Ogg streams with (I forget the term) virtual sidestreams 
with metadata, that can be sent at any point (at track change for 
example). The stream source must support this obviously.



The goal is to glean
the information which is *available anyway*.  Without changing the
protection regime.


"*available anyway** is only song artist and song title, I know this for 
a fact as I'm the tech guy in one of the oldest internet radio stations. 
Do you know how I know this? Because that is the only info that is sent 
from the DJs to the stream server over Shoutcast v1.


A DJ connecting to a Shoutcast v2 server using Shoutcast v2 mode can 
send album and year data etc. But there are almost no Shoutcast v2 
players out there (the biggest and most popular one I'm aware of is 
Winamp) pretty much all other players with shoutcast support only 
support v1 metadata. And ther are even more players out there that do 
not support shoutcast metadata at all. To them the metadata looks like 
invalid MP3 or AAC(+) data and is skipped/ignored. That metadata is a 
hack. Icecast does it as part of the Ogg standard and "should" work on 
all Ogg compatible players.



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.


There exists professional radio broadcast software for this which can 
cost thousands. And they need to be rock solid 24/7/365. No browser is 
designed to run that long. Not sure they even test that long runtimes as 
usually every few months there is a browser update anyway.



=== Proposed new API direction
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 

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 "