13:41:34 <RRSAgent> RRSAgent has joined #webrtc
13:41:34 <RRSAgent> logging to http://www.w3.org/2013/02/07-webrtc-irc
13:41:36 <trackbot> RRSAgent, make logs world
13:41:36 <Zakim> Zakim has joined #webrtc
13:41:38 <trackbot> Zakim, this will be RTC
13:41:38 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
13:41:39 <trackbot> Meeting: Web Real-Time Communications Working Group Teleconference
13:41:39 <trackbot> Date: 07 February 2013
13:41:58 <dom> s/Teleconference/F2F Meeting/
13:42:16 <dom> stefanh: propose to adapt agenda in light of lack of progress on SDP interface yesterday
13:42:54 <burn> burn has joined #webrtc
13:42:56 <dom> ... instead of SDP agenda item, we'll look at video scaling and cropping in Media Capture Task Force
13:43:02 <hta> hta has joined #webrtc
13:43:23 <gmandyam> gmandyam has joined #webrtc
13:45:15 <timeless> scribe: timeless
13:45:26 <adam> adam has joined #webrtc
13:45:29 <fluffy> fluffy has joined #webrtc
13:45:32 <timeless> Topic: Conclusions Media Cap
13:45:46 <timeless> [ Conclusions Media Cap discussions Boston ]
13:45:49 <timeless> [ hta reads slide ]
13:45:53 <lgombos> lgombos has joined #webrtc
13:45:58 <timeless> hta: any comments/complaints?
13:46:00 <timeless> [ None ]
13:46:26 <timeless> cullen: thanks guys for doing this
13:46:36 <timeless> Topic: MediaStream Cropping
13:46:41 <timeless> [ MediaStream Cropping ]
13:46:47 <timeless> justin: this is a quick set of slides i put together
13:46:52 <ekr> ekr has joined #webrtc
13:47:02 <timeless> ... for how a camera could stream could be provided in an aspect ratio not equal to native
13:47:10 <timeless> [ Problem statement ]
13:47:16 <dom> -> http://www.w3.org/wiki/images/7/76/Aspect_Ratio.pdf Justin's slides on aspect ratio
13:47:22 <timeless> justin: most sensors and cameras are moving to 16:9 capture
13:47:25 <timeless> ... not all cameras are new
13:47:29 <timeless> ... quite a few are 4:3
13:47:43 <timeless> ... it's hard for a full screen gui, especially full screen gui @ 16:9
13:47:51 <Dan_Druta> Dan_Druta has joined #webrtc
13:47:53 <timeless> ... <video/> will always pad to fit
13:47:57 <timeless> ... as opposed to crop to fit
13:48:03 <adambe> adambe has joined #webrtc
13:48:04 <timeless> ... even if <video/> would crop to fit
13:48:20 <timeless> ... you wouldn't want to encode those bits that'd be cropped at the other end
13:48:21 <ekr> rrsagent, draft minutes
13:48:21 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/07-webrtc-minutes.html ekr
13:48:34 <timeless> ... if you're doing local preview, you'd probably want to see the other side
13:48:38 <timeless> ... so people can see if they're out of from
13:48:44 <timeless> [ Solution: crop 4:3 to 16:9 ]
13:49:02 <timeless> justin: discard top/bottom (or left/right if needed)
13:49:17 <timeless> ... Flash's camera api would do this if you asked for an unsupported res
13:49:26 <timeless> ... instangram likes squares, so you could get this
13:49:42 <timeless> ... i'm only concerned w/ crop - letterboxing/pillarboxing are available from <video/>
13:49:54 <timeless> [ General Approach ]
13:50:01 <timeless> justin: opt in, new mandatory constraint
13:50:09 <timeless> ... you want this specific height, width
13:50:24 <timeless> ... width.max,min=640
13:50:33 <timeless> ... height.max,min=360
13:50:36 <timeless> ... allowCrop=true
13:50:48 <timeless> ... if camera supports resolution that falls within mandatory constraints, use that res
13:51:10 <timeless> ... if camera supports res that exceeds mandatory constraints, allowCrop=true to crop satisfy mandatory constraints
13:51:24 <timeless> dom: if this is mandatory
13:51:31 <timeless> ... how does it fit?
13:51:38 <timeless> ... it doesn't seem like a `selection` critera
13:51:48 <timeless> justin: it's more for having chosen a camera
13:51:55 <timeless> ... selecting settings later
13:52:04 <timeless> dom: so, it's a constraint that may be more for control than selection
13:52:09 <timeless> justin: i'm intending it for that, yes
13:52:15 <timeless> burn: this is control, not selection
13:52:31 <timeless> burn: why mandatory { allowCrop }
13:52:43 <timeless> ... instead of mandatory/optional { cropIfNeeded }
13:52:57 <timeless> justin: for optional things
13:53:02 <dom> [this seems to point to a growing divergence between constraints-for-selection and constraints-for-setting]
13:53:02 <timeless> ... if these bounds are not hard bounds
13:53:11 <timeless> ... then it'd be a closest match
13:53:18 <Dan_Druta> Dan_Druta has joined #webrtc
13:53:19 <timeless> burn: if it didn't get it, it didn't get it
13:53:32 <timeless> ... the point of optional constraints is notifying them if they can't be satisfied
13:53:41 <timeless> ... i'm proposing `cropIfNeeded`
13:54:07 <timeless> ... if you put it in mandatory, then it would crop if it needs to and can
13:54:14 <timeless> justin: do you have an example?
13:54:25 <timeless> ... i have a camera that can or can't crop in hardware
13:54:34 <timeless> burn: you might have other optional constraints relating to aspectRatio
13:54:41 <timeless> ... if you get those, you might want cropping,
13:54:46 <timeless> ... if not, you might not care
13:54:52 <timeless> JonLennox: comment, that might make this harder
13:55:07 <timeless> ... i'm often in a situation of VGA camera
13:55:16 <timeless> ... cropping `middle 2/3` makes it easier
13:55:37 <timeless> ... but on a mobile phone in landscape, cropping like that doesn't do what i want
13:55:43 <timeless> justin: i have another proposal
13:55:56 <timeless> ... PeterThatcher mentioned that problem on the ride over
13:56:04 <timeless> fluffy: trying to simplify things
13:56:09 <timeless> ... i assumed crop was always true
13:56:14 <mauro> mauro has joined #webrtc
13:56:22 <timeless> ... if they asked for 16:9 and the input is 9:16, they get a postage stamp
13:56:29 <timeless> ... person rotates phone, problem goes away
13:56:39 <timeless> ... caution that adding complexity won't help people
13:56:47 <timeless> ... what happens if it's mandatory and it comes back `can't`
13:56:55 <timeless> hta: i kind of like the general approach
13:56:59 <timeless> ... but i dislike the examples
13:57:08 <timeless> ... i live in the world of resizable windows and interchangable cameras
13:57:12 <timeless> ... i want to write a UI once
13:57:24 <timeless> ... that will work when the user resizes the window
13:57:32 <timeless> ... and works w/ barberdall camera
13:57:35 <timeless> ... and an HD camera
13:57:54 <timeless> ... i want 1 of 2 things
13:58:01 <timeless> ... either everything in picture field
13:58:09 <timeless> ... or i want picture to fill my field
13:58:17 <timeless> s/barberdall/Barbie Doll/
13:58:25 <timeless> ... in neither situation should we stretch the picture
13:58:31 <timeless> ... remove the talk about min/max, and use the res.
13:58:39 <timeless> ... if you need to crop, crop
13:58:45 <timeless> justin: are you +1'ing fluffy ?
13:58:52 <timeless> ... if you ask for a res, and
13:58:57 <timeless> hta: when media is flowing
13:59:02 <timeless> ... browser knows where it's going
13:59:06 <timeless> ... and it knows where it's coming from
13:59:11 <timeless> ... it will have to do a fit operation
13:59:22 <timeless> ... this is an instruction to browser to crop instead of letterbox
13:59:33 <timeless> ... it doesn't instruct browser to aim for res
13:59:54 <timeless> timeless: he's complaining about the example
14:00:03 <timeless> justin: he's saying constraint pillarbox/crop
14:00:09 <timeless> hta: my real window size is 250:180
14:00:13 <timeless> s/180/172
14:00:17 <timeless> ... it should fit to that
14:00:22 <timeless> ... the best way to achieve that
14:00:30 <timeless> ... i think the browser should do what it needs to do
14:00:51 <timeless> stefanh: with <video/> it can adjust to video aspectRatio
14:01:00 <timeless> ... and there are examples of using <canvas/> to crop
14:01:08 <timeless> ... canvas uses lots of power
14:01:26 <timeless> ... and you lose advantage of sending non-displayed bits
14:01:38 <timeless> justin: i was going to add <canvas/> in an earlier slide
14:01:44 <timeless> ... if we had a Media Stream Processing API
14:01:47 <timeless> [ laughter ]
14:01:54 <timeless> justin: doing thins in the GPU
14:01:57 <timeless> s/thins/things/
14:02:04 <timeless> ... could be very efficient
14:02:14 <timeless> derf: i want to apply this to any video stream
14:02:17 <timeless> ... not just cameras
14:02:37 <timeless> ... according to settings, a <video/> can't have this applied
14:02:40 <timeless> [ Examples ]
14:02:45 <timeless> justin: this isn't the alternate proposal
14:02:51 <timeless> ... just how to use this constraint
14:02:57 <timeless> ... 720p sensor, want 4:3
14:03:07 <timeless> width.max,min=960
14:03:13 <timeless> height.max,min=720
14:03:18 <timeless> allowCrop=true
14:03:34 <timeless> burn: on this topic of do we let browser do its wisest thing
14:03:40 <timeless> ... or let JS dev give a preference
14:03:54 <timeless> ... i don't think it makes it more complex to allow both cases
14:04:05 <timeless> ... it's quite productive to let the user choice
14:04:25 <timeless> ... crop, pad, optional
14:04:36 <timeless> s/optional/best-guess/
14:04:49 <timeless> justin: that's what i heard fluffy say
14:05:03 <timeless> burn: if there's a mismatch between <track> request and destination
14:05:11 <timeless> ... then you can express a preference as an app writer
14:05:18 <timeless> ... for cropping, or padding, or not caring
14:05:32 <timeless> justin: how do you recognize this mismatch when the destination is PeerConnection
14:05:47 <timeless> timeless: shouldn't PeerConnection be able to express a resolution?
14:05:57 <timeless> burn: there's no way to express PeerConnection res as you do for <video/>
14:06:01 <timeless> ... unless we want to add that
14:06:03 <timeless> [ Yes ]
14:06:09 <timeless> burn: that would address a lot of this
14:06:19 <timeless> ... because then it becomes parallel to <video/>
14:06:30 <timeless> fluffy: what i heard by hta was what i said
14:06:37 <timeless> ... a resize by Pretty, Ugly, ...
14:06:46 <timeless> ... for something that crosses the PeerConnection
14:06:55 <timeless> ... if we want that to propagate back to the origin
14:07:06 <timeless> ... the resize will have to go back across the PeerConnection
14:07:16 <timeless> ... involving a renegotiation
14:07:19 <timeless> ... complicated, but very nice
14:07:23 <timeless> ... if no one sets constraints
14:07:32 <timeless> ... but we need a way to say "i'm going to send 640x480"
14:07:43 <timeless> ... by creating a track with that
14:07:50 <timeless> ... and PeerConnection says "oh, that's what i'm sending"
14:07:59 <timeless> ... and then it doesn't negotiate
14:08:04 <timeless> justin: someone changes window size
14:08:11 <timeless> ... and that pushes it all the way back
14:08:22 <timeless> ... if someone changes window size and camera has to stop and restart,
14:08:36 <timeless> ... that yields wacky behavior
14:08:49 <timeless> fluffy: if camera is HD camera
14:08:53 <timeless> s/HD/SIF
14:08:57 <timeless> ... and someone selects QSIF
14:09:04 <timeless> ... allow crop also
14:09:09 <timeless> ... have constraints?
14:09:12 <timeless> justin: proposing
14:09:23 <dom> s/SIF/CIF
14:09:28 <dom> s/QSIF/QCIF
14:09:30 <adambe> adambe has joined #webrtc
14:09:34 <timeless> ... PeerConnection encoder can do cropping internally
14:09:45 <dom> -> http://en.wikipedia.org/wiki/Common_Intermediate_Format CIF on wikipedia
14:10:07 <timeless> ... the point is to give something to the encoder to do efficient scales
14:10:11 <timeless> ... for power of two scales
14:10:18 <timeless> ... for efficient matches of what output can display
14:10:22 <timeless> martin__: the more i think of this
14:10:30 <timeless> ... the more i think i have too many ways to do the same thing
14:10:38 <timeless> ... this seems to belong in the renderer
14:10:50 <timeless> ... we have <video/> it may pillarbox/letterbox/crop
14:11:00 <timeless> ... if we treat PeerConnection as renderer
14:11:10 <timeless> ... then i don't think we need constraints
14:11:25 <timeless> justin: assume a single camera
14:11:27 <timeless> ... no choosing
14:11:31 <timeless> ... for WYSIWYG
14:11:38 <timeless> ... do we have 2 mechanisms or 1 ?
14:11:51 <timeless> ... same way to ask camera for get X res, same way for X' res
14:11:55 <timeless> martin__: two ways
14:12:02 <timeless> ... @ <video/>
14:12:10 <timeless> ... and a way @ Track()
14:12:17 <adam> adam has joined #webrtc
14:12:19 <timeless> ... which may or may not
14:12:29 <timeless> ... if each sink is the only place to set these properties
14:12:35 <timeless> ... the only constraint would be for selection
14:12:36 <fluffy> fluffy has joined #webrtc
14:12:42 <timeless> ... i'm coming to the conclusion that that's pointless
14:12:52 <timeless> ... since in most cases it's orientation of camera that matters most
14:13:02 <timeless> hta: device selection is different topic
14:13:09 <timeless> ekr: whatever camera aspects
14:13:15 <timeless> ... if i plug in arbitrary res
14:13:20 <timeless> ... to <video>
14:13:31 <timeless> ... we expect something as reasonable as possible
14:13:43 <timeless> [ it will rescale in letterbox or pillarbox ]
14:13:50 <timeless> martin__: there's no way to control it
14:13:51 <adam_> adam_ has joined #webrtc
14:13:54 <timeless> justin: is it specified?
14:14:00 <timeless> stefanh: i think it's specified
14:14:12 <timeless> ... you can ask it to auto grow
14:14:17 <timeless> justin: you can never crop
14:14:31 <timeless> ekr: anything really sophisticated
14:14:37 <timeless> ... like Media Stream Processing API
14:14:45 <timeless> ... want something analog to <video/>
14:14:54 <timeless> ... i want to force fit this camera to this stream
14:15:01 <timeless> ... this is a stop-gap?
14:15:12 <timeless> justin: fixing a common problem w/ an efficient+cheap solution
14:15:20 <timeless> ekr: i could live w/ either @source or @sink
14:15:31 <timeless> ... i think i exploded at pushing across Connection
14:15:38 <timeless> stefanh: to martin__
14:15:48 <ekr> ekr has joined #webrtc
14:15:53 <dom> -> http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#dom-video-videowidth HTML5 spec says: "In the absence of style rules to the contrary, video content should be rendered inside the element's playback area such that the video content is shown centered in the playback area at the largest possible size that fits completely within it, with the video content's aspect ratio being preserved. Thus, if the aspect ratio of the playback area does not match
14:15:53 <dom> the aspect ratio of the video, the video will be shown letterboxed or pillarboxed. Areas of the element's playback area that do not contain the video represent nothing."
14:15:57 <timeless> ... to add Crop <media> element?
14:15:59 <timeless> martin__: yeah
14:16:08 <timeless> burn: i think simplest logical model for all of this
14:16:24 <timeless> ... is your Track is used to identify what's natively produced
14:16:31 <timeless> ... and Sink is what you expect to get out
14:16:39 <timeless> ... and influences where you munge
14:16:43 <lgombos> lgombos has joined #webrtc
14:16:49 <timeless> ... so PeerConnection should have things like <video>
14:17:02 <timeless> ... i think constraints on Track still make sense
14:17:19 <timeless> ... so you can ask for High Res from Camera (which offers High Res and Low Res)
14:17:25 <timeless> ... so an app writer can say "these matter to me"
14:17:30 <timeless> ... so sink does processing
14:17:36 <timeless> ... and make it clear that's where it is
14:17:47 <timeless> justin: so that's a proposal to flag it
14:17:53 <timeless> ... at ...
14:18:01 <timeless> burn: allow back propagation or not is up to us
14:18:24 <timeless> ... we could allow settings on PeerConnection to allow settings to go across
14:18:35 <timeless> ... PeerConnection gets to decide how its properties as a sink are set
14:18:46 <timeless> justin: choosing how a device is opened up
14:18:53 <timeless> ... i argue this is analogous
14:18:55 <adam_> adam_ has joined #webrtc
14:19:05 <timeless> ... saying "give me X", or saying "give me X'"
14:19:05 <wonsuk> wonsuk has joined #webrtc
14:19:18 <timeless> ... we could talk about feedback mechanism
14:19:26 <timeless> ... saying `camera can produce X res's`
14:19:55 <timeless> justin: the reason allowCrop=true is there
14:20:03 <timeless> ... is for if you're in Portrait mode
14:20:09 <timeless> ... and you don't want to do cropping
14:20:19 <timeless> ... maybe apps don't ever do that
14:20:25 <timeless> ... give me these pixels no matter what
14:20:32 <timeless> ... give apps some flexibility
14:20:42 <timeless> burn: i'm not recommending taking away control from app writer
14:20:46 <ekr> ekr has joined #webrtc
14:20:46 <timeless> ... question is where to do it
14:20:50 <timeless> ... on Sink or on Track
14:21:07 <timeless> PeterThatcher: is it safe to say we want to avoid reopening camera?
14:21:24 <timeless> ... does app tell browser this?
14:21:38 <timeless> justin: most flexible is to open @high res
14:21:42 <timeless> ... and crop/scale
14:21:48 <timeless> ... cameras have non-0 reset time
14:22:00 <timeless> ... and there's noticable artifact as they stop/restart camera
14:22:18 <timeless> PeterThatcher: so this ...
14:22:28 <dom> ScribeNick: dom
14:22:28 <timeless> justin: changing camera after feedback from sink
14:22:37 <timeless> s/timeless/scribe/
14:22:39 <dom> martin__: the simple response to that is: don't do that
14:22:45 <richt> richt has joined #webrtc
14:23:14 <dom> ... if you're operating in the wrong mode for the display you're opearting in, you'll have to deal iwth it at some point
14:23:15 <timeless> q+ to ask if we want a selection constraint "don't pass a thing which triggers non-0 reset time to camera"?
14:23:30 <dom> ... This proposal is adding processing in the pipeline, which is what I wanted to avoid
14:23:49 <dom> ... leaving constraints for elements that matter for the hardware
14:23:59 <dom> ... anything related to processing should be left up to a processing api
14:24:17 <dom> ... that api would provide a way to crop the video among other things
14:24:33 <timeless> s/so this.../would support controlling the crop at camera open time to avoid other constraints changing and causing re-open/
14:25:03 <dom> justin: that would be great, but that expands the scope of needed work
14:25:30 <dom> martin__: we would need to gather use cases, but that would be much cleaner than trying to push processing through constraints
14:25:53 <dom> adambe: everytime we talk about constraints, it sounds like this could be for sources, tracks, or sinks
14:26:00 <dom> ... that is very confusing
14:26:19 <dom> ... it would be easier if only of these should be the focus of constraints
14:26:31 <dom> burn: I have a similar comment; I think it should apply to two, not three
14:27:03 <dom> adambe: we have the recorder as a sink, for peerconnection, stefanh proposed a transport handler to support setting priority etc
14:27:33 <dom> ... for the MediaElement, you can control the width and height, but I don't know how you would control framerate, etc
14:27:47 <dom> ... It seems more natural to let the sink in control
14:28:36 <dom> Dan_Druta: I heard two aspects of applying constraints for: efficiency, and user experience
14:28:43 <timeless> q- timeless
14:28:48 <dom> ... we should be very clear about it when we talk about pros and cons
14:29:22 <timeless> q+ to ask if we want a selection constraint "don't pass a thing which triggers non-0 reset time to camera"?
14:29:58 <dom> juberti: re the sink driving, that's an important model, but I don't think we should force everyone under that model
14:31:11 <dom> gmandyam: in the media capture call in December, we discussed @@@
14:31:34 <dom> ... you can set options for recording independently of the source
14:32:19 <dom> ... it's not a real-time operation either, so with different considerations than peerconnection
14:33:57 <dom> juberti: setting stuff at the source level doesn't invalidate options at the recording level
14:34:36 <dom> burn: the current state of the settings proposal that we talked about, and the world we live in the current spec
14:34:51 <dom> ... is that of source, tracks, and sinks, you can only set constraints on tracks and sinks
14:35:04 <dom> ... peerconnection doesn't have the same kinf of settings capabilities
14:35:17 <dom> ... there is a need to control what the source provides natively
14:35:38 <dom> ... (if the device cheats e.g. with Apple, there is nothing we can do about it)
14:35:55 <dom> ... we only two, but we have three places
14:36:11 <dom> ... we could set constraints on sources, tracks, sinks
14:36:25 <dom> ... the problem with constraints on peerconnection, you can have multiple tracks going in a peerconnection
14:36:34 <dom> ... each of these tracks could have their own configuration
14:36:57 <dom> ... this is why we've been talking about control on tracks
14:37:38 <dom> ... the problem is to determine whether munging is done at the track abstraction level (and the source is where you set what you want), or at the sink abstraction level (and the track is where you set what you want)
14:37:43 <dom> fluffy: +1 to burn
14:37:49 <dom> ... we're lacking a mental model of all this
14:38:00 <dom> ... there are sources, sinks, and tracks connect them together
14:38:10 <dom> ... the problem with sinks is that we don't have much control about it
14:38:27 <gmandyam> @@@ = At December MediaCap TF call, the participants agreed that width-height combo settings are required for the recording API.  I proposed a possible setting to the mailing list.
14:38:29 <dom> ... as a result, tracks are preferred location for exercising control
14:38:48 <dom> ... if you put constraint on tracks, that affect what's produced by that track
14:39:24 <dom> ... for the sources, the general model is that they look at all the tracks they deliver, and they select the best setting that allow them to satisfy the tracks they're producing
14:39:43 <dom> ... As a result, the mental model should be that Tracks are where we want to set constraints preferably
14:39:48 <dom> juberti: that makes sense to me
14:40:44 <dom> Josh_Soref: regarding the risk of latency attached to reopening a camera
14:40:57 <dom> ... could this be something we can prevent using a constraint?
14:41:19 <dom> ... (preventing from reopening a camera to adjust to a new setting)
14:41:50 <dom> ... On the PeerConnection bit, I've always assumed @@@
14:42:08 <dom> stefanh: I think we need more control over transmission media
14:42:29 <dom> ... we could apply that to tracks, or provide an api in peerconnection per-track
14:43:04 <dom> juberti: I would prefer to apply it via peerconnection
14:43:15 <dom> stefanh: I agree
14:43:27 <timpanton> timpanton has joined #webrtc
14:43:42 <dom> hta: the video element has the CSS3 property to define the cropping/fitting model
14:44:32 <dom> martin__: I don't mind fluffy's suggestions, except that it means you now have two ways to control this for the video element
14:44:45 <dom> ... I'm kind of tempted that we don't have this setting API for that
14:44:51 <dom> ... I'll have to talk with Travis about that
14:45:01 <dom> juberti: I have an alternate proposal
14:45:07 <hta> (the css3 property is called object-fit - it took me a while to find it)
14:45:12 <dom> ... where you define the maximal crop aspect ration
14:45:45 <dom> -> http://dev.w3.org/csswg/css3-images/#object-fit object-fit in CSS Image Values and Replaced Content Module Level 3
14:46:33 <dom> Josh_Soref: in the recorder case, there isn't necessary a post-processing server somewhere else
14:47:18 <adam> adam has joined #webrtc
14:47:31 <dom> ... I can be doing local recording
14:48:36 <dom> juberti: the cropAspectRatio is the process aspect ratio
14:49:16 <dom> @@@: we would make it clear that process stuff would only be used for peerconnection
14:49:19 <dom> cullen: do you have a slide on scaling?
14:49:22 <dom> juberti: no
14:49:35 <dom> cullen: I would love that we say we never scale up
14:49:48 <dom> martin__: disagree, it has to happen in some cases
14:50:24 <dom> ... I think we're talking about processing, and where that processing is applied
14:50:46 <dom> stefanh: to avoid upscaling, we would have to change the mediaelement, since it scales up
14:51:15 <dom> cullen: I was referring to not allowing to scale up at the track level, but I think the length of the line shows I'm losing on that one
14:51:26 <dom> ekr: what does it mean to scale up a track?
14:51:45 <dom> cullen: say you've acquired a sd camera
14:52:14 <dom> ... and then you apply a constraint to the track to get a bigger resolution
14:53:10 <dom> ekr: so I have a SD source that gets a SD track, plugging it into an HD video tag — that will be ugly
14:53:33 <dom> ... if you were to apply to same setting to a peerconnection, the same thing would happen
14:53:51 <dom> ... what you're saying that we should not allow to augment the resolution of a native track
14:53:57 <dom> burn: I think you should have control
14:54:01 <ekr> ekr has joined #webrtc
14:54:05 <dom> ... but fluffy, you're badly schizophrenic
14:54:14 <dom> ... if the constraint you set on the track is the output of the track
14:54:26 <dom> ... and it's ok for munging to happen
14:54:35 <dom> ... then scaling up has to be allowed to happen
14:54:54 <dom> ... what we would want is to have constraints to limit the way the processing can be done
14:55:06 <dom> ... and I think that's what justin is describing
14:55:28 <dom> juberti: the goal is to provide a simpler way to do processing without providing a full-blown graph processing api
14:56:05 <dom> juberti: I worry about an authoritarian model where @@@
14:56:59 <dom> juberti: I don't think it makes sense to send the quadruple amount of bits with no increased quality
14:57:20 <dom> tim: afaict, no browser has implemented object-fit property except opera in the past two years
14:57:36 <dom> -> http://caniuse.com/object-fit object-fit in caniuse
14:58:41 <dom> jan: we're a bit off-track with upscaling
14:58:42 <Josh_Soref> q?
14:58:54 <dom> ... we've talked about source constraints and track constraints
14:59:15 <dom> ... if we had peerconnection.maxWidth, peerConnection.maxHeight, this would cutshort this whole debate
14:59:32 <dom> juberti: I think the peerconnection should have specific control on what each track aspect is
14:59:50 <dom> ... I think we're pretty far afield to specific problem I'm trying to solve here
15:00:52 <dom> martin__: if you're concerned about sending more bits over a PeerConnection than is necessary,
15:01:17 <dom> ... having these settings on PeerConnection allows the PC to say "you've set this higher than what the source provides"
15:02:18 <dom> Jan: I would modify my earlier proposal to have PeerConnection say the aspect ration of what the client will care about (e.g. 4x3)
15:02:28 <dom> ... this is only for peerconnection
15:02:38 <dom> juberti: not really, since object-fit is not implemented
15:02:57 <dom> ... some cameras can do cropping at the hardware level, but not all of them
15:03:07 <dom> ... this would let us solve the problem to these various cases
15:03:22 <dom> ... it's not the general mediaprocessing api, but it has a better RoI
15:03:36 <dom> hta: I think there is some level agreement that cropping needs to be able happen
15:03:46 <dom> ... and the application should be able to have some control over it
15:04:04 <richt> richt has joined #webrtc
15:04:16 <dom> ... there is a fair bit of debate on what the model is on what constraints apply to, and how they show up at the destination of the track
15:04:20 <dom> ... vs modification at the source of the track
15:04:38 <dom> ... We kind of passed that boundary when we agreed to be able to produce multiple resolutions from a single source
15:05:01 <dom> ... I would like to ask martin to write up his concerns on setting constraints on track
15:05:16 <dom> ... and propose an alternate approach
15:06:15 <dom> ACTION: Martin to write up his concerns with using constraints on track to manipulate stuff that might apply to sources and might apply to sinks
15:06:15 <trackbot> Created ACTION-83 - Write up his concerns with using constraints on track to manipulate stuff that might apply to sources and might apply to sinks [on Martin Thomson - due 2013-02-14].
15:06:21 <Josh_Soref> s/dom/hta/
15:06:29 <Josh_Soref> RRSAgent, draft minutes
15:06:29 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/07-webrtc-minutes.html Josh_Soref
15:06:45 <Josh_Soref> Chair: hta, stefanh
15:06:57 <dom> hta: I would like justin to take an action item to describe this constraint in a way that can be included in the document
15:07:17 <dom> ACTION: Justin to describe the constraint for aspect ratio for potential inclusion in the document
15:07:17 <trackbot> Created ACTION-84 - Describe the constraint for aspect ratio for potential inclusion in the document [on Justin Uberti - due 2013-02-14].
15:07:32 <Josh_Soref> RRSAgent, draft minutes
15:07:32 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/07-webrtc-minutes.html Josh_Soref
15:07:51 <adambe> adambe has joined #webrtc
15:08:02 <dom> Topic: Error handling
15:08:10 <timeless> scribe: timeless
15:08:16 <dom> hta: there are cases where we need to provide more information than just the error name
15:08:20 <timeless> s/dom/scribe/
15:08:22 <dom> ... e.g. when there is an sdp error
15:08:25 <timeless> s/dom/scribe/
15:08:34 <dom> ... we want the line of where the SDP arose
15:08:38 <timeless> s/dom/scribe/
15:08:43 <timeless> hta: could people help me refresh my memory?
15:08:52 <timeless> burn: we were trying to finalize the principles
15:08:58 <timeless> ... but we decided we needed to look at specific
15:09:07 <timeless> ... and adambe said we needed to hear from implementers
15:09:12 <timeless> ... as they implement
15:09:20 <timeless> ... instead of "ooh, maybe it will do this, maybe it will do that"
15:09:25 <timeless> ekr: what errors we're seeing
15:09:29 <timeless> ... what you need to return
15:09:32 <timeless> ... how often, and when
15:09:47 <timeless> ... justin and i are debating Error1, or Error2 and Error3
15:10:01 <timeless> ... i mostly see malformed SDP
15:10:09 <timeless> ... a browser screwed it up, or someone mangled it
15:10:21 <timeless> ... a parser of why i didn't like it and what it was
15:10:25 <adambe> s/adambe/Adam Roach/
15:10:41 <timeless> ... Adam Roach pointed out the same need for ICE
15:10:47 <timeless> ... when i look at existing ICE information
15:10:55 <timeless> ... that would be a long way toward knowing what's going on
15:11:02 <timeless> ... a way to detail every check
15:11:05 <timeless> ... would be useful
15:11:43 <timeless> ... very confusing errors
15:11:57 <timeless> ... the only thing in the docs at all is detailed ICE info
15:12:08 <timeless> justin: for Chrome 25, we'll have which line of ICE it choked on
15:12:18 <timeless> ... SDP people complain about Dom11 for not having crypto lines
15:12:39 <timeless> ... we should see if that's useful
15:12:45 <timeless> s/ICE it/SDP it/
15:12:57 <timeless> ... we also created chrome:ice-debugging (not for JS)
15:13:09 <timeless> ... to allow people to debug apps w/o exposing js apis to apps
15:13:15 <timeless> ... we'll have more debugging tools
15:13:20 <timeless> ... before we invent too many more things
15:13:26 <timeless> ekr: most of these errors are programming errors
15:13:41 <timeless> ... i think it's a great idea to have inspectors that are only accessible to programmer
15:13:45 <dom> [The WebSockets API is very careful in not exposing too many details about errors: http://www.w3.org/TR/websockets/#feedback-from-the-protocol ; not sure if there are similar risks in our case]
15:13:45 <timeless> ... you test when you write code
15:13:48 <timeless> ... you don't know why
15:13:53 <timeless> ... once you get it working, it works
15:14:02 <timeless> ... ICE check failed on component 1  to the user
15:14:06 <timeless> ... is unlikely to help the user
15:14:20 <timeless> fluffy: we're putting your email address in our errors
15:14:29 <timeless> ... i don't think we've reviewed the doc for errors that can come up
15:14:35 <adam> adam has joined #webrtc
15:14:36 <timeless> ... we're seeing implementations
15:14:42 <timeless> ... a port of Firefox that does 264
15:14:49 <timeless> ... not being able to report up mismatches
15:14:54 <timeless> s/does/also does/
15:15:02 <timeless> ... problems that you don't see since you only do one codec
15:15:07 <timeless> derf: how we report errors is good
15:15:16 <timeless> ... we need to define what happens when there's an error
15:15:27 <timeless> ... you might parse SDP, it might be valid, but not apply to session state
15:15:36 <timeless> ... mismatched m=lines between offer and answer
15:15:44 <timeless> ... i don't care about behavior, but it needs to be consistent
15:15:52 <timeless> ... we could Tear down the entire call
15:15:59 <timeless> ... we could not access the entire SDP
15:16:06 <timeless> ... or browser crashes
15:16:15 <timeless> ... but it shouldn't be inconsistent between browsers
15:16:27 <timeless> dom: WebSockets API is careful
15:16:32 <timeless> ... about avoiding exposing details
15:16:40 <timeless> ekr: SDP exposes the entire Network Topology
15:16:52 <dom> [so should we drop SDP? >:]
15:16:58 <timeless> ... hta's proposal of statistics
15:17:00 <timeless> ... could be useful
15:17:11 <timeless> ... or if i'm showing my video instead of remote
15:17:15 <timeless> ... if there's no RTP coming in
15:17:21 <timeless> ... re derf's proposal
15:17:28 <timeless> ... there's going to be a whole class of things
15:17:33 <timeless> ... passing bogus SDP
15:17:37 <timeless> ... sometimes that's a parse error
15:17:42 <timeless> ... sometimes that's an application error
15:17:49 <timeless> ... standards should encourage right behavior
15:17:59 <timeless> ... but if you get halfway through applying an SDP
15:18:05 <timeless> ... i can't roll-back
15:18:16 <timeless> ... it might be better for me to close
15:18:30 <ekr> ekr has joined #webrtc
15:18:38 <timeless> juberti: someone had a proposal of how rollback should happen
15:18:42 <timeless> ... two sets of errors
15:18:45 <timeless> ... @SDP layer
15:18:51 <timeless> ... either not eat
15:18:55 <timeless> ... or tear down
15:19:01 <timeless> ... or @SRTP
15:19:13 <timeless> ... and we could blow up in Security layer
15:19:21 <timeless> ... we can make best practices
15:19:27 <timeless> hta: implementer feedback
15:19:35 <timeless> ... /me you can s//
15:19:41 <timeless> s|... /me you can s//||
15:19:46 <timeless> hta: some parse errors
15:19:56 <timeless> ... are easy, some are harder to pin down
15:20:03 <timeless> ... the missing crypto line is hard
15:20:08 <timeless> ... which line is the one to report it for?
15:20:18 <timeless> ... it would be nice to have some descriptive text
15:20:21 <timeless> ... not for applications
15:20:25 <timeless> ... but useful for debuggers
15:20:30 <dom> [oh boy, are we now describing an SDP parser API?]
15:20:31 <timeless> ... or maybe useful advice
15:20:39 <timeless> s/proposal of/action to describe/
15:20:47 <timeless> ekr: missing crypto line v. missing fingerprint
15:20:52 <timeless> ... having looked at jingle
15:20:59 <timeless> ... it wouldn't be at parse time
15:21:02 <timeless> ... it'd be later
15:21:08 <timeless> ... you need a textual report
15:21:17 <timeless> ... "i'm sad for reason: ..."
15:21:28 <timeless> ... parsers print to logging but don't propagate
15:21:35 <timeless> juberti: that landed last night
15:21:40 <timeless> ... in Canary
15:21:57 <timeless> stefanh: no big need for adding errors
15:22:11 <timeless> ... but more on what happens when you encounter an error
15:22:32 <timeless> hta: this is part of procedure description for setLocalDescription/...
15:22:37 <timeless> ... we left off precise language
15:22:49 <timeless> ... on the idea of getting the general principles before we write precise language
15:22:58 <timeless> ... i think it's the time to write precise language
15:23:21 <timeless> [ Coffee Break for 15 minutes ]
15:55:27 <ekr> ekr has joined #webrtc
15:55:43 <lgombos> lgombos has joined #webrtc
15:55:46 <timeless> Topic: Data Channel API
15:55:51 <adam> adam has joined #webrtc
15:56:04 <dom> dom has joined #webrtc
15:56:22 <dom> RRSAgent, draft minutes
15:56:22 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/07-webrtc-minutes.html dom
15:56:26 <timeless> jesup: W3 flavor of data channel discussion
15:56:36 <timeless> ... i hope less controversial than the IETF flavor
15:56:43 <timeless> ... maybe we'll make a decision
15:56:48 <timeless> [ DataChannel JS API]
15:56:52 <timeless> s/]/ ]/
15:56:58 <dom> i/hta: could people help me refresh my memory?/ScribeNick: timeless
15:57:00 <dom> RRSAgent, draft minutes
15:57:00 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/07-webrtc-minutes.html dom
15:57:03 <timeless> jesup: feedback from Mozilla Devs working on those apis
15:57:07 <timeless> ... has been generally positive
15:57:14 <timeless> ... it's worked the way they've expected
15:57:21 <timeless> ... primary unresolved area
15:57:33 <timeless> ... is how to create data channel and how it interacts w/ createOffer/createAnswer
15:57:38 <timeless> [ Changes to API ]
15:57:55 <timeless> jesup: IETF 85 ... protocol to add data channels to agree on interop
15:58:07 <timeless> martin__: the web socket idea of a sub protocol?
15:58:11 <timeless> jesup: i guess so
15:58:15 <timeless> ... an IANA registered string
15:58:27 <timeless> ... if you do this, you agree you're exchanging in some form
15:58:34 <timeless> ... since we're mirroring WebSocket
15:58:40 <timeless> ... this is that thing from WebSocket
15:59:00 <timeless> adambe: latest version of WebSocket lets you say you accept multiple protocols?
15:59:17 <timeless> jesup: but you can only use one once it's in flight
15:59:19 <dom> -> http://www.iana.org/assignments/websocket/websocket.xml WebSocket Subprotocols registry
15:59:31 <timeless> ... our way to create data channel is different from WebSocket
15:59:36 <timeless> martin__: no need to negotiate
15:59:38 <timeless> ... it's with itself
15:59:55 <timeless> jesup: you would need a way to signal back agreement, complexity for no reason
15:59:58 <timeless> [ Proposal ]
16:00:05 <timeless> jesup: like yesterday, but w/o SDP
16:00:10 <timeless> ... all the JS layer
16:00:22 <timeless> .. no DataChannel unless you call pc.createDataChannel()
16:00:23 <wonsuk> wonsuk has joined #webrtc
16:00:24 <mreavy> mreavy has joined #webrtc
16:00:27 <timeless> s/../.../
16:00:45 <timeless> jesup: you can call it any number of times before createOffer/createAnswer
16:01:01 <timeless> ... if called after initial createOffer, it triggers a negotiationneeded
16:01:09 <timeless> hta: createOffer or setLocalDescription?
16:01:23 <timeless> jesup: before SDP or after SDP is the distinction
16:01:30 <timeless> ... relative ICE things
16:01:43 <timeless> hta: what if they createOffer throw it away and call createOffer again?
16:01:49 <timeless> jesup: maybe `initial` is wrong
16:02:13 <timeless> hta: one solution is first call triggers negotiationneeded
16:02:23 <timeless> jesup: createStream throw away stream, stream is still there
16:02:27 <timeless> ... same for data channels
16:02:35 <timeless> martin__: seems like there's some need for ...
16:02:45 <timeless> derf: we had an AI for when negotiationneeded fires
16:02:54 <timeless> martin__: and when other things fire after
16:02:57 <timeless> [ Problems ]
16:03:27 <timeless> jesup: unless you sniff SDP, you won't know if there was a data channel
16:03:31 <martin__> the question is a) when onnegotiationneeded fires and b) when it clears such that it could fire again
16:03:43 <timeless> ... we can't add an m=line in an answer
16:03:54 <timeless> ... if you want it,  you'd need a second round of offer-answer
16:03:57 <timeless> [ Example ]
16:04:10 <derf> martin__, I suspect the answer to b) is that it can always fire again.
16:04:24 <timeless> [ Decisions! (Please!) ]
16:04:45 <timeless> jesup: use createDataChannel to trigger m=application line
16:04:57 <timeless> ... if needed, createDataChannel will call negotiationneeded
16:05:25 <timeless> martin__: need to be >0 open channels to include m=application
16:05:36 <timeless> ... because you could create a data channel, close it, and then createOffer
16:05:56 <timeless> hta: i'm fine w/ this
16:06:28 <timeless> ... is that what you want?
16:06:31 <timeless> jesup: basically
16:07:26 <ekr> ekr has joined #webrtc
16:07:26 <timeless> XXX
16:07:34 <timeless> paul: namespace for sub protocols?
16:07:41 <timeless> ... subordinate to webrtc channel namespace?
16:07:49 <timeless> ... should be same namespace as websocket subprotocols?
16:07:54 <timeless> ... i don't know that
16:07:55 <martin__> ACTION jesup to if we replace onnegotiationneeded conditions to the same as those we have for addStream()
16:07:55 <trackbot> Error finding 'jesup'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
16:08:04 <timeless> jesup: i think it's an IANA register
16:08:20 <timeless> paul: just want a procedure
16:08:23 <martin__> ACTION Randell to make onnegotiationneeded conditions the same as those we have for addStream()
16:08:23 <trackbot> Error finding 'Randell'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
16:08:23 <timeless> ... to define these
16:08:35 <timeless> TedHardie: it's a first come first server registry
16:08:40 <timeless> ... set up by WebSocket folks
16:08:45 <timeless> paul: single level name
16:08:53 <timeless> hta: you can define protocols for data channel
16:09:08 <timeless> ... that don't work well w/ web sockets
16:09:15 <timeless> ... that might be an argument for different registry
16:09:26 <timeless> jesup: not an argument for different registry, just don't use w/ websocket
16:09:36 <timeless> TedHardie: for this room, push to IETF side
16:09:38 <timeless> jesup: i agree
16:09:48 <timeless> ... what `protocol` means shall be defined by IETF
16:09:51 <martin__> OK, randell isn't a registered user
16:10:05 <timeless> Dan_Druta: protocol isn't limited to registry, righ?
16:10:08 <timeless> s/righ/right/
16:10:17 <timeless> jesup: if it wishes to ignore the registry, nothing can force it
16:10:26 <timeless> jesup: I yield the remainder of my time
16:10:40 <timeless> stefanh: we made a decision to go w/ this w/ hta's amendment
16:11:10 <dom> ACTION: stefanh to get Randell to make onnegotiationneeded conditions the same as those we have for addStream(
16:11:10 <trackbot> Created ACTION-85 - Get Randell to make onnegotiationneeded conditions the same as those we have for addStream( [on Stefan Håkansson - due 2013-02-14].
16:11:16 <timeless> [ Stats ]
16:11:22 <timeless> i/Stats/Topic: Stats/
16:11:58 <timeless> [ hta defines Microphones `chair at desk`, `speaker at wireless`, `individual at center mic` ]
16:12:02 <timeless> [ New API ]
16:12:20 <timeless> hta: changing datatype of what comes back on stats report
16:12:30 <timeless> ... to be an object that's able to tell you the identifiers
16:12:36 <timeless> ... and able to get those objects
16:12:42 <timeless> ... each object has type and id
16:12:53 <timeless> ... and set of names, and a getter to get value for name
16:13:00 <timeless> juberti: like a Dictionary?
16:13:06 <timeless> [ New Objects ]
16:13:11 <timeless> hta: exactly
16:13:18 <timeless> ... Dictionaries are a name value mapping
16:13:27 <timeless> ... I decided this is a fine way of putting stuff into documentation
16:13:33 <timeless> ... that can be checked with a WebIDL parser
16:14:46 <timeless> hta: sequence returned order is somewhat curious
16:14:51 <timeless> ... depends on alphabetical names
16:14:59 <timeless> ... and based on hierarchy
16:15:38 <timeless> ... things defined in derived dictionary are added to the sequence (sorted) after the original dictionary's list
16:15:49 <timeless> ... this is a pain in the posterior
16:16:02 <timeless> ... i looked into the state of a Dictionary
16:16:11 <timeless> ... and how to return one from a function
16:16:31 <timeless> ... the answer i got is that `it's doable, w/ 3 experts in DOM state manipulation`
16:16:42 <timeless> ... so i propose no dictionaries
16:16:51 <timeless> ... [as from the previous slide ]
16:17:00 <timeless> [ Principles of object definition ]
16:17:10 <timeless> hta: use Dictionary as documentation method
16:17:15 <timeless> ... pointers are done via ID
16:17:42 <timeless> ... Keep it simple (and well defined)
16:17:52 <timeless> martin__: i'm unsympathetic to the hard to implement
16:18:06 <timeless> hta: did you implement something that fully implements dictionary
16:18:13 <timeless> martin__: one thing i didn't deal w/ was extra params
16:18:30 <timeless> martin__: the idea that you'd have trouble passing objects to js as hard to do...
16:18:36 <timeless> ... we've discussed this at length
16:18:52 <timeless> ... the things we're getting are key-value-pairs w/ primitives and maybe arrays
16:19:00 <timeless> ... but you're forcing them to use unfamiliar constructs
16:19:04 <JeromeMarcon_> JeromeMarcon_ has joined #webrtc
16:19:30 <timeless> adambe: JS has a way to deal w/ KeyValue pairs
16:19:40 <timeless> ... couldn't we say we're returning a JS object w/ these values
16:19:43 <timeless> ... and not promise order
16:20:09 <timeless> ... that gives us enumeration and lookup from JS
16:20:14 <timeless> hta: one vote for Dictionary
16:20:18 <timeless> ... and one comment for Object
16:20:28 <timeless> fluffy: in favor of making this work
16:20:29 <dom> [I think you can use [NoInterfaceObject] interface to describe regular JavaScript objects]
16:20:41 <timeless> ... keen to restrict semantics to that of Dictionary
16:20:50 <timeless> ... if function calls get mapped to thing, this would be a disaster
16:21:02 <timeless> ... nearly every language has something like Dictionary
16:21:16 <timeless> ... I want Dictionary semantics, ... ASN.1 - i don't care
16:21:45 <timeless> ekr: is there an argument against these being properties
16:21:52 <timeless> ... that isn't rooted in implementation details
16:22:25 <timeless> ... why isn't names() and getValue() just properties of the object
16:22:48 <timeless> ... one is that it's Lousy for JS user
16:22:57 <timeless> ... and one that it's inconvenient for the C++ WebKit dev
16:23:04 <timeless> ... is it just PITA for WebKit?
16:23:37 <timeless> ... i'd have expected that a param was property index (.keys)
16:23:45 <timeless> ... and reference by .<> or [<>]
16:23:52 <timeless> fluffy: you expect Dictionary
16:24:12 <timeless> ekr: what's the merits of this other than implementation?
16:24:13 <jeromemarcon> jeromemarcon has joined #webrtc
16:24:28 <timeless> juberti: if it was []/. instead of getValue()
16:24:38 <timeless> dom: i understand Dictionary is a pain
16:24:42 <timeless> ... but why not Interface
16:24:48 <timeless> ... this is similar to GeoLoc in a way
16:24:57 <timeless> ... they use [NoInterfaceObject]
16:25:10 <timeless> ... we shouldn't define our own way of declaring our own local data
16:25:17 <timeless> ... WebIDL w/ interfaces provides that
16:25:23 <timeless> martin__: use partial interfaces
16:25:33 <timeless> hta: partial interfaces w/o source
16:25:45 <timeless> juberti: why objects
16:25:54 <timeless> ... couldn't we make them more like regular dictionaries?
16:26:28 <timeless> hta: if `void (RTCStatsReport statsReport)` with a map
16:26:43 <timeless> hta: Dictionary provides some guarantees and constraints i don't want
16:26:53 <timeless> martin__: it doesn't need to be a Dictionary
16:27:00 <timeless> ... it could be [] or .
16:27:10 <timeless> ... you can do this in JS in browsers w/ handlers
16:27:23 <timeless> ... i don't see a problem w/ implementation
16:27:30 <timeless> ... if you aren't backing directly w/ C++
16:27:48 <timeless> martin__: we need a map
16:27:56 <timeless> adambe: `statsReport`
16:28:00 <timeless> ... report is a complete thing
16:28:04 <timeless> ... and you have subreports
16:28:12 <timeless> ... you want two levels
16:28:18 <timeless> ... you could guarantee a timestamp, type, id
16:28:24 <timeless> ... why are those on a different level?
16:28:43 <timeless> martin__: individual stats object could be created at different times
16:29:07 <timeless> adambe: move timetamp/id into getValue?
16:29:25 <adam> adam has joined #webrtc
16:29:39 <timeless> ... i'm disregarding the top object
16:29:47 <timeless> [ RTCStatsReport ]
16:30:19 <timeless> adambe: i don't see why we need a stats.type v. stats.getValue(x).
16:30:27 <timeless> hta: how do you specify that in WebIDL
16:30:38 <timeless> martin__: i'd rather show example code for exact number of packets
16:30:55 <timeless> dom: I think in WebIDL, your additional data structure is generic
16:31:09 <timeless> ... Object is a Map
16:32:27 <timeless> fluffy: don't drive from WebIDL
16:32:31 <timeless> ... figure out from how you want to use it
16:32:37 <timeless> ... i think it generally does
16:32:42 <timeless> hta: i don't have slides w/ code
16:33:04 <dom> s/is generic/inherits from a core interface
16:33:38 <timeless> hta: if i have dictionary foo { int blah; }
16:33:45 <timeless> ... i can't have additional attributes
16:33:53 <timeless> martin__: no one sees the dictionary type
16:34:06 <timeless> ... so you can have dictionary privatefoo : foo {...}
16:34:12 <timeless> hta: they are unobservable?
16:34:28 <timeless> fluffy: this applies to any language w/ dictionary inheritance
16:34:38 <timeless> ekr: no opinion about dictionaries permitting this behavior
16:34:47 <timeless> ... it's important to be able to add additional properties
16:34:54 <timeless> ... if that can't be made to work, that's death for dictionary
16:35:08 <timeless> jan: i think Dictionary doesn't have a sequence on purpose
16:35:12 <timeless> ... as a useful constraint
16:35:49 <timeless> ... you can't know if a caller had a meaning in their sequence or not
16:35:59 <timeless> ... a sequential dictionary would be a less restrictive type
16:36:34 <timeless> fluffy: write in the spec that objects will inherit from the type defined in the spec
16:36:36 <timeless> hta: sold
16:37:32 <timeless> adambe: so, StatsReport is a map?
16:37:42 <timeless> ... and we need unique key for each object?
16:37:47 <timeless> hta: key was unique in that object
16:38:08 <timeless> juberti: top thing is map->RTCStatsObject
16:38:45 <timeless> ... the dictionary's become interface *RTP* : RTCStatsObject
16:39:02 <timeless> s/.../hta:/
16:39:03 <gmandyam> gmandyam has joined #webrtc
16:39:34 <timeless> martin__: RTCStatsReport is second level of ugly
16:39:39 <timeless> hta: it's just a map
16:39:44 <adam> adam has joined #webrtc
16:39:49 <timeless> martin__: a map of id's to things
16:39:53 <timeless> ... but why do we need ids?
16:39:58 <timeless> ... why are they the key?
16:40:06 <timeless> ... why not rtcstatsobject.type ?
16:40:19 <timeless> ... given id's aren't stable across calls
16:40:28 <timeless> adambe: at time X
16:40:30 <timeless> ... you get a report
16:40:38 <timeless> ... check stats for some subreport component
16:40:42 <timeless> ... at time Y
16:40:45 <timeless> ... you get a report
16:40:49 <timeless> ... you want to compare reports
16:41:13 <timeless> ... you need to know that stats report is comparable
16:41:52 <timeless> "Comment 22"
16:41:59 <timeless> martin__: indexing by type
16:42:10 <timeless> ...  i need to go back to usage patterns
16:42:20 <timeless> hta: by id gives you one
16:42:33 <timeless> ... by type could give you more
16:43:18 <timeless> hta: an id could be an implementation defined string/random number
16:43:36 <timeless> martin__: but that can be correlated to other stats object at other random times for the same stats object?
16:43:51 <timeless> hta: it's the identifier of the underlying object's specific stats proper
16:43:55 <timeless> s/proper/property
16:44:16 <dom> -> http://lists.w3.org/Archives/Public/public-webrtc/2012Dec/att-0013/RTCWEBStatsv2.pdf Harald stats v2 proposal
16:44:26 <timeless> adambe: how do we define RTCStatsReport ?
16:44:51 <timeless> martin__: I think WebIDL has operator [index]
16:44:57 <timeless> ... or getter()
16:45:13 <timeless> hta: i can't say definitely w/o `JS the good parts`
16:45:17 <timeless> ... i've seen filter()
16:45:35 <timeless> ... if primary map is by id, then it's easy to get by type
16:45:48 <timeless> adambe: statsreport is only by id
16:45:53 <timeless> ... people implement by type themselves
16:45:58 <timeless> hta: i think my life is simpler
16:46:09 <timeless> juberti: what's the timestamp unit?
16:46:17 <timeless> hta: `long` is a mistake
16:46:26 <timeless> adambe: i argued for DOMTimeStamp
16:46:33 <timeless> hta: I argued for Date
16:47:16 <timeless> ekr: i'd be sad if i couldn't express time in units smaller than ms
16:47:28 <timeless> ... requirement is sub-ms resolution
16:47:42 <dom> -> http://www.w3.org/TR/hr-time/ High Resolution Time
16:47:45 <timeless> juberti: FP or us?
16:48:00 <timeless> martin__: nothing native provides one
16:48:25 <timeless> dom: High Resolution Time does this
16:48:30 <timeless> Josh_Soref: i believe it's from Web Perf
16:48:43 <timeless> hta: adopt High Res Time as soon as it goes to the list
16:49:22 <timeless> hta: i implemented this as long and was surprised it didn't overflow
16:49:32 <timeless> [ No more slides ]
16:49:46 <wonsuk> wonsuk has joined #webrtc
16:50:01 <timeless> juberti: on naming
16:50:07 <timeless> ... RTCStatsObject is the parent type
16:50:12 <timeless> ... derived types are RTPStream
16:50:18 <timeless> ... do we want `Stats` in the names?
16:50:39 <timeless> ... i could see having an RTPStream object at a future type
16:50:42 <timeless> s/type/time/
16:50:56 <timeless> adambe: i think they should show that they're Stats
16:51:37 <timeless> s/adambe/juberti/
16:51:47 <timeless> adambe: how do we keep track of remote stats?
16:51:54 <timeless> ... are they properties of a local stat
16:51:59 <timeless> ... or another property?
16:52:40 <timeless> hta: most of the time, properties
16:52:55 <timeless> ... i defined RTPStream `other end is`
16:53:31 <timeless> ... one comes from RTCP and one's local
16:53:44 <timeless> ... linking objects together is a special case
16:53:58 <timeless> adambe: my preference was to target the remote object directly
16:54:34 <timeless> hta: the weird point is
16:54:40 <timeless> ... if you get partial stats
16:54:51 <timeless> ... sometimes the other side falls outside your filter
16:55:07 <timeless> adambe: but you only filter on one level
16:55:39 <timeless> ... remote shouldn't be null or
16:55:43 <timeless> [ scribe is getting lost ]
16:55:58 <timeless> hta: if you filter, you get n+object graph
16:56:25 <timeless> ... you could have stats for other tracks
16:56:35 <timeless> hta: one case you look up id and it's there
16:56:40 <timeless> ... and one case the id isn't there
16:57:03 <timeless> hta: if there's a point about filtering
16:57:13 <timeless> fluffy: i could live with this
16:57:17 <timeless> ... i'd prefer something more
16:57:31 <timeless> ... trying to treat remote stats slightly differently doesn't make sense to me
16:58:09 <timeless> ... i'd suggest having 4 sets of statistics ({Local,Remote}{Incoming,Outgoing}RTPStreamStats)
16:58:15 <timeless> ... and then stuff all 4 in one obect
16:58:20 <timeless> s/obect/object
16:58:27 <timeless> hta: if you group, you impose a tree structure
16:58:55 <timeless> ... i have peerconnection -> streams -> tracks
16:58:59 <timeless> ... i have transports -> tracks
16:59:04 <timeless> ... not the same mapping
16:59:30 <timeless> "relations are good, normal forms are good, trees are bad"
17:00:31 <timeless> juberti: on name
17:00:34 <timeless> ... type
17:00:39 <timeless> ... do we prefer to spell out type
17:00:45 <timeless> ... as opposed to instanceof
17:01:02 <timeless> ... you have a bunch of RTCStats objects that are more derived
17:01:08 <timeless> ... you can look at the parent name property
17:01:18 <timeless> ... should we use instanceof?
17:01:21 <Zakim> Zakim has left #webrtc
17:01:46 <timeless> Josh_Soref: if you want to duct-type an object, instanceof doesn't work
17:01:59 <timeless> martin__: i wrote up an example of how to use this
17:02:07 <timeless> ... it's clumsy if i'm looking for a particular type
17:02:12 <timeless> ... how to figure out which type i'm looking for
17:02:27 <timeless> hta: leaf hierarchy
17:02:34 <timeless> ... reuse inheritance for more attributes
17:02:38 <timeless> ... type field isn't useful anymore
17:02:48 <timeless> ... is it incoming, or googlespecial or ...
17:03:02 <timeless> ... so we need type documentation
17:03:50 <timeless> adambe: some way to tell getstats what you want to poll for?
17:04:00 <timeless> ... it'd be easier if you could somehow know what to expect
17:04:20 <timeless> Topic: Open Issues
17:04:33 <timeless> s/Topic: Open Issues/
17:04:38 <timeless> stefanh: Lunch
17:04:44 <timeless> [ +1 +1 +1 ]
17:05:01 <timeless> fluffy: is there uncertainty to the ietf-stuff
17:05:06 <timeless> ... for what to do?
17:05:15 <timeless> hta: for stats, adambe needs to edit as agreed
17:05:22 <timeless> ... adambe and i will have a telco next week
17:05:52 <timeless> fluffy: one of you will create a document-ietf mirror of burn
17:06:00 <timeless> hta: which registry?
17:06:11 <timeless> fluffy: do we create a registry of stats?
17:06:21 <timeless> hta: i think we should
17:06:24 <timeless> fluffy: expert review?
17:06:40 <timeless> TedHardie: there's a W3C side process for creating registries
17:06:53 <timeless> adambe: what about additional ones
17:06:59 <timeless> ... do we want some mandatory stats?
17:07:07 <timeless> hta: i think the spec is unreadable w/o some examples
17:07:14 <timeless> ... the document should register those
17:07:16 <timeless> [ Lunch ]
17:07:28 <timeless> [ Meeting resumes as IETF after Lunch ]
17:07:52 <timeless> TedHardie: we'll try to close IETF on-time if not early due to SnowPocalypse
17:08:00 <timeless> ... i know we officially scheduled 5
17:08:07 <timeless> ... i'd suggest we target resuming @ 1:15
17:11:08 <dom> RRSAgent, draft minutes
17:11:08 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/07-webrtc-minutes.html dom
17:33:20 <mreavy> mreavy has joined #webrtc
17:55:03 <adam> adam has joined #webrtc
17:58:22 <lgombos> lgombos has joined #webrtc
18:17:21 <JonLennox> JonLennox has left #webrtc
18:28:11 <lgombos> lgombos has joined #webrtc
19:39:07 <mreavy> mreavy has left #webrtc
19:46:29 <lgombos_> lgombos_ has joined #webrtc
20:25:53 <lgombos> lgombos has joined #webrtc
21:02:31 <lgombos_> lgombos_ has joined #webrtc
21:58:46 <jun> jun has joined #webrtc