See also: IRC log
<stefanh> details and proposed agenda for the call: http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0004.html
<stefanh> details and agenda: http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0004.html
scribenick burn
<stefanh> draft noted June 25: http://lists.w3.org/Archives/Public/public-media-capture/2014Jun/0144.html
stefan: first need to approve minutes from last call
<ekr> I have not reviewed these minutes
stefan: any problems with these minutes?
<ekr> I will do so now, please do not approve until end of call
stefan: will return to minutes approval at end of call
... next is ideal algorithm, Peter will present
<stefanh> Peter's slides: http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/att-0019/Finding_an_-Ideal-_Algorithm__4_.pdf
Peter: mailed latest pdf this morning
... 2 alternatives: min distance and advanced expansion
... starting with min distance
<Jim_Barnett> How does this work with applyConstraints?
Peter: key is to calculate distance from all constraints for each possible device mode and choose the smallest
<hta> jim: I think it would work identically, except that only modes available for the selected device would be selected. Put yourself on the speaker queue if you wish to address this question in the chat.
Peter: note that there are different types of distances based on which constraint. for example, sourceId is weighted to require more exact matches
ekr: how does this work with cameras that pick a resolution and rescale?
... very difficult for me to enumerate all possibilities
justin: if there are no specific modes any choice is arbitary. idea is to do something comparable when you can't enumerate.
ekr: this is linear programming problem
cullen: no, just pick something reasonable/close here
<stefanh> zakim ack ekr
(can't catch all the discussion here)
ekr: I want someone to write me the code that does this in O(nsquared)
<ekr> Sorry, that's *not* n^2
<ekr> Obviously n^2 is trivial
cullen: not linear programming. yes, combinations of frame rate and resolution will require more checking
ekr: let's say camera has different resolutions, each of which comes with a different bitrate.
... but you are given a table and not a function
<mt_> it could be a table or a maximum pixel rate
cullen: with table-based approach, can step through optimal value for each table entry
jib: in FF implementation some drivers enumerate all modes and some don't give you any. You have to guess when not given the info.
ekr: so you have to enumerate as a table?
cullen: typically told resolution x can be done up to this framerate, y up to this framerate, etc.
... so in theory this is infinite, but in practice you don't have to do that.
... often this is a function and not a table.
jib: doesnt' have to be perfect
ekr: no, you told me i had to do this algorithm.
cullen: in most cases can describe a closed-form solution
ekr: i complained about needing a complete constraint solver 2 years ago
jib: a third option is to just make them hints
stefan: some implementers are in the team that came up with this. any comments from them?
<fluffy> I apoligize - I did not realize there were people on the Q
giri: was Euclidean distance rejected?
<mt_> for the record, having seen Jan-Ivar's code, ekr's concern is pretty valid.
<mt_> the mac camera is a pain
cullen: for aspectratio you want to compare geometrically/exponentially. it is Euclidean but scaled to the idea of an ideal image. every new constraint does require a metric and we could debate them, but as long as it's deterministic it doesn't matter too much since you can implement your own
... you can always use advanced to get what you want
<mt_> fluffy: this is not euclidean distance
cullen: if you don't like the definition of ideal in the standard, then use advanced
<mt_> sum of logs!
<mt_> least squares!
<ekr> sin(logs)
harald: slight preference for squaring. We say algo has to behave the same as what's specified, but doesn't say you have to use the algo given. This is quite implementable in practice.
... with real drivers and real devices this is doable
<hta> juberti-
stefan: what about this large value for strong match? doesn't this make this constraint mandatory or exact?
cullen: for some constraints, such as the id, we essentially want ideal to mean exact. regarding squaring the distances that's probably not a big sticking point
jib: not sure we need close or greater. For example, on framerate why not just CLOSE?
peter: couldn't think of a reason
(several folks spoke at once in reply)
Peter: okay with framerate being the same as aspectratio or height/width
... also, the intent was that the exact alg doesn't have to be implemented, but result must be same
Justin: on distance min, we considered Euclidean but switched to linear for simplicity. This wolud be a minor change. On dynamic range, there is no trivial solution. best is for app to try something and see what happens. If app requests a certain framerate and resolution from device, it just needs to check what comes back from device and adjust accordingly.
... typically you DO have enumerated modes. It works quite well. That's my implementer feedback.
(back to slides)
Peter: this is easy to try out in a spreadsheet
... there were some questions raised on the list, shown here in the slides
(skipping over advanced expansion option at group request)
jib: I like min distance much better than advanced expansion but also like no ideal
ekr: if this is what's required to get ideal, then let's get rid of idea altogether
martin: i suggest getting rid of advanced instead
jib: i meant that I like impl-spceific version as well, not removing ideal altogether
cullen: we have to keep advanced because of use cases. don't want ideal with non-deterministic behavior. we can remove it, but don't leave it in and have nondeterministic behavior
justin: not sure how to solve continuous ranges with advanced since it doesn't give a target, and I think ideal solves 99% of cases people want without using advanced, so it's important to keep
... think ideal is the best thing we have so far for dealing with parameters that are interrelated. ideal needs to be deterministic.
stefan: in DC there seemed to be much support for ideal. several people are requesting ideal be deterministic.
ekr: yes, make ideal deterministic.
<ekr> I agree that this text is deterministic. I just don't like it :)
harald: (consensus call) two questions: if this spec proposed for ideal clear enough that it satisfies reuqirement for determinism. Second question is whether we accept or reject it. Believe we have rough consensus on first part. Any objections to that?
(silence)
<gmandyam> QuIC is in favor of rejection
scribe: Now for call in favor or against. Several folks chiming in on IRC
In favor are Dan, Stefan, JIB, (missed name -- from MSFT) in addition to those who have already spoken
<mt_> Shijun Sun
harald: believe we have rough consensus to go ahead. EKR said he could live with it. Giri?
Giri: don't understand what this adds, but if chairs call rough consensus then so it is.
<ekr> harald: if you think there is consensus, can you please formally call it?
harald: formal objections are permitted in W3C, are you doing that?
giri: i don't understand how min distance proposal happened and this approach isn't sufficiently future-proofed. Not sure it addresses real use cases.
... no objective comparison of algorithms.
Stefan: i hear you saying there could be another algorithm.
Giri: it mandates deterministic behavior which is not future proof. ideal is fairly new, not clear we understand it well enough
... will not raise formal objection, but caution group against adding features at this point.
justin: we covered rationale for ideal in dc. today we attempted to explain how it works. it's pretty simple. I don't understand the advanced use cases and thus consider ideal essential for developers. If you need something beyond ideal, advanced exists.
<jib> +1
<mt_> i agree with juberti on this; advanced is merely a poor substitute for programmable selection
giri: record the decision and take it to teh mailing list so we can move on.
<jib> mt_: agree with mt and justin on removing advanced
harald: let's go ahead with min distance version of ideal. further comments would need to be made there.
<hta> burn: there = on the mailing list
<Peter> Sure. Sorry about that.
harald: Chairs have declared that there is rough consensus to go ahead with the min distance version of ideal and that further comments would need to be made on the mailing list.
<ekr> thank you
<stefanh> scribenick stefanh
<fluffy> sorry but I need to drop at this pont
Harald to talk about bug resolution
<ekr> For future reference, if you do "RESOLVED: " Zakim treats it specially
hta: refering to slides sent out earlier: http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/att-0018/August_Media_Capture_Bug_Walkthrough__1_.pdf
hta: Most bugs are about making sure text is clear and consistent
...called out two bugs for discussion
<ekr> Or rather RRSAGENT
...does anyone want to call out any other bug from list
How long does permissions persist? See slide
....permission about read labels of devices you've had access to the label too. Should the app be allowed to read labels after closing all devices?
....finger-printing related.
Ekr: we should remove label access when closing
...for consistency.
Decision: label permissions persist until all devices are closed
hta: Next: 22251 error codes when no devices are available (or some other thing hinders)
...proposal in slide
...OK?
MT: how is source unavailable different from not getting aceess
...and do we want to make the distinction?
hta: there is a difference (elaborating)
MT: do we want to expose this to the app (for good and bad)? What info can the app get that is sensitive?
Jim: in the past we said the app should not know (but that was a loooong time ago)
Decision: implement proposal
hta: next slide about how bugs are handled
...next slide about how people can help out resolving bugs
Minutes from last meeting (June 25) approved.
<jib> my slides: https://docs.google.com/presentation/d/1pql9zGhtX8r84qdnGFuSZM0aOMOHBxXVbkJsXwbCI0k/edit#slide=id.p
jib: talking through slides
....meaning of word "constraint"
...slide 3 look at JS code example
....slide 4
....slide 5
....ideal is the only thing that stands out
Ekr: I don't think I agreed to floating point expressions
jib: sorry for bad example
.... slide 6
adam: I have an issue with removing the exact keyword - we may express constraints as objects in the future, would mean ambiguity
jib: have not seen a proposal for multi prop constraints before
...can be figured out
<mt_> fwiw, I'm with jib on this, aside from the point about removing exact
...slide 7 min max can been different things depending on where they are applied
<mt_> the aspect ratio thing needs to be solved
....questions?
...we're are not tied to ideal
justin: app developer perspective, would be surprised if things fail 'cause a bare value is interpreted as exact
jib: naive people seem to think "mandatory" and not ideal
juberti: if you move to a new computer you could be surprised
jib: the developer should use ideal or advanced
juberti: not the simple apps
ekr: agree with justin, lingusitic arguments not convincing
hta: jib introduced foot gun - this is a foot gun
jib: foot-gun was different
<mt_> calling back to previous... https://www.w3.org/Bugs/Public/show_bug.cgi?id=26526
Peter: prefer removing bare values
stefanh: agree with Peter - my point
mt_: foot-gun argument works for me too
jib: unfortunate to remove "bare" (lost argument why)
<mt_> chairs, I formally request a consensus call on this
hta: only one arguing for bare meaning exact is jib
dan: do we accept jib's proposal?
<ekr> We are out of time.
hta: currently bare means ideal, we have a new proposal to make it mean exact
...anyone except jib supporting the change?
...silence
...result: no concensus to change, so bare will mean ideal
chairs declared this as consensus.