[![W3C][1]][2]

# Media Capture Task Force teleconference

## 28 Feb 2012

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Adam_Bergkvist, Dan_Burnett, Frederick_Hirsch, Harald_Alvestrand,
Josh_Soref, Tim_Panton, Travis_MSFT, derf, fluffy, nstratford, stefanh

Regrets


Chair

    Stefan, Harald_Alvestrand

Scribe

    Josh_Soref

## Contents

  * [Topics][5]

    1. [Scenarios][6]

    2. [Capabilities/Constraints][7]

    3. [Constraint Structure][8]

    4. [Capabilities Example][9]

    5. [Next Meeting][10]

    6. [AOB][11]

  * [Summary of Action Items][12]

* * *

<scribe> Scribe: Josh_Soref

### Scenarios

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

> [Process Document][13]

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

### Capabilities/Constraints

[http://lists.w3.org/Archives/Public/public-media-
capture/2012Feb/0041.html][14]

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

### Constraint Structure

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

### Capabilities Example

{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: I don't know how to interpret a mandatory constrain that has lower
priority than a non-mandatory constrain.

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: All mandatory constraints before optional is kind of what I was
thinking about with my previous comment about the mandatory constrain at
position 3.

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

### Next Meeting

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

### AOB

stefanh: thanks everyone for great input

... and thanks to Josh_Soref for scribing

Travis_MSFT: great discussion

[ adjourned ]

trackbot, end meeting

## Summary of Action Items

[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][15] version 1.135 ([CVS
log][16])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://lists.w3.org/Archives/Public/public-media-
capture/2012Feb/0048.html

   [4]: http://www.w3.org/2012/02/28-webrtc-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #ActionSummary

   [13]: http://www.w3.org/2005/10/Process-20051014/

   [14]: http://lists.w3.org/Archives/Public/public-media-
capture/2012Feb/0041.html

   [15]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [16]: http://dev.w3.org/cvsweb/2002/scribe/