- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 11 Aug 2014 14:43:50 +0200
- To: public-media-capture@w3.org
Hi,
The minutes of the teleconference on August 5 are now available at:
http://www.w3.org/2014/08/05-mediacap-minutes.html and copied as text
below. Please send corrections to the list.
Dom
Mediacapture Task Force teleconference
05 Aug 2014
See also: [2]IRC log
[2] http://www.w3.org/2014/08/05-mediacap-irc
Attendees
Present
Dan_Burnett, stefanh, adam, +1.425.610.aaaa,
+1.408.421.aabb, +1.267.934.aacc, jib,
+91.22.39.14.aadd, gmandyam, [Mozilla], [Microsoft],
fluffy, Jim_Barnett, +47.41.44.aaee, hta,
+1.425.610.aaff
Regrets
Chair
hta, stefanh
Scribe
burn
Contents
* [3]Topics
1. [4]Admin
2. [5]Algorithm for "Ideal"
3. [6]Bug walkthrough
4. [7]JIB Talk about "bare"
* [8]Summary of Action Items
__________________________________________________________
<stefanh> details and proposed agenda for the call:
[9]http://lists.w3.org/Archives/Public/public-media-capture/201
4Aug/0004.html
[9]
http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0004.html
<stefanh> details and agenda:
[10]http://lists.w3.org/Archives/Public/public-media-capture/20
14Aug/0004.html
[10]
http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0004.html
scribenick burn
<stefanh> draft noted June 25:
[11]http://lists.w3.org/Archives/Public/public-media-capture/20
14Jun/0144.html
[11]
http://lists.w3.org/Archives/Public/public-media-capture/2014Jun/0144.html
Admin
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
Algorithm for "ideal"
<stefanh> Peter's slides:
[12]http://lists.w3.org/Archives/Public/public-media-capture/20
14Aug/att-0019/Finding_an_-Ideal-_Algorithm__4_.pdf
[12]
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
Bug walkthrough
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:
[13]http://lists.w3.org/Archives/Public/public-media-capture/20
14Aug/att-0018/August_Media_Capture_Bug_Walkthrough__1_.pdf
[13]
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:
[14]https://docs.google.com/presentation/d/1pql9zGhtX8r84qdnGFu
SZM0aOMOHBxXVbkJsXwbCI0k/edit#slide=id.p
[14]
https://docs.google.com/presentation/d/1pql9zGhtX8r84qdnGFuSZM0aOMOHBxXVbkJsXwbCI0k/edit#slide=id.p
Topic: jib Talk about "bare"
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...
[15]https://www.w3.org/Bugs/Public/show_bug.cgi?id=26526
[15] 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.
Summary of Action Items
[End of minutes]
Received on Monday, 11 August 2014 12:44:05 UTC