Meeting minutes
Slideset: https://
MediaCapture-screen-share
Jan-Ivar: it sounds reasonable to me. The wording "high" for preference may not be usual
… what would be the change to the user experience
Palak: we can show a dialog to the user to ask whether it's ok to capture audio
Tim: it seems an overlap in the space
Jan-Ivar: we can bikeshed on the value
… you don't need a 2-value-enum
… the absence of an audio preference is the default
but a 1-value enum is strange
Guido: it's more a hint for the application to say Audio is essential
… "try again and enable audio"
… it's still a hint, the user has the final say
Jan-Ivar: we can start with a 1 enum value
Guido: I'll prepare a PR to be discussed.
ACTION: Guido to prepare a PR for audioPref
Diagnostic Logging
Guido: the UC is to help developers by allowing the UA to log internal WebRTC data
… this proposal is about creating local logs, subject to explicit user authorization
… not exposed to the app
… data log format can be specific to the UA
Guido: API shape with startDiagnosticLogging, finishDiagnosticLogging. Also cancelLogging, that removes any existing logging.
… returns random logging Id
… it never fails, takes on optional metadata argument
Guido: the intention in chrome is to limit to enterprise users
Jan-Ivar: would these objects exist all the time? or limited to enterprise users?
Guido: it would be the best
Jan-Ivar: how do you detect an enterprise user?
Jan-Ivar: we already have static methods
… could this be static methods?
Guido: yes
Jan-Ivar: could they have a permission prompt?
Guido: it could be, but it would add to prompt fatigue, so having an admin enabling this would be better
… integration with a permission API would be useful
Tim: I'd prefer to have it in RTC connection
… somehow good to have enterprise level authorization
Guido: we could have a setting in the UA to explicitly enable it
Jan-Ivar: record?
Guido: it could be possible to upload to an endpoint provided by the UA
… we don't want to log exposed to the application
… only if UA is authorized
… a user filing a bug could use the session number to refer to the log
Encoded Source Update
Guido: We allow the application to insert encoded frames directly into an RTCRtpSender
… the data is forwarded to nodes internally
… this is an API to better support that Use Case
Jan-Ivar: @@@
Guido: it could be similar to replace track
… I always prefer using a method
… it makes implementation easier
… but it's not a blocker
Guido: developer feedback says that new constructors are needed
Jan-Ivar: don't we already have constructors for frames?
Guido: not with metadata
Guido: rtpTimestamp has a random initial value, so we need a timestampWithoutOffset
Guido: we have a prototype. we'd like to make a PR and discuss
Jan-Ivar: About the constructors.
… EncodedVideoChunk has a constructor
… have you considered web codecs as a potential input?
… could be kill 2 birds with one stone by reusing the web codecs version?
Guido: we had a prototype with web codecs
… but we also need to add the metadata that this constructor does not have
… it might be useful to optimize
… I'm open to discussing it
… worth exploring
Guido: Applications require some signals to better control the encoder
Guido: proposed API shape
Guido: add more in a v2
Guido: prototoyped constructor
… works for audio and some UC for video
Guido: we need more prototyping before proposing something for standardization
Jan-Ivar: Overall it's great
… can you explain more about allocated bitrate?
Guido: it's used to configure an encoder
… we can have a proxy encoder than can do the requested bitrate value
Guido: we'll continue prototyping/
WebRTC-PC Grab Bag
Jan-Ivar: at last meeting we did not finish some issues
… underspecified resolutions
Peter: I'd not say introspection into the SDP
… the SDP may not include everything all the time
Jan-Ivar: it's worth checking after the meeting
… it's about the state of the peer connection
Jan-Ivar: the SDP is already a well specified state of the connection
… previously we agreed on using verbatim string matching
jan-Ivar: proposed changes to spec prose
Tim: so you can have a selected pair that @@@1
Jan-Ivar: it was already the case before
Jan-Ivar: that language came from ORTC
… it happens to be the only insertion points for new candidates
… but they can appear inthe SDP
Tim: still disappointed that peer reflexive candidates are not exposed
Jan-Ivar: the proposal does not make that note disappear, indeed
Guido: the proposal seems more useful, more accurate than the old one. We need to check for any compatiblity issue
… will evaluate that before giving answer
ACTION: Jan-Ivar to make a PR on 3118/3119/3120 and get it reviewed
MediaCapture Grab Bag
Jan-Ivar: first step of activation is to check whether too much time has passed
… then the web page can send only one @@@2
Jan-Ivar: all implementation of getDisplayMedia picker are invasive
Jan-Ivar: proposal is to consume transient activation in getDisplayMedia
… there's also a 3rd option with media session and p-in-p
Tim: is there an interaction with audio play?
… if you do gDM and you want a self-view with your audio, if your consume the activation the audio play will fail
… e.g. taking an audio track and play it right away
Jan-Ivar: looking for audio use cases that might be broken by this?
… can't find any, but worth checking. Raise issues if you find them
Tim: it really is consuming so it seems that there might be interactions. no precise UC
… it looks similar to gUM, but it won't work the same
… can we just flag the difference so people realize it's not the same behaviour
… a warning in the text seems necessary
ACTION: Jan-Ivar to look into the possible issues/UCs