WebRTC Virtual Interim

<vivien> [recording is now in progress]

Bernard: "for discussion today" slide shown

Issues 1178/1406: Defining the scope of DTLS/ICE transport objects (Taylor)

Issue 1178/PR 1623: Need to describe when ICE and DTLS transport objects are created/changed

<vivien> Issue 1178

<vivien> PR 1623

Issue 1406/PR 1631: When ICE restart results in connection to a new endpoint

<vivien> Issue 1406

<vivien> PR 1631

Taylor: slides 10 - 12 shown

Taylor: according to decisions made at previous VIs

Cullen: (question about relation to createOffer / setLocal)
... worry about discrepancy between spec xxxx and what browsers implement
... regarding being able to continue to receive e.g. audio

Taylor: xxx

Cullen: happy with that

(looking at PRs)

RESOLUTION: Merge 1623 & 1631, and close issues 1178 and 1406

Issue 1283/PR 1570: Centering, Scaling, Cropping (Stefan)

<vivien> Issue 1283

<vivien> PR 1570

Decision: not consensus to merge PR1570.
... perhaps add a bit saying crop if that is what the application desires.

do not crop could be the default.

proposal: two modes: center/scale/crop and scale/pad

probably on sender.

Randell: do we need "balanced"?

<dom> proposed values: "letterbox", "crop" or "auto"

harald: we should use the terms from html spec

cullen: not what I'm proposing

<dom> is https://developer.mozilla.org/en-US/docs/Web/CSS/object-fit what harald is referring to?

dan: we should use "pad" because we do not know if the result will be pillarbox or letterbox

cullen: concrete proposal: we add new knob "fill", "contain", "auto"

<dom> I think this is "cover" rather than "fill"

cullen: fill equals "center,scale,crop", "fill" means pad, "auto" means auto

RESOLUTION: Cullen and Stefan will work with text, Justin will be asked to review and if these 3 agree, we can merge and go to CR with that.

Issue 1625/PR 1632: RTCPriorityType undesirably combines relative bitrate with QoS priority (Taylor)

<vivien> Issue 1625

<vivien> PR 1632

Taylor: QoS mixing bitrate and priority
... and to coarse with 1:2:4:8 bitrate choices
... proposal to add a new knob for relative bitrate

Harald: as author of the text: if you want to send something with high prio and low bitrate, just set high prio on it

Long discussion

RESOLUTION: discussion will continue in PR

Issue 478: Content hints for MediaStreamTrack (Peter Boström)

<vivien> Issue 478

Long discussion, especially on where this should be placed. Also about default and coupling to constraints.

Consensus is that this is worth discussing. Many seems to like the idea, but needs more discussion on how, where, when if we decide to do something like this.

There will be time at TPAC to discuss this further.

The proposal is implemented in Blink if anyone wants to play with it.

<dom> MediaStreamTrack Content Hints draft proposal

<dom> CR Bug

<dom> Examples of usage of Content Hint

<dom> I think if we want to ensure sinks adopt these hints, it should be added to https://www.w3.org/TR/mediacapture-streams/#defining-new-consumers-of-mediastreams-and-mediastreamtracks

RESOLUTION: Dan and Peter will work on this. Cullen interested in near / far field speech

Issue 470: Does getSettings() reflect configured or actual settings? (Jan-Ivar)

<vivien> Issue 470

(Dan talking)

Dan: does getSettings get actual or configured settings?
... has been discussed before (camera pan example)
... original intent was to get the currently use value if the constraints allow a range

<fluffy> exit

<burn> the question is whether we have now crossed the threshold for adding a major new feature - finding out the current actual state

<burn> I am not arguing in favor of that, just bringing up the question based on this issue