IRC log of mediacap on 2014-08-05

Timestamps are in UTC.

14:56:49 [RRSAgent]
RRSAgent has joined #mediacap
14:56:49 [RRSAgent]
logging to http://www.w3.org/2014/08/05-mediacap-irc
14:57:04 [Zakim]
Zakim has joined #mediacap
14:57:50 [burn]
zakim, this is mcap
14:57:50 [Zakim]
ok, burn; that matches UW_MdCap()11:00AM
14:58:11 [burn]
zakim, who's here?
14:58:11 [Zakim]
On the phone I see Dan_Burnett, ??P12
14:58:13 [Zakim]
On IRC I see RRSAgent, jib, stefanh, burn, adam, richt, derf, Josh_Soref___, anssik_, timeless, slightlyoff, trackbot
14:58:19 [burn]
zakim, this is Dan_Burnett
14:58:19 [Zakim]
sorry, burn, I do not see a conference named 'Dan_Burnett' in progress or scheduled at this time
14:58:27 [adam]
Zakim, I am ??P12
14:58:28 [Zakim]
+stefanh
14:58:28 [Zakim]
+adam; got it
14:58:33 [burn]
zakim, I am Dan_Burnett
14:58:33 [Zakim]
ok, burn, I now associate you with Dan_Burnett
14:59:32 [Jim_Barnett]
Jim_Barnett has joined #mediacap
14:59:33 [Zakim]
+ +1.425.610.aaaa
14:59:49 [stefanh]
details and proposed agenda for the call: http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0004.html
14:59:57 [Zakim]
+ +1.408.421.aabb
14:59:59 [hta]
hta has joined #mediacap
15:00:17 [fluffy]
fluffy has joined #mediacap
15:00:22 [Zakim]
+ +1.267.934.aacc
15:00:29 [mt_]
mt_ has joined #mediacap
15:00:43 [jib]
zakim, I am aacc
15:00:43 [Zakim]
+jib; got it
15:00:57 [Zakim]
+ +91.22.39.14.aadd
15:01:04 [gmandyam]
gmandyam has joined #mediacap
15:01:05 [Zakim]
+gmandyam
15:01:10 [Zakim]
+[Mozilla]
15:01:47 [fluffy]
zakim, who is here?
15:01:47 [Zakim]
On the phone I see Dan_Burnett, adam, stefanh, +1.425.610.aaaa, +1.408.421.aabb, jib, +91.22.39.14.aadd, gmandyam, [Mozilla]
15:01:49 [Zakim]
On IRC I see gmandyam, mt_, fluffy, hta, Jim_Barnett, Zakim, RRSAgent, jib, stefanh, burn, adam, richt, derf, Josh_Soref___, anssik_, timeless, slightlyoff, trackbot
15:02:09 [ekr]
ekr has joined #mediacap
15:02:18 [Zakim]
+[Microsoft]
15:02:33 [fluffy]
zakim, aabb is fluffy
15:02:33 [Zakim]
+fluffy; got it
15:03:19 [stefanh]
details and agenda: http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0004.html
15:03:29 [Shijun_Sun]
Shijun_Sun has joined #mediacap
15:04:01 [Peter]
Peter has joined #mediacap
15:04:15 [Zakim]
-[Mozilla]
15:04:29 [Zakim]
+Jim_Barnett
15:04:33 [Zakim]
+[Mozilla]
15:05:08 [Zakim]
+ +47.41.44.aaee
15:05:20 [hta]
zakim, aaaee is me
15:05:20 [Zakim]
sorry, hta, I do not recognize a party named 'aaaee'
15:05:25 [hta]
zakim, aaee is me
15:05:25 [Zakim]
+hta; got it
15:05:33 [burn]
scribenick burn
15:06:07 [stefanh]
draft noted June 25: http://lists.w3.org/Archives/Public/public-media-capture/2014Jun/0144.html
15:06:11 [burn]
stefan: first need to approve minutes from last call
15:06:14 [ekr]
I have not reviewed these minutes
15:06:22 [burn]
... any problems with these minutes?
15:06:24 [ekr]
I will do so now, please do not approve until end of call
15:06:42 [burn]
... will return to minutes approval at end of call
15:07:00 [burn]
... next is ideal algorithm, Peter will present
15:07:08 [stefanh]
Peter's slides: http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/att-0019/Finding_an_-Ideal-_Algorithm__4_.pdf
15:07:19 [burn]
Peter: mailed latest pdf this morning
15:07:42 [burn]
... 2 alternatives: min distance and advanced expansion
15:08:13 [burn]
... starting with min distance
15:08:29 [Jim_Barnett]
How does this work with applyConstraints?
15:08:31 [ekr]
q+
15:09:00 [burn]
... key is to calculate distance from all constraints for each possible device mode and choose the smallest
15:09:25 [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.
15:10:00 [burn]
... note that there are different types of distances based on which constraint. for example, sourceId is weighted to require more exact matches
15:10:25 [burn]
ekr: how does this work with cameras that pick a resolution and rescale?
15:11:03 [gmandyam]
q+
15:11:11 [hta]
q+
15:11:16 [burn]
... very difficult for me to enumerate all possibilities
15:11:47 [burn]
justin: if there are no specific modes any choice is arbitary. idea is to do something comparable when you can't enumerate.
15:11:58 [burn]
ekr: this is linear programming problem
15:12:07 [burn]
cullen: no, just pick something reasonable/close here
15:12:25 [stefanh]
zakim ack ekr
15:12:44 [burn]
(can't catch all the discussion here)
15:13:27 [burn]
ekr: I want someone to write me the code that does this in O(nsquared)
15:14:09 [mt_]
zakim, who is noisy?
15:14:11 [ekr]
Sorry, that's *not* n^2
15:14:20 [Zakim]
mt_, listening for 10 seconds I heard sound from the following: 12 (15%), +1.425.610.aaaa (10%), fluffy (49%)
15:14:21 [ekr]
Obviously n^2 is trivial
15:14:30 [hta]
zakim, mute aaaa
15:14:30 [Zakim]
+1.425.610.aaaa should now be muted
15:14:40 [burn]
cullen: not linear programming. yes, combinations of frame rate and resolution will require more checking
15:14:59 [juberti]
juberti has joined #mediacap
15:15:12 [burn]
ekr: let's say camera has different resolutions, each of which comes with a different bitrate.
15:15:45 [burn]
... but you are given a table and not a function
15:15:48 [juberti]
Zakim, who's noisy?
15:15:58 [Zakim]
juberti, listening for 10 seconds I heard sound from the following: +91.22.39.14.aadd (4%), fluffy (96%), Jim_Barnett (4%)
15:16:05 [mt_]
it could be a table or a maximum pixel rate
15:16:12 [burn]
cullen: with table-based approach, can step through optimal value for each table entry
15:16:48 [burn]
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.
15:17:10 [burn]
ekr: so you have to enumerate as a table?
15:17:45 [burn]
cullen: typically told resolution x can be done up to this framerate, y up to this framerate, etc.
15:18:12 [burn]
... so in theory this is infinite, but in practice you don't have to do that.
15:18:40 [burn]
... often this is a function and not a table.
15:18:43 [juberti]
q+
15:19:09 [burn]
jib: doesnt' have to be perfect
15:19:19 [burn]
ekr: no, you told me i had to do this algorithm.
15:19:36 [burn]
cullen: in most cases can describe a closed-form solution
15:20:14 [burn]
ekr: i complained about needing a complete constraint solver 2 years ago
15:20:25 [burn]
jib: a third option is to just make them hints
15:21:06 [burn]
stefan: some implementers are in the team that came up with this. any comments from them?
15:21:13 [fluffy]
q?
15:21:16 [ekr]
q-
15:21:34 [fluffy]
I apoligize - I did not realize there were people on the Q
15:21:37 [burn]
giri: was Euclidean distance rejected?
15:22:52 [mt_]
for the record, having seen Jan-Ivar's code, ekr's concern is pretty valid.
15:22:57 [mt_]
the mac camera is a pain
15:24:21 [burn]
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
15:24:30 [burn]
... you can always use advanced to get what you want
15:24:46 [mt_]
fluffy: this is not euclidean distance
15:24:59 [burn]
... if you don't like the definition of ideal in the standard, then use advanced
15:25:17 [gmandyam]
ack gmandyam
15:25:23 [mt_]
sum of logs!
15:25:35 [mt_]
least squares!
15:25:50 [ekr]
sin(logs)
15:26:08 [stefanh]
q+
15:26:08 [burn]
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.
15:26:22 [hta]
q-
15:26:25 [burn]
... with real drivers and real devices this is doable
15:26:26 [jib]
q+
15:26:44 [hta]
juberti-
15:26:54 [mt_]
q- juberti
15:26:54 [hta]
q- juberti
15:27:13 [Peter]
Zakim, who is muted?
15:27:13 [Zakim]
I see +1.425.610.aaaa muted
15:27:19 [burn]
stefan: what about this large value for strong match? doesn't this make this constraint mandatory or exact?
15:27:23 [Peter]
Zakim, unmute aaaa
15:27:23 [Zakim]
+1.425.610.aaaa should no longer be muted
15:27:40 [Peter]
q+
15:27:53 [juberti]
q+
15:28:57 [burn]
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
15:29:04 [stefanh]
ack me
15:29:31 [burn]
jib: not sure we need close or greater. For example, on framerate why not just CLOSE?
15:29:44 [burn]
peter: couldn't think of a reason
15:30:14 [burn]
(several folks spoke at once in reply)
15:31:02 [jib]
q-
15:31:51 [burn]
Peter: okay with framerate being the same as aspectratio or height/width
15:32:20 [ekr]
q+
15:32:33 [burn]
... also, the intent was that the exact alg doesn't have to be implemented, but result must be same
15:33:10 [ekr]
q-
15:34:19 [burn]
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.
15:34:46 [burn]
... typically you DO have enumerated modes. It works quite well. That's my implementer feedback.
15:35:07 [burn]
(back to slides)
15:35:17 [fluffy]
q?
15:35:36 [burn]
ack Peter
15:35:41 [burn]
ack juberti
15:36:12 [burn]
Peter: this is easy to try out in a spreadsheet
15:37:52 [burn]
... there were some questions raised on the list, shown here in the slides
15:38:10 [burn]
(skipping over advanced expansion option at group request)
15:38:33 [ekr]
q+
15:38:54 [burn]
jib: I like min distance much better than advanced expansion but also like no ideal
15:39:11 [fluffy]
q+
15:39:14 [burn]
ekr: if this is what's required to get ideal, then let's get rid of idea altogether
15:39:29 [burn]
martin: i suggest getting rid of advanced instead
15:39:51 [burn]
jib: i meant that I like impl-spceific version as well, not removing ideal altogether
15:40:24 [juberti]
q+
15:40:27 [burn]
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
15:40:30 [ekr]
q-
15:40:34 [fluffy]
q-
15:41:43 [burn]
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
15:42:56 [burn]
... think ideal is the best thing we have so far for dealing with parameters that are interrelated. ideal needs to be deterministic.
15:43:09 [juberti]
q-
15:43:44 [ekr]
q+
15:44:07 [burn]
stefan: in DC there seemed to be much support for ideal. several people are requesting ideal be deterministic.
15:44:24 [burn]
ekr: yes, make ideal deterministic.
15:44:36 [juberti]
q+
15:44:46 [ekr]
q-
15:45:20 [ekr]
I agree that this text is deterministic. I just don't like it :)
15:45:57 [lgombos]
lgombos has joined #mediacap
15:45:59 [burn]
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?
15:46:01 [burn]
(silence)
15:46:11 [gmandyam]
QuIC is in favor of rejection
15:46:55 [burn]
... Now for call in favor or against. Several folks chiming in on IRC
15:47:35 [burn]
In favor are Dan, Stefan, JIB, (missed name -- from MSFT) in addition to those who have already spoken
15:47:47 [mt_]
Shijun Sun
15:48:10 [burn]
harald: believe we have rough consensus to go ahead. EKR said he could live with it. Giri?
15:48:37 [burn]
Giri: don't understand what this adds, but if chairs call rough consensus then so it is.
15:48:49 [ekr]
harald: if you think there is consensus, can you please formally call it?
15:49:00 [burn]
harald: formal objections are permitted in W3C, are you doing that?
15:49:41 [burn]
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.
15:50:16 [burn]
... no objective comparison of algorithms.
15:50:35 [juberti]
q+
15:50:36 [burn]
Stefan: i hear you saying there could be another algorithm.
15:51:37 [burn]
Giri: it mandates deterministic behavior which is not future proof. ideal is fairly new, not clear we understand it well enough
15:52:03 [burn]
... will not raise formal objection, but caution group against adding features at this point.
15:52:43 [fluffy]
q?
15:53:49 [gmandyam]
q+
15:54:19 [burn]
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.
15:54:21 [jib]
+1
15:54:22 [juberti]
q-
15:54:41 [mt_]
i agree with juberti on this; advanced is merely a poor substitute for programmable selection
15:54:52 [burn]
giri: record the decision and take it to teh mailing list so we can move on.
15:55:01 [gmandyam]
ack gmandyam
15:55:10 [jib]
mt_: agree with mt and justin on removing advanced
15:55:30 [burn]
harald: let's go ahead with min distance version of ideal. further comments would need to be made there.
15:55:30 [adam]
Zakim, who is noisy?
15:55:42 [Zakim]
adam, listening for 10 seconds I heard sound from the following: Dan_Burnett (42%), +1.425.610.aaaa (43%), [Mozilla] (22%)
15:55:43 [hta]
burn: there = on the mailing list
15:56:02 [adam]
Zakim, mute +1.425.610.aaaa
15:56:02 [Zakim]
+1.425.610.aaaa should now be muted
15:56:24 [Peter]
Sure. Sorry about that.
15:57:11 [burn]
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.
15:57:16 [ekr]
thank you
15:57:29 [Peter]
Zakim, unmute aaaa
15:57:29 [Zakim]
+1.425.610.aaaa should no longer be muted
15:57:53 [stefanh]
scribenick stefanh
15:58:06 [fluffy]
sorry but I need to drop at this pont
15:58:13 [Zakim]
-fluffy
15:58:14 [stefanh]
Harald to talk about bug resolution
15:58:23 [ekr]
For future reference, if you do "RESOLVED: " Zakim treats it specially
15:58:32 [stefanh]
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
15:58:54 [stefanh]
Most bugs are about making sure text is clear and consistent
15:59:05 [stefanh]
...called out two bugs for discussion
15:59:08 [ekr]
Or rather RRSAGENT
15:59:37 [stefanh]
...does anyone want to call out any other bug from list
16:00:00 [stefanh]
How long does permissions persist? See slide
16:00:57 [ekr]
q+
16:01:09 [stefanh]
....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?
16:01:29 [stefanh]
....finger-printing related.
16:02:38 [Zakim]
- +1.425.610.aaaa
16:02:56 [stefanh]
Ekr: we should remove label access when closing
16:03:11 [stefanh]
...for consistency.
16:04:08 [stefanh]
Decision: label permissions persist until all devices are closed
16:04:10 [Zakim]
+ +1.425.610.aaff
16:05:00 [stefanh]
Next: 22251 error codes when no devices are available (or some other thing hinders)
16:05:17 [stefanh]
...proposal in slide
16:05:25 [stefanh]
...OK?
16:05:54 [stefanh]
MT: how is source unavailable different from not getting aceess
16:06:10 [stefanh]
...and do we want to make the distinction?
16:06:24 [Jim_Barnett]
q+
16:06:29 [stefanh]
hta: there is a difference (elaborating)
16:07:01 [stefanh]
MT: do we want to expose this to the app (for good and bad)? What info can the app get that is sensitive?
16:07:37 [stefanh]
Jim: in the past we said the app should not know (but that was a loooong time ago)
16:08:13 [stefanh]
Decison: implement proposal
16:08:38 [stefanh]
hta: next slide about how bugs are handled
16:09:24 [stefanh]
...next slide about how people can help out resolving bugs
16:10:32 [stefanh]
Minutes from alst meeting (June 25) approved.
16:10:40 [stefanh]
s/alst/last/
16:11:11 [jib]
my slides: https://docs.google.com/presentation/d/1pql9zGhtX8r84qdnGFuSZM0aOMOHBxXVbkJsXwbCI0k/edit#slide=id.p
16:11:49 [stefanh]
AoB: jib talk about "bare"
16:12:04 [stefanh]
jib: talking through slides
16:12:20 [stefanh]
....meaning of word "constraint"
16:12:31 [stefanh]
...slide 3 look at JS code example
16:13:08 [stefanh]
....slide 4
16:13:49 [stefanh]
....slide 5
16:13:54 [ekr]
q+
16:14:25 [stefanh]
....ideal is the only thing that stands out
16:14:37 [Jim_Barnett]
q-
16:15:07 [stefanh]
Ekr: I don't think I agreed to floating point expressions
16:15:17 [stefanh]
jib: sorry for bad example
16:16:06 [adam]
q+
16:16:09 [stefanh]
.... slide 6
16:16:19 [ekr]
q-
16:17:38 [stefanh]
adam: I have an issue with removing the exact keyword - we may express constraints as objects in the future, would mean ambiguity
16:18:02 [stefanh]
jib: have not seen a proposal for multi prop constraints before
16:18:26 [stefanh]
...can be figured out
16:19:23 [mt_]
fwiw, I'm with jib on this, aside from the point about removing exact
16:19:26 [stefanh]
...slide 7 min max can been different things depending on where they are applied
16:19:36 [mt_]
the aspect ratio thing needs to be solved
16:20:14 [stefanh]
....questions?
16:20:24 [hta]
q?
16:20:33 [adam]
q-
16:20:43 [stefanh]
...were are not tied to ideal
16:20:48 [juberti]
q+
16:20:57 [stefanh]
s/were/we're/
16:21:26 [ekr]
q+
16:21:36 [hta]
q+
16:22:17 [stefanh]
justin: app developer perspective, would be surprised if things fail 'cause a bare value is interpreted as exact
16:22:26 [Peter]
q+
16:22:42 [stefanh]
q+
16:23:01 [stefanh]
jib: naive people seem to thing "mandatory" and not ideal
16:23:14 [stefanh]
s/thing/think/
16:23:21 [mt_]
q+
16:23:58 [stefanh]
juberti: if you move to a new computer you could be surprised
16:24:43 [stefanh]
jib: the developer should use ideal or advanced
16:25:05 [stefanh]
juberti: not the simple apps
16:26:48 [stefanh]
ekr: agree with justin, lingusitic arguments not convincing
16:27:37 [stefanh]
hta: jib introduced foot gun - this is a foot gun
16:28:06 [stefanh]
jib: foot-gun was different
16:28:43 [mt_]
calling back to previous... https://www.w3.org/Bugs/Public/show_bug.cgi?id=26526
16:28:52 [stefanh]
Peter: prefer removing bare values
16:29:14 [stefanh]
stefanh: agree with Peter - my point
16:29:19 [mt_]
q-
16:29:25 [hta]
ack juberti
16:29:27 [hta]
ack ekr
16:29:29 [hta]
ack hta
16:29:31 [stefanh]
mt_: foot-gun argument works for me too
16:29:33 [hta]
ack peter
16:29:36 [hta]
ack stefanh
16:29:37 [stefanh]
ack me
16:30:01 [stefanh]
jib: unfortunate to remove "bare" (lost argument why)
16:30:18 [mt_]
chairs, I formally request a consensus call on this
16:32:52 [stefanh]
hta: only one arguing for bare meaning exact is jib
16:33:40 [stefanh]
dan: do we accept jib's proposal?
16:34:19 [ekr]
We are out of time.
16:34:25 [stefanh]
hta: currently bare means ideal, we have a new proposal to make it mean exact
16:34:55 [stefanh]
...anyone except jib supporting the change?
16:35:00 [stefanh]
...silence
16:35:18 [stefanh]
...result: no concensus to change, so bare will mean ideal
16:35:41 [stefanh]
chairs declared this as consensus.
16:35:44 [Zakim]
-[Mozilla]
16:35:52 [Zakim]
-Dan_Burnett
16:35:53 [Zakim]
-stefanh
16:35:54 [Zakim]
-gmandyam
16:35:54 [Zakim]
-hta
16:35:56 [Zakim]
-[Microsoft]
16:35:56 [Zakim]
-Jim_Barnett
16:35:57 [Zakim]
- +1.425.610.aaff
16:35:59 [Zakim]
-jib
16:36:16 [Zakim]
-adam
16:36:27 [hta]
hta has left #mediacap
16:37:10 [Zakim]
- +91.22.39.14.aadd
16:37:12 [Zakim]
UW_MdCap()11:00AM has ended
16:37:12 [Zakim]
Attendees were 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,
16:37:12 [Zakim]
... +47.41.44.aaee, hta, +1.425.610.aaff
16:51:09 [ekr]
ekr has joined #mediacap
16:52:57 [ekr]
ekr has joined #mediacap
18:31:24 [Zakim]
Zakim has left #mediacap
19:07:12 [fjh]
fjh has joined #mediacap
19:08:20 [fjh]
fjh has left #mediacap
19:12:27 [lgombos_]
lgombos_ has joined #mediacap
19:13:55 [jib]
jib has joined #mediacap
19:22:35 [jib]
jib has joined #mediacap
20:00:36 [jib]
jib has joined #mediacap
20:06:37 [lgombos_]
lgombos_ has joined #mediacap
20:17:13 [jib]
jib has joined #mediacap
20:32:44 [lgombos_]
lgombos_ has joined #mediacap
20:53:58 [jib]
jib has joined #mediacap
21:02:58 [lgombos_]
lgombos_ has joined #mediacap
21:08:36 [jib]
jib has joined #mediacap
21:14:17 [ekr]
ekr has joined #mediacap
21:49:37 [fjh]
fjh has joined #mediacap
21:52:08 [lgombos__]
lgombos__ has joined #mediacap
22:08:22 [jib]
jib has joined #mediacap
22:11:37 [lgombos__]
lgombos__ has joined #mediacap
23:57:02 [lgombos__]
lgombos__ has joined #mediacap