RE: New Editor's draft (v20140321)

I was not in attendance for the Berlin IETF, so I cannot comment on the motivation for this feature.  I can say however that during the Feb. F2F last year there was some discussion on whether the UA can attempt to meet a mandatory constraint when the native capture device cannot.

For instance, say that getNativeSettings() returns {"frame rate":  30.0, ...}.  However, a MediaStream was successfully created with {"mandatory":{"frame rate": 60.0} ...}.  Then the developer could have an indication as to whether the UA is applying post-processing in trying to meet the mandatory constraint, and may choose to adjust the constraint back to 30 fps to avoid any UA-introduced processing delay.

It could be that in reality, the UA will not try to meet a mandatory constraint that the capture device cannot meet itself.  If so, then what I mentioned above is not really relevant.

-Giri

From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com]
Sent: Monday, March 24, 2014 6:42 AM
To: Harald Alvestrand; public-media-capture@w3.org
Subject: Re: New Editor's draft (v20140321)

On 3/23/14 3:41 PM, Harald Alvestrand wrote:
On 03/21/2014 03:37 PM, Jan-Ivar Bruaroey wrote:
On 3/21/14 9:07 AM, Adam Bergkvist wrote:
    Added native settings to tracks.

Use-case please? Where was this discussed? It is unclear what this is intended to solve.

Looking at the language for  getNativeSettings(), I have concerns about this API: " Note that both the track settings and the native settings are snapshots and can change without application involvement."

Native settings that can change. Are we supposed to poll reactively for changes to "native" settings after we've already gotten the wrong thing? That seems awfully late. I would think that what's native about any source (or anything) would be almost entirely deterministic, and discoverable ahead of time, with something like getCapabilities().

So if anything, I think we're extending in the wrong place here.

I am, however, impressed by how this got in here so expediently. ;-)

Just to un-impress you a bit :-) .... this is an attempt to put down a concrete implementation of an understanding some of us reached at discussions at the Berlin IETF, July 2013.

The understanding was that there may be times where an app needs to know what the state of the underlying source was, independent of the properties of the tracks it's producing. I'm not sure how real that need is, but we agreed at that time to try to express it in some fashion; this is the first attempt.

OK so it hasn't been discussed here then? I'm happy to discuss: I read two questions in your statement, what the need is, and by when is it useful to have this information?

Also, I am still impressed. :-) Having a "first attempt" land in the spec no doubt makes for easier discussion - if any were to surface here - but I trust prudence is now taken to remove it again, if need be, based on lack of support, not lack of opposition.



--

Surveillance is pervasive. Go Dark.

.: Jan-Ivar :.