See also: IRC log
<scribe> Scribe: Josh_Soref
Travis_MSFT: Thank you to everyone who was able to review the document and provide feedback
... there was a request from the DAP WG to publish it as a FPWD
... that notice went out about a week ago
... darobin has volunteered to do the publishing work
<stefanh> there is the same request from the webrtc group
Travis_MSFT: he was on vacation, and I believe he'll get it out some time this week
burn: This is a document
... I understood that documents that aren't Specifications don't get FPWD
... and instead get published as Notes
Travis_MSFT: I had the same concern
... Initially I marked it up differently
... If you have an issue, let's talk about it
burn: I agree it should be published
... I was just surprised to see FPWD for a non REC track document
stefanh: I acted on darobin's suggestion of doing FPWD
burn: this is based on my 13 years of experience in W3C
... but darobin also has lots of experience in W3C
... I'll just talk with darobin
stefanh: I just want it to be published
Travis_MSFT: the document hasn't changed significantly since I did the CfC
... Josh_Soref gave feedback but indicated it wasn't critical to FPWD
... If I have time, I may squeeze them in before publication
stefanh: The next point, is on the next step
... is there any activity we can make to get more input
Josh_Soref: note that FPWD is one way to get more input
Travis_MSFT: I had a suggestion
... I know we originally proposed this document so we could unify on a set of scenarios and goals
... for this TF
... what we have today is a document that has a really good description of a high level usage scenario
... what I think the next steps for the document are
... is to use the scenarios we've agreed on
... to extract the functional requirements for the API
... I know we're focusing on getUserMedia()
... but next we should focus on the features that media streams will need
... does that sound reasonable?
stefanh: to me that sounds reasonable
adambe: I agree
hta: Given that we aren't starting with a clean slate
... we'll want to aim for a non disruptive approach
Travis_MSFT: I agree with that sentiment
... one approach we could take
... I could take an action item to attempt to draft some requirements
... and we could keep iterating
hta: yes
... do you think you should write up a list that includes the WebRTC UCs?
... or anything in addition to those?
Travis_MSFT: I think that's certainly worth a shot
... I can certainly look into them again
hta: it would be nice if we had a single list of requirements
Travis_MSFT: I agree
ACTION hta to action Travis to Draft a setup of initial requirements based on the WebRTC and the Scenarios document
<trackbot> Created ACTION-25 - Action Travis to Draft a setup of initial requirements based on the WebRTC and the Scenarios document [on Harald Alvestrand - due 2012-03-06].
http://lists.w3.org/Archives/Public/public-media-capture/2012Feb/0041.html
burn: Even though I suspect many people have read this document
... I think it would be helpful for me to go over this to make sure we're on the same page
... my task was to come up with an API for capabilities
... Capabilities and Hints are fairly closely tied together
... I've always had that opinion, but I hadn't found a way to explain this
... I spoke with fluffy
... App Developer = Web Developer
... When a web developer says "i need a video of a certain size"
... When they're told "that's just a hint"
... that's frustrating for application authors
... we tried to design a way to make it workable for both the Browser (UA implementer)
... and the App Developer
... that amounts to Constraints
... the goal was to develop Constraints that we a way for a Web Developer to express what they'd like
... in a meaningful way to the browser
... but also a way to express preferences
... so if they couldn't get THIS, then try to get me THIS
... and also to provide a way for the Web Developer to specify a minimum
... the browser also needs to be able to handle Congestion on the Network
... or User resizing their screen
... it would be unfortunate for the browser to have to go back to the Application author
... and get a new answer
burn: we think that a Constraint structure satisfies these requirements
... I'm going to talk about this Constraint structure
... There's a possibility that we need to distinguish between Constraints for Peer connections
... and Constraints for just getting media in the first place (not using a Peer connection)
... I believe that this design can work for both
... but we may need some things to make the different cases easier
... With respect to the Constraint API
... I don't think there's much to an API beyond an API for hints
... I suggest that it should be in the place where we discussed hints
... I propose that we use an ordered list of Key-Value-Pair
... approximately Key-Value-Pair
... for "is it mandatory" -- we'll talk about that later
... You specify with a priority, a specific constraint
... Skip past the list of constraints
... in the email
... you'll see that I have a JSON list here
... with 0...5 keys, those are priority orderings
... 0 is the highest priority
... there are priority numberings, and then specific constraints
{0:{video-min-height:600, mandatory:true},
1: {video-max-aspectratio:1.333333333333},
2: {video-min-timebetweenrefframes:20},
3: {video-max-bandwidth:500, mandatory:true},
4: {video-min-framerate:30},
5: (video-autowhitebalance:on}}
[ burn explains the Example ]
burn: I'm specifying a minimum height of 600 pixels
... a browser will if it has to choose between an aspect ratio or a height constraint
... I've indicated that I've preferred that it meet the height constraint (because the priority is higher)
... I've also indicated a mandatory flag on some constraints
... for my application, I don't want to start without that minimum height and that maximum bandwidth
... I want an error from the browser instead
... indicating which couldn't be satisfied
... Before I continue
... are there any questions?
adambe: I have a question about Mandatory
... there's a Mandatory at position 0 and a Mandatory at position 3
... how does it relate to the optional item at position 1?
burn: that's correct
... because I don't think bandwidth relates to aspect ratio
... I think a more interesting thing is between 2 and 3
adambe: XX2
burn: the priority ordering is to be used to resolve conflicts between constraints
... there's likely a conflict between height and aspect-ratio
... I think you're asking why not list mandatory before optional
... I could as an application author put them with 1 and 2 after 3
... but I don't really care
Travis_MSFT: it might be interesting
... to talk through an algorithm for evaluating the example
burn: I'll talk about it loosely
... I don't have it written out
... please don't hold me to being a computer
... approximately speaking
... as an implementer, reading through this
... you would attempt to satisfy every constraint
... starting with the lowest number (highest priority)
... if you satisfy it, you move on
... if you don't satisfy it, and it's marked as mandatory, you must fail
... out of all the possible video resolutions I can choose
... I am able to choose one that can satisfy this constraint
Travis_MSFT: you might look at your available video formats
... and you'd narrow things down
... you'd present to the user
... or fail if you run out of things
derf: Tim Terriberry, From Mozilla
... you might be able to satisfy each in isolation
... but not in combination
burn: for all the ones I marked as mandatory, I need them
... if I could satisfy min-height or max-bandwidth, but not both
... we could talk about that
... but I'd like to talk about that later
... derf, is it ok if we note that and come back to it?
derf: that's fine
burn: as you're narrowing
... if the constraint you're processing leaves you with the empty set
... and that constraint was not mandatory
... then I think the process should undo that constraint and move on to the next step
Travis_MSFT: because it isn't a mandatory constraint
... there isn't a need to satisfy that particular constraint
... and you continue processing
burn: and the ones that are higher priority matter more
... we should say that the algorithm processes these in priority order
derf: you're going to run into the problem of a conflict between a priority order optional constraint
... and a mandatory constraint
fluffy: I think you want to do mandatory constraints first
derf: I think fluffy 's suggestion makes more sense than burn 's
burn: I'm fine with that
... when I proposed this approach
... it was based on SSML 1.0
... when we discussed this, we didn't discuss this very in detail
... we may be able to change the structure
... all mandatory before optional
adambe: [...]
burn: I wanted to do clarifying questions first
fluffy: we can design the algorithm down the road
burn: Travis_MSFT was trying to talk through an algorithm to understand what we're doing
Travis_MSFT: and that's been met
burn: are there any other clarifying questions about constraints?
[ none ]
burn: ok, then let's go on to the capabilities
... a call to getCapabilities()
... this was supposed to be focusing on the Fully Trusted case
... that's what anant was talking about in the previous call
... I didn't attempt at all to even attempt to describe things for the less trusted case
... it returns a JS Array for each device/media stream/channel
... we may need to figure out how to describe that
... for now I put it per device
... for each device, it's going to list all of the relevant constraints
... but they're the constraints for the device
... camera 1 has no resolution less than 800
... no smaller resolution than 600
... similarly for camera 2
adambe: his is specific constraints
... this is not a profile
... you can't expect all of these to work together
burn: correct
... it doesn't mean that 800x600 is a valid resolution
... and I did this on purpose
... for camera 2, I intentionally picked values where with and height don't match up
... you're likely to get 1920x1080
... or 1600x1200
Travis_MSFT: I like this
... you've anonymized the camera names
... and you've forced the authors to decide what the want
burn: that was the intent
... for your application, you know what's important
... you may want a maximum,... if you're doing a thumbnail, you may not want something 2000px wide
Travis_MSFT: there are no units here
... is that because each thing has a defined unit?
burn: if you scroll up in the email
... for every constraint, I give a unit
... I had us skip over that
... but I think it's extremely important to specify the unit
Travis_MSFT: can you give an example of wanting different units for a given field
burn: possibly someone may want width in display centimeters instead of px
Travis_MSFT: which they could figure out on their own
burn: we tried not to go overboard on a list of constraints
... I'm not even saying this is the initial set
... I knew if I didn't come up with a reasonable number of example constraints
... I'd get yelled at
Travis_MSFT: I'm not proposing
... I like having unitless when I get data back
... because my code will do math on it
fluffy: I have a hard time thinking of an example
... say you wanted both px and cm
... we could just add a new constraint width-in-cm
Travis_MSFT: should we plan ahead and call it video-min-width-px
burn: I don't think we need to focus on that now
... are there any other clarification questions at this point?
Travis_MSFT: the getCapabilities() is that a call that can be called at any time
burn: I think that question is orthogonal to this discussion
... it's important, but I purposefully left that out of this discussion
... there are other people better suited for discussing that
... there may be something for working out the reduced privilege case
... and that's something we can work out later
Travis_MSFT: I agree with that
... in my opinion, it sounds very reasonable
... and it seems that we could adapt for a Non-Trusted Environment
Josh_Soref: are we ok with the ua scaling/padding out?
derf: my answer would be no
... the QT apis that Apple have
... if you ask for a particular resolution
... it will give you something
... and there's no way to shut this off
... I think it's a terrible thing from an app developer's perspective
Travis_MSFT: I'm holding a BlackBerry device
... I'm browsing a min-video-width of an hd size
... the hardware on my device can't stream that
... it's doing a disservice to the user
... because the UA follows the letter of the law
<tim> I think the answer is different for manditory vs no manditory constraints.
Travis_MSFT: I'm ok with the UA doing things differently
adambe: I think web developers will use these constraints cautiously
... because they will lock people out of their services
Josh_Soref: you're being way overoptimistic
fluffy: can you give us a specific case for lying?
[ Josh_Soref describes a case where two people are using a conferencing application because one of them has it, and the other needs to communicate with that person. The two users of the software can tolerate lower quality content because they're doing a task and the application is available. But the application insists on a higher resolution than the coerced (mobile) user's User Agent can provide. ]
Travis_MSFT: the case you described as a downgrade of constraints
... willfully violating the minimum constraints
<stefanh> fluffy: I don't know how to design a browser that second guesses
Travis_MSFT: are there cases of wanting to violate the maximum constraints?
derf: for example downgrading from hd to thumbnail is certainly possible
... but there's often a serious case of performance impact
<tim> We really need to be clear if these are manditory constrainst we are atalking about.
derf: the app needs to know about that
... in principle, I don't have a problem with the UA lying on behalf of the User
... I can certainly see sticking a pref somewhere for an expert user
... in practice, I don't think the pref will be flipped
burn: I think in the small mobile device
... the browser will lie when it thinks it's in the best interest of the User
... and that's fine
... I've chosen to use a version of Safari on my iPhone with this little screen
Travis_MSFT: there's often an option on mobile devices to "browse the mobile web" or "browse the desktop web"
... it's essentially lying
burn: and that's right
... there are definitely times when I want to scroll the screen for the features
fluffy: I don't consider that lying
[ PC explanation ]
<tim> Me
<hta> tim = tim panton
<hta> derf = tim terriberry
<hta> just for the record :-)
tim: about mandatory, or non mandatory constraints, in the context of the UA lying
... I don't have an opinion
Travis_MSFT: in context of that discussion, I wasn't limiting my discussion to either case
... given the API in the proposal, any constraint can become a mandatory constraint
... whichever constraint the UA may choose to deceive the application
... it could apply to any of them
tim: I have a feeling there is a difference, but I'm not sure what it is
... I have a feeling it's worse to lie about a mandatory constraint
... but I can't justify that
Travis_MSFT: the good news from this discussion is that there's tacit agreement that this is a good idea
Josh_Soref: which this
burn: is there anyone who doesn't like this general approach?
hta: I like this approach
Travis_MSFT: I also like it
... I second the notion that there may be a set of constraints which are different between getUserMedia() and Peer
... possibly with considerable overlap
... I like the idea of keeping the list of constraints in a single place
stefanh: there seems to be support for this
... burn: how do you propose that we move forward?
burn: the next step is to rewrite this to address the mandatory-optional structure
... then we need to split out the constraints and design a document for IANA to make the registry
... go ahead and create a registry
<Zakim> Josh_Soref, you wanted to suggest negative values for mandatory? :)
Josh_Soref: the simplest approach for splitting mandatory from optional is to move the mandatory to the negative space (you're currently 0 based)
adambe: I think that you don't need the numbering
burn: I think for mandatory, I don't think you need a priority ordering
... either they're all satisfied, or they aren't
... I don't like explicit numbers either
... when you look at JS arrays, they're really lists with lengths
adambe: you actually used an Object not an Array...
... you can use an object with a list
burn: I showed it as an object
... it would be better to show it in list notation
Travis_MSFT: a List in JS gives you indices for free
burn: ...
... I had object in my head because I was trying to figure out how to squeeze Mandatory in there
... We can create two list
fluffy: I like two lists
... on mandatory needing to be ordered
... say you ask for X and not X
... as mandatory
... obviously you get an error
... if we define an error as listing everything you haven't met
Travis_MSFT: in the current syntax, you have to do Mandatory: true
... which makes it explicit that it's mandatory
... if you have two pure lists, it's hard to see which is the mandatory list
adambe: { mandatory: [...], optional: [...]}
hta: you could use [....,mandatory-above-this-line,....]
burn: I'd rather two lists
... it's easier to process
... if you look through mandatory
... and then optional
Travis_MSFT: if you don't have mandatory constraints, you don't need to specify that list
stefanh: maybe we could leave the details later
... was there a decision to move forward?
... I think so
burn: one thing that isn't clear is...
... where the definition should go
... there's a registry that will define constraints
... but that isn't defining what a constraint structure is
... as used in getUserMedia/....
Travis_MSFT: I'd propose we put the Algorithm and what we've defined here into the getUserMedia spec
stefanh: I agree
burn: I'm fine with that
... I just want to define it in one place
... and reference it from everywhere else
Travis_MSFT: getUserMedia or another deliverable
... (getUserMedia doesn't cover Peer)
adambe: now we're specifying the case
... where you're a developer fiddling around with all the settings
... should we also have comments about defaults?
... I had a comment before about developers not using this because they'd be locking people out
burn: to me, if you don't ask for anything, the browser can do anything
fluffy: I think it'd be better to specify defaults
... video specify is it using the largest/smallest?
... audio is easier to pick defaults
adambe: I think defaults should be good
... you should need a reason to not use defaults
burn: my silence is agreement
... I don't have a problem with the group discussing it after I put a basic framework in place
hta: that works for me
Travis_MSFT: thinking ahead
... this general system seems like it would work great for recording different media streams
... I think this is heading in the right direction
ACTION burn to flesh this out
<trackbot> Created ACTION-26 - Flesh this out [on Daniel Burnett - due 2012-03-06].
ACTION burn to work to create a draft with fluffy to create an IANA registry
<trackbot> Created ACTION-27 - Work to create a draft with fluffy to create an IANA registry [on Daniel Burnett - due 2012-03-06].
burn: the registry can be created empty
... and we can discuss in W3C later filling it out
Travis_MSFT: I'm also an available resource
burn: I may take you up on that
... in talking with fluffy, the draft 0 deadline is Monday
... because of that, I may need to focus on the Registry first
... don't panic if I don't get the other part done next week
stefanh: when should we have the next call?
... I will be leaning on Anant after MWC
burn: We need to do it after the IETF meeting, and we'll need a doodle
... if anant can get something together in the next week, then we could have a productive call in 2 weeks
... otherwise we need to wait until after IETF
... and we can coordinate that by email
MWC is Feb 27-Mar 1
DAP has a F2F Mar 19-23
IETF has a Meeting Mar 25-30
April 4-9 is Easter week.
WebApps has a F2F Apr 9-13
[ Apr 9-13 is Passover too ]
ACTION hta to create a doodle for the next meeting
<trackbot> Created ACTION-28 - Create a doodle for the next meeting [on Harald Alvestrand - due 2012-03-06].
stefanh: thanks everyone for great input
... and thanks to Josh_Soref for scribing
Travis_MSFT: great discussion
[ adjourned ]
trackbot, end meeting