Re: New Editor's draft (v20140321)

On 3/24/14 10:31 AM, Mandyam, Giridhar wrote:
>
> 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.
>

I think a motionblur:false constraint would best answer the developer's 
needs here, and match the API we've built so far.

But thanks for the example, I'll use it to make my two points:

1) Theoretically, shouldn't hardware limitations be discoverable in 
getCapabilities()? e.g. getNativeCapabilities() instead of 
getNativeSettings()? If that's not easy, what's the point of 
getCapabilities()?

2) If you don't trust the driver, why trust the UAs (to return the right 
info)? I'm trying to think how I'd implement getNativeCapabilities() in 
the UA, and a static table of device names comes to mind... I mean, how 
is the UA supposed to know what tricks are in the driver at runtime? 
Another abstract method specifically for people who don't trust 
abstractions seems like a no-win.

.: Jan-Ivar :.

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