public-webrtc-logs@w3.org from January 2022 by author

Andreas Pehrson via GitHub

• Re: [webrtc-stats] Are "codec" stats per transceiver or per transport? (#614) (Thursday, 20 January)

Anne van Kesteren via GitHub

• Re: [mediacapture-screen-share] Normative security requirements ("ISSUE 1") (#126) (Friday, 21 January)

benny daon via GitHub

• Re: [webrtc-extensions] Add sctp rate control params to RTCPeerConnection constructor (#71) (Monday, 10 January)
• Re: [webrtc-extensions] Add sctp rate control params to RTCPeerConnection constructor (#71) (Saturday, 8 January)

Bernard Aboba via GitHub

• Re: [mediacapture-transform] Relationship to WebGPU (#34) (Tuesday, 18 January)
• Re: [webrtc-svc] how to specify L3T3? (#61) (Wednesday, 12 January)
• Re: [webrtc-extensions] Add sctp rate control params to RTCPeerConnection constructor (#71) (Monday, 10 January)
• Re: [webrtc-extensions] Add sctp rate control params to RTCPeerConnection constructor (#71) (Sunday, 9 January)
• Re: [webrtc-svc] [Question] Difference between SVC and Simulcast (#60) (Saturday, 8 January)
• [webrtc-extensions] Pull Request: RTP Header Extensions Encryption (cryptex) (Saturday, 8 January)
• Re: [webrtc-svc] [Question] Difference between SVC and Simulcast (#60) (Friday, 7 January)
• Re: [webrtc-extensions] `getCapabilities` seems to leak hardware capabilities w/o a permission (#54) (Thursday, 6 January)
• Closed: [webrtc-extensions] Add normative steps to getCapabilities() or deprecate it in favor of an async API (#57) (Thursday, 6 January)
• Re: [webrtc-svc] What should the scalability mode be when no scalability mode is specified? (#58) (Thursday, 6 January)
• Re: [webrtc-svc] What should the scalability mode be when the preferred scalability mode is not supported on the requested codec? (#59) (Thursday, 6 January)
• Re: [webrtc-svc] Handling of unknown scalability modes is underspecified (#57) (Thursday, 6 January)
• Re: [webrtc-extensions] Add normative steps to getCapabilities() or deprecate it in favor of an async API (#57) (Thursday, 6 January)
• Re: [webrtc-extensions] RTCRtpSender.getCapabilities() may not return correct information in sync (#49) (Thursday, 6 January)
• Re: [webrtc-extensions] RTP Header Extension Encryption (#47) (Thursday, 6 January)
• Re: [webrtc-extensions] Add sctp rate control params to RTCPeerConnection constructor (#71) (Thursday, 6 January)
• Re: [webrtc-extensions] Consider an API for non-delivered messages in SCTP datachannels (#50) (Thursday, 6 January)
• Re: [webrtc-encoded-transform] Add API to request key frames (#125) (Tuesday, 4 January)

Christoph Guttandin via GitHub

• [webrtc-encoded-transform] Pull Request: Remove duplicate closing tag (Sunday, 30 January)

docfaraday via GitHub

• Re: [webrtc-stats] codec.sdpFmtpLine isn't clear about which description to use (#616) (Friday, 21 January)

Domenic Denicola via GitHub

• Re: [mediacapture-record] MediaRecorderErrorEvent is a bad idea; use ErrorEvent instead (#211) (Wednesday, 12 January)
• [mediacapture-record] MediaRecorderErrorEvent is a bad idea; use ErrorEvent instead (#211) (Wednesday, 12 January)

Dominique Hazael-Massieux via GitHub

• [webrtc-pc] Pull Request: Update to ReSpec version 28.2.8 (Monday, 31 January)
• [mediacapture-main] Pull Request: Update to latest ReSpec version 28.2.8 (Monday, 31 January)
• Re: [webrtc-pc] Document substantive changes since Rec as candidate amendments (#2713) (Friday, 28 January)
• [webrtc-pc] Pull Request: Document substantive changes since Rec as candidate amendments (Friday, 28 January)
• Re: [mediacapture-region] Avoid using non-existent interface name (#15) (Friday, 28 January)
• Re: [mediacapture-region] Avoid using non-existent interface name (#15) (Thursday, 27 January)
• Re: [mediacapture-region] Avoid using non-existent interface name (#15) (Thursday, 27 January)
• [mediacapture-region] Pull Request: Avoid using non-existent interface name (Thursday, 27 January)
• [webrtc-pc] Pull Request: Update to ReSpec version 28.2.2 (Monday, 24 January)
• [mediacapture-main] Pull Request: Update to latest ReSpec version 28.2.2 (Monday, 24 January)
• [mediacapture-region] Pull Request: Remove latest version link (Friday, 21 January)
• Re: [mediacapture-record] Creation of Seekable Files (#119) (Monday, 17 January)
• [webrtc-pc] Pull Request: Update to ReSpec version 28.2.1 (Monday, 17 January)
• [mediacapture-main] Pull Request: Update to latest ReSpec version 28.2.1 (Monday, 17 January)
• Re: [mediacapture-record] MediaRecorderErrorEvent is a bad idea; use ErrorEvent instead (#211) (Friday, 14 January)
• [mediacapture-record] Pull Request: Remove superfluous MediaRecorderErrorEvent interface (Friday, 14 January)
• Re: [mediacapture-transform] Relationship to WebGPU (#34) (Thursday, 13 January)
• Re: [mediacapture-main] Update to latest ReSpec version 28.1.0 (#848) (Monday, 10 January)
• [mediacapture-main] Pull Request: Update to latest ReSpec version 28.1.0 (Monday, 10 January)
• Closed: [mediacapture-screen-share] @W3C chromium/React trial enrollment (#202) (Monday, 3 January)
• Re: [mediacapture-main] Update to latest ReSpec version (#843) (Monday, 3 January)

Eero Häkkinen via GitHub

• Re: [mediacapture-image] Add face detection mode constraint (#292) (Tuesday, 11 January)

Elad Alon via GitHub

• Re: [mediacapture-region] Can the MediaStreamTrack list its cropping regions directly? (#6) (Monday, 31 January)
• Re: [mediacapture-region] Why exposing produceCropTarget at MediaDevices level? (#11) (Monday, 31 January)
• Re: [mediacapture-region] cropTo is returning promises but it is unclear when promises are supposed to be rejected synchronously or not (#14) (Monday, 31 January)
• Re: [mediacapture-screen-share] Identification of Captured Application By Capturer (#166) (Monday, 31 January)
• Closed: [mediacapture-region] Wording around MediaStreamTrackOrSubclassThereof (#3) (Friday, 28 January)
• Re: [mediacapture-region] Avoid using non-existent interface name (#15) (Thursday, 27 January)
• [mediacapture-region] Pull Request: Remove MediaStreamTrackOrSubclassThereof (Thursday, 27 January)
• Re: [mediacapture-region] Avoid using non-existent interface name (#15) (Thursday, 27 January)
• Re: [mediacapture-region] Avoid using non-existent interface name (#15) (Thursday, 27 January)
• Re: [mediacapture-region] Avoid using non-existent interface name (#15) (Thursday, 27 January)
• Re: [mediacapture-region] Why exposing produceCropTarget at MediaDevices level? (#11) (Thursday, 27 January)
• Re: [mediacapture-region] Is BrowserCaptureMediaStreamTrack needed? (#10) (Thursday, 27 January)
• Re: [mediacapture-region] Why exposing produceCropTarget at MediaDevices level? (#11) (Thursday, 27 January)
• Re: [mediacapture-region] CropTarget should probably be available to Elements and not only HTMLElements (#13) (Thursday, 27 January)
• Re: [mediacapture-region] Can the MediaStreamTrack list its cropping regions directly? (#6) (Wednesday, 26 January)
• Re: [mediacapture-region] Timing of cropTo promise resolution with media capture-transform (#12) (Wednesday, 26 January)
• Re: [mediacapture-region] Why exposing produceCropTarget at MediaDevices level? (#11) (Wednesday, 26 January)
• Re: [mediacapture-region] Is muting track the right call for empty cropped tracks (#9) (Wednesday, 26 January)
• Closed: [mediacapture-region] Review request: Use of opaque interface (#4) (Tuesday, 25 January)
• Re: [mediacapture-region] Review request: Use of opaque interface (#4) (Tuesday, 25 January)
• Re: [mediacapture-region] Can the MediaStreamTrack list its cropping regions directly? (#6) (Tuesday, 25 January)
• Re: [mediacapture-region] Can the MediaStreamTrack list its cropping regions directly? (#6) (Tuesday, 25 January)
• Re: [mediacapture-region] Can the MediaStreamTrack list its cropping regions directly? (#6) (Tuesday, 25 January)
• Re: [mediacapture-region] Is muting track the right call for empty cropped tracks (#9) (Tuesday, 25 January)
• Re: [mediacapture-region] Is BrowserCaptureMediaStreamTrack needed? (#10) (Tuesday, 25 January)
• Re: [mediacapture-region] Timing of cropTo promise resolution with media capture-transform (#12) (Tuesday, 25 January)
• Re: [mediacapture-region] Why exposing produceCropTarget at MediaDevices level? (#11) (Tuesday, 25 January)
• Re: [mediacapture-main] It is unclear from the spec whether cloning a MediaStreamTrack preserves the subtype or not of the cloned track (#857) (Tuesday, 25 January)
• Re: [mediacapture-screen-share] Multi-capture (concurrent capture of multiple surfaces) (#204) (Friday, 21 January)
• Closed: [mediacapture-region] Broken link: "Latest published version" (#7) (Friday, 21 January)
• [mediacapture-region] Broken link: "Latest published version" (#7) (Friday, 21 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Thursday, 20 January)
• Re: [mediacapture-screen-share] Identification of Captured Application By Capturer (#166) (Wednesday, 19 January)
• Re: [mediacapture-region] Can the MediaStreamTrack list its cropping regions directly? (#6) (Wednesday, 19 January)
• Re: [mediacapture-screen-share] Normative security requirements ("ISSUE 1") (#126) (Friday, 14 January)
• Re: [mediacapture-screen-share] Normative security requirements ("ISSUE 1") (#126) (Friday, 14 January)
• [mediacapture-screen-share] Pull Request: Rephrase security considerations (Friday, 14 January)
• Re: [mediacapture-screen-share] Identification of Captured Application By Capturer (#166) (Friday, 14 January)
• Re: [mediacapture-screen-share] Identification of Captured Application By Capturer (#166) (Thursday, 13 January)
• [mediacapture-screen-share] Multi-capture (concurrent capture of multiple surfaces) (#204) (Thursday, 13 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Monday, 10 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Monday, 10 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Friday, 7 January)
• Re: [mediacapture-screen-share] Cropping Video Tracks (#195) (Friday, 7 January)
• Re: [mediacapture-screen-share] Cropping Video Tracks (#195) (Wednesday, 5 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Monday, 3 January)
• Re: [mediacapture-screen-share] How to detect Display Surfaces Minimized (#198) (Monday, 3 January)
• Closed: [mediacapture-screen-share] How to detect Display Surfaces Minimized (#198) (Monday, 3 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Monday, 3 January)
• [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Monday, 3 January)

Florent Castelli via GitHub

• Re: [webrtc-svc] What should the scalability mode be when no scalability mode is specified? (#58) (Wednesday, 19 January)
• Re: [webrtc-svc] Handling of unknown scalability modes is underspecified (#57) (Wednesday, 19 January)
• Re: [webrtc-svc] how to specify L3T3? (#61) (Monday, 10 January)

Harald Alvestrand via GitHub

• Re: [webrtc-svc] What should the scalability mode be when the preferred scalability mode is not supported on the requested codec? (#59) (Monday, 31 January)
• Re: [webrtc-svc] What should the scalability mode be when no scalability mode is specified? (#58) (Monday, 31 January)
• Re: [webrtc-svc] Handling of unknown scalability modes is underspecified (#57) (Monday, 31 January)
• Re: [webrtc-encoded-transform] fix type of timestamp attribute (#116) (Thursday, 27 January)
• [webrtc-encoded-transform] Metadata fields need descriptions (#129) (Thursday, 27 January)
• [mediacapture-transform] Pull Request: Update audio explainer with intro + WebIDL (Thursday, 27 January)
• Re: [mediacapture-output] Is reverting to different speakers from a background tab a valid use case? (#129) (Wednesday, 26 January)
• Re: [webrtc-extensions] captureTimestamp seems to have an inconsistent clock base (#97) (Wednesday, 26 January)
• [webrtc-extensions] captureTimestamp seems to have an inconsistent clock base (#97) (Wednesday, 26 January)
• Re: [mediacapture-transform] Remove remaining "audio" references in spec (#72) (Monday, 24 January)
• Closed: [mediacapture-transform] Need note saying there's no consensus on audio processing (#71) (Monday, 24 January)
• Re: [mediacapture-main] Broken foreground detection (#752) (Monday, 24 January)
• Re: [webrtc-stats] codec.sdpFmtpLine isn't clear about which description to use (#616) (Thursday, 20 January)
• Re: [webrtc-stats] Are "codec" stats per transceiver or per transport? (#614) (Thursday, 20 January)
• Re: [mediacapture-main] Check for permission policy synchronously when getUserMedia is called (#851) (Thursday, 20 January)
• [mediacapture-transform] Pull Request: Remove remaining "audio" references in spec (Wednesday, 19 January)
• Re: [mediacapture-transform] Should MediaStreamTrackGenerator have an API to fine-tune MediaStreamTrack internal states? (#26) (Thursday, 13 January)
• Closed: [mediacapture-transform] Should MediaStreamTrackGenerator have an API to fine-tune MediaStreamTrack internal states? (#26) (Thursday, 13 January)
• Re: [mediacapture-record] MediaRecorderErrorEvent is a bad idea; use ErrorEvent instead (#211) (Wednesday, 12 January)
• Re: [mediacapture-transform] Is MediaStreamTrackGenerator expected to increase <audio>.currentTime without input? (#63) (Wednesday, 12 January)
• Closed: [mediacapture-transform] Is MediaStreamTrackGenerator expected to increase <audio>.currentTime without input? (#63) (Wednesday, 12 January)
• Closed: [mediacapture-transform] Document timestamp (non)synchronization behaviors (#35) (Wednesday, 12 January)
• Re: [mediacapture-transform] Document timestamp (non)synchronization behaviors (#35) (Wednesday, 12 January)
• Re: [mediacapture-transform] Should MediaStreamTrackGenerator have an API to fine-tune MediaStreamTrack internal states? (#26) (Wednesday, 12 January)
• Re: [mediacapture-transform] Add "real-time" warning/note to MediaStreamTrackGenerator (#20) (Wednesday, 12 January)
• Re: [webrtc-extensions] Add sctp rate control params to RTCPeerConnection constructor (#71) (Tuesday, 11 January)
• Re: [mediacapture-screen-share] Should Application surface be removed (#189) (Monday, 10 January)
• Re: [mediacapture-screen-share] Normative security requirements ("ISSUE 1") (#126) (Monday, 10 January)
• Re: [webrtc-extensions] Add sctp rate control params to RTCPeerConnection constructor (#71) (Monday, 10 January)
• Re: [mediacapture-transform] Compare callback-based and ReadableStream-based exposure of video MediaStreamTrack media flow (#69) (Friday, 7 January)
• Closed: [mediacapture-transform] Compare callback-based and ReadableStream-based exposure of video MediaStreamTrack media flow (#69) (Friday, 7 January)
• Re: [mediacapture-transform] Relationship to WebGPU (#34) (Friday, 7 January)
• Re: [mediacapture-transform] Document timestamp (non)synchronization behaviors (#35) (Friday, 7 January)
• Re: [mediacapture-transform] Video data rotation should be explicit (#65) (Friday, 7 January)
• Re: [mediacapture-transform] API shape for creating a MediaStreamTrack from a WHATWG Stream (#70) (Friday, 7 January)
• Closed: [mediacapture-transform] API shape for creating a MediaStreamTrack from a WHATWG Stream (#70) (Friday, 7 January)
• Re: [mediacapture-transform] API shape for creating a MediaStreamTrack from a WHATWG Stream (#70) (Friday, 7 January)
• Closed: [mediacapture-transform] API shape for creating a WHATWG Stream from a MediaStreamTrack (#68) (Friday, 7 January)
• Re: [mediacapture-transform] API shape for creating a WHATWG Stream from a MediaStreamTrack (#68) (Friday, 7 January)
• Re: [mediacapture-transform] Clarify Generator construction with required kind (#18) (Friday, 7 January)
• Re: [webrtc-extensions] RTP Header Extension Encryption (#47) (Friday, 7 January)
• Re: [webrtc-extensions] RTP Header Extension Encryption (#47) (Friday, 7 January)
• Re: [webrtc-extensions] RTP Header Extension Encryption (#47) (Friday, 7 January)
• Re: [webrtc-extensions] RTCRtpSender.getCapabilities() may not return correct information in sync (#49) (Thursday, 6 January)
• Re: [webrtc-extensions] Add normative steps to getCapabilities() or deprecate it in favor of an async API (#57) (Thursday, 6 January)
• Re: [webrtc-extensions] RTP Header Extension Encryption (#47) (Thursday, 6 January)
• Closed: [webrtc-pc] Need to administratively prohibit candidates in SetRemoteDescription (#2675) (Thursday, 6 January)
• Re: [mediacapture-main] devicechange should fire when enumerateDevices works (#842) (Thursday, 6 January)
• [webrtc-svc] What should the scalability mode be when the preferred scalability mode is not supported on the requested codec? (#59) (Thursday, 6 January)
• [webrtc-svc] What should the scalability mode be when no scalability mode is specified? (#58) (Thursday, 6 January)
• [webrtc-svc] Handling of unknown scalability modes is underspecified (#57) (Thursday, 6 January)
• [mediacapture-transform] API shape for creating a MediaStreamTrack from a WHATWG Stream (#70) (Tuesday, 4 January)
• [mediacapture-transform] API shape for creating a WHATWG Stream from a MediaStreamTrack (#68) (Tuesday, 4 January)

henbos via GitHub

• Re: [webrtc-stats] Are "codec" stats per transceiver or per transport? (#614) (Wednesday, 26 January)

Ian Denhardt via GitHub

• Re: [webrtc-extensions] Add a CSP check to RTCPeerConnection.addIceCandidate(). (#81) (Wednesday, 5 January)
• Re: [webrtc-extensions] Add a CSP check to RTCPeerConnection.addIceCandidate(). (#81) (Wednesday, 5 January)
• Re: [webrtc-extensions] Add a CSP check to RTCPeerConnection.addIceCandidate(). (#81) (Tuesday, 4 January)

Jan-Ivar Bruaroey via GitHub

• Re: [mediacapture-screen-share] Rephrase security considerations (#205) (Monday, 31 January)
• [mediacapture-screen-share] Pull Request: Move normative statements out of the (non-normative) Security & Permissions (Monday, 31 January)
• Re: [mediacapture-screen-share] Revisit: Let getDisplayMedia() influence the default type choice in the picker (#184) (Monday, 31 January)
• Re: [webrtc-stats] WPT tests are wrong about when "outbound-rtp" and "inbound-rtp" stats appear (#619) (Saturday, 29 January)
• Re: [webrtc-stats] WPT tests are wrong about when "outbound-rtp" and "inbound-rtp" stats appear (#619) (Friday, 28 January)
• [mediacapture-main] Pull Request: Move enumerateDevices' 'MAY wait for focus' to affect devicechange as well (Wednesday, 26 January)
• Re: [webrtc-stats] WPT tests are wrong about when "outbound-rtp" and "inbound-rtp" stats appear (#619) (Wednesday, 26 January)
• [webrtc-stats] WPT tests are wrong about when "outbound-rtp" and "inbound-rtp" stats appear (#619) (Wednesday, 26 January)
• Re: [mediacapture-main] devicechange should fire when enumerateDevices works (#842) (Tuesday, 25 January)
• [mediacapture-output] Is reverting to different speakers from a background tab a valid use case? (#129) (Tuesday, 25 January)
• [mediacapture-main] Pull Request: Add privacy note and link to device enumeration design principles. (Monday, 24 January)
• Re: [mediacapture-main] devicechange should fire when enumerateDevices works (#842) (Monday, 24 January)
• Re: [mediacapture-main] devicechange should fire when enumerateDevices works (#842) (Monday, 24 January)
• [mediacapture-screen-share] Pull Request: Add note and example of inaccessible stats that fire mute (Monday, 24 January)
• Re: [mediacapture-screen-share] Should mute and unmute events of MediaStreamTrack be allowed to fire based on user non-action? (#141) (Monday, 24 January)
• Re: [webrtc-stats] codec.sdpFmtpLine isn't clear about which description to use (#616) (Friday, 21 January)
• Re: [webrtc-stats] codec.sdpFmtpLine isn't clear about which description to use (#616) (Friday, 21 January)
• Re: [webrtc-pc] Clarify receiver's sdpFmtpLines might differ in have-local-offer (#2711) (Friday, 21 January)
• [webrtc-pc] Pull Request: Clarify receiver's sdpFmtpLines might differ in have-local-offer (Friday, 21 January)
• [webrtc-stats] Pull Request: Match channels stat language with that of channels parameter. (Friday, 21 January)
• [webrtc-stats] Pull Request: Add note on coalescing codec stats. (Friday, 21 January)
• Re: [webrtc-stats] Are "codec" stats per transceiver or per transport? (#614) (Friday, 21 January)
• Re: [mediacapture-main] Check for permission policy synchronously when getUserMedia is called (#851) (Thursday, 20 January)
• Closed: [mediacapture-main] getUserMedia permission policy check happens very late (#847) (Thursday, 20 January)
• Re: [webrtc-extensions] Add a CSP check to RTCPeerConnection.addIceCandidate(). (#81) (Thursday, 20 January)
• Closed: [mediacapture-main] MediaStreamTrack clone algorithm should copy cloned readyState value (#852) (Thursday, 20 January)
• [webrtc-stats] codec.sdpFmtpLine isn't clear about which SDP to use (#616) (Thursday, 20 January)
• [webrtc-stats] Possibly outdated text on codec.channels (#615) (Thursday, 20 January)
• [webrtc-pc] sdpFmtpLine prose is vague about which SDP to use (#2710) (Thursday, 20 January)
• [webrtc-stats] Are "codec" stats per transceiver or per transport? (#614) (Thursday, 20 January)
• Re: [mediacapture-screen-share] Identification of Captured Application By Capturer (#166) (Thursday, 20 January)
• [mediacapture-transform] Need note saying there's no consensus on audio processing (#71) (Thursday, 13 January)
• Re: [mediacapture-main] deviceId and Clear-Site-Data (#836) (Thursday, 6 January)
• Re: [mediacapture-screen-share] Cropping Video Tracks (#195) (Thursday, 6 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Thursday, 6 January)
• Closed: [mediacapture-main] Inconsistencies around double filtering of "devicechange" events (#810) (Thursday, 6 January)
• Re: [mediacapture-screen-share] Cropping Video Tracks (#195) (Wednesday, 5 January)
• Re: [webrtc-extensions] Add a CSP check to RTCPeerConnection.addIceCandidate(). (#81) (Tuesday, 4 January)
• [webrtc-pc] Pull Request: Restrict ICE agent from using administratively prohibited candidates (Tuesday, 4 January)

John Hardy via GitHub

• [mediacapture-image] Possibly incorrect note on focusMode (#293) (Tuesday, 4 January)

Karl Tomlinson via GitHub

• Re: [mediacapture-main] Move enumerateDevices' 'MAY wait for focus' to affect devicechange as well (#858) (Monday, 31 January)

law via GitHub

• Re: [mediacapture-record] Creation of Seekable Files (#119) (Monday, 17 January)

Lenny via GitHub

• Re: [webrtc-extensions] RTP Header Extension Encryption (#47) (Friday, 7 January)

MaciejWebWolf via GitHub

• Re: [mediacapture-main] GetDisplayMedia don't capture the audio from microphone (#694) (Friday, 7 January)

Makarand Patwardhan via GitHub

• Re: [webrtc-stats] ActiveIceCandidatePairStats.bytesReceived (even when no tracks were subscribed to) (#613) (Wednesday, 26 January)
• Closed: [webrtc-stats] ActiveIceCandidatePairStats.bytesReceived (even when no tracks were subscribed to) (#613) (Wednesday, 26 January)
• Re: [webrtc-stats] ActiveIceCandidatePairStats.bytesReceived (even when no tracks were subscribed to) (#613) (Friday, 14 January)
• [webrtc-stats] ActiveIceCandidatePairStats.bytesReceived (even when no tracks were subscribed to) (#613) (Friday, 14 January)

Michael Tüxen via GitHub

• Re: [webrtc-extensions] Add sctp rate control params to RTCPeerConnection constructor (#71) (Tuesday, 11 January)
• Re: [webrtc-extensions] Add sctp rate control params to RTCPeerConnection constructor (#71) (Monday, 10 January)
• Re: [webrtc-extensions] Add sctp rate control params to RTCPeerConnection constructor (#71) (Monday, 10 January)
• Re: [webrtc-extensions] Add sctp rate control params to RTCPeerConnection constructor (#71) (Sunday, 9 January)
• Re: [webrtc-extensions] Add sctp rate control params to RTCPeerConnection constructor (#71) (Sunday, 9 January)

Michał Śledź via GitHub

• Closed: [webrtc-svc] [Question] Difference between SVC and Simulcast (#60) (Saturday, 8 January)
• Re: [webrtc-svc] [Question] Difference between SVC and Simulcast (#60) (Saturday, 8 January)
• Re: [webrtc-svc] [Question] Difference between SVC and Simulcast (#60) (Saturday, 8 January)
• [webrtc-svc] [Question] Difference between SVC and Simulcast (#60) (Friday, 7 January)

Mike Taylor via GitHub

• Re: [mediacapture-output] Define "speaker-selection" powerful feature types and algorithms. (#128) (Tuesday, 18 January)

pes10k via GitHub

• Re: [mediacapture-main] Add privacy note and link to device enumeration design principles. (#856) (Friday, 28 January)

Philip Jägenstedt via GitHub

• Re: [mediacapture-record] MediaRecorderErrorEvent is a bad idea; use ErrorEvent instead (#211) (Thursday, 20 January)

Philipp Hancke via GitHub

• Re: [webrtc-stats] WPT tests are wrong about when "outbound-rtp" and "inbound-rtp" stats appear (#619) (Saturday, 29 January)
• Re: [webrtc-stats] WPT tests are wrong about when "outbound-rtp" and "inbound-rtp" stats appear (#619) (Friday, 28 January)
• Re: [webrtc-stats] ActiveIceCandidatePairStats.bytesReceived (even when no tracks were subscribed to) (#613) (Tuesday, 18 January)
• Re: [webrtc-stats] ActiveIceCandidatePairStats.bytesReceived (even when no tracks were subscribed to) (#613) (Friday, 14 January)
• Re: [webrtc-svc] how to specify L3T3? (#61) (Thursday, 13 January)
• [webrtc-svc] how to specify L3T3? (#61) (Monday, 10 January)

Sergio Garcia Murillo via GitHub

• Re: [webrtc-svc] how to specify L3T3? (#61) (Monday, 10 January)
• Re: [webrtc-extensions] RTP Header Extension Encryption (#47) (Friday, 7 January)

Varun Singh via GitHub

• Re: [webrtc-stats] RTCVideoSourceStats.framesPerSecond should be a double (#540) (Wednesday, 26 January)

W3C Bot via GitHub

• Re: [webrtc-encoded-transform] Remove duplicate closing tag (#130) (Sunday, 30 January)
• Re: [webrtc-encoded-transform] fix type of timestamp attribute (#116) (Thursday, 27 January)

youennf via GitHub

• Re: [webrtc-encoded-transform] Should we expose the precise timestamp of the frame that was triggered by a generateKeyFrame call? (#128) (Friday, 28 January)
• [webrtc-encoded-transform] Should we expose the precise timestamp of the frame that was triggered by a generateKeyFrame call? (#128) (Thursday, 27 January)
• [mediacapture-region] cropTo is returning promises but it is unclear when promises are supposed to be rejected synchronously or not (#14) (Thursday, 27 January)
• Re: [mediacapture-region] Why exposing produceCropTarget at MediaDevices level? (#11) (Thursday, 27 January)
• Re: [mediacapture-region] Why exposing produceCropTarget at MediaDevices level? (#11) (Thursday, 27 January)
• [mediacapture-region] CropTarget should probably be available to Elements and not only HTMLElements (#13) (Thursday, 27 January)
• Re: [mediacapture-region] Why exposing produceCropTarget at MediaDevices level? (#11) (Thursday, 27 January)
• Re: [mediacapture-region] Can the MediaStreamTrack list its cropping regions directly? (#6) (Wednesday, 26 January)
• Re: [mediacapture-region] Is BrowserCaptureMediaStreamTrack needed? (#10) (Wednesday, 26 January)
• Re: [mediacapture-region] Can the MediaStreamTrack list its cropping regions directly? (#6) (Wednesday, 26 January)
• Re: [mediacapture-region] Timing of cropTo promise resolution with media capture-transform (#12) (Wednesday, 26 January)
• Re: [mediacapture-region] Is muting track the right call for empty cropped tracks (#9) (Wednesday, 26 January)
• Re: [mediacapture-region] Why exposing produceCropTarget at MediaDevices level? (#11) (Wednesday, 26 January)
• Re: [mediacapture-main] It is unclear from the spec whether cloning a MediaStreamTrack preserves the subtype or not of the cloned track (#857) (Tuesday, 25 January)
• [mediacapture-main] It is unclear from the spec whether cloning a MediaStreamTrack preserves the subtype or not of the cloned track (#857) (Tuesday, 25 January)
• Re: [mediacapture-region] Is BrowserCaptureMediaStreamTrack needed? (#10) (Tuesday, 25 January)
• [mediacapture-region] Timing of cropTo promise resolution with media capture-transform (#12) (Tuesday, 25 January)
• [mediacapture-region] Why exposing produceCropTarget at MediaDevices level? (#11) (Tuesday, 25 January)
• [mediacapture-region] Is BrowserCaptureMediaStreamTrack needed? (#10) (Tuesday, 25 January)
• Re: [mediacapture-screen-share] Identification of Captured Application By Capturer (#166) (Tuesday, 25 January)
• Re: [mediacapture-main] devicechange should fire when enumerateDevices works (#842) (Tuesday, 25 January)
• Re: [mediacapture-region] Can the MediaStreamTrack list its cropping regions directly? (#6) (Monday, 24 January)
• [mediacapture-region] Is muting track the right call for empty cropped tracks (#9) (Monday, 24 January)
• Re: [mediacapture-main] getUserMedia permission policy check happens very late (#847) (Thursday, 20 January)
• Closed: [mediacapture-main] getUserMedia should not reject with NotFoundErrorError or OverConstrainedError on contexts for which permission is denied (#849) (Thursday, 20 January)
• [mediacapture-transform] There is no note stating that https://github.com/whatwg/streams/blob/main/streams-for-raw-video-explainer.md is needed (#74) (Thursday, 20 January)
• [mediacapture-region] Can the MediaStreamTrack list its cropping regions directly? (#6) (Wednesday, 19 January)
• [mediacapture-transform] Is MediaStreamTrackProcessor needed? (#73) (Wednesday, 19 January)
• Re: [mediacapture-screen-share] Identification of Captured Application By Capturer (#166) (Wednesday, 19 January)
• [mediacapture-main] Pull Request: Explicitly copy readyState when cloning a track (Friday, 14 January)
• [mediacapture-main] MediaStreamTrack clone algorithm should copy cloned readyState value (#852) (Friday, 14 January)
• Re: [mediacapture-screen-share] Identification of Captured Application By Capturer (#166) (Friday, 14 January)
• Re: [mediacapture-main] Broken foreground detection (#752) (Monday, 10 January)
• [mediacapture-screen-share] Improve getDisplayMedia current focus requirement (#203) (Monday, 10 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Monday, 10 January)
• [mediacapture-main] Pull Request: Check for permission policy synchronously when getUserMedia is called (Monday, 10 January)
• [mediacapture-main] Pull Request: Filter getUserMedia errors if permission is denied (Monday, 10 January)
• [mediacapture-main] getUserMedia should not reject with NotFoundErrorError or OverConstrainedError on contexts for which permission is denied (#849) (Monday, 10 January)
• Re: [mediacapture-main] getUserMedia permission policy check happens very late (#847) (Monday, 10 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Saturday, 8 January)
• [mediacapture-main] getUserMedia permission policy check happens very late (#847) (Saturday, 8 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Saturday, 8 January)
• Re: [mediacapture-screen-share] Cropping Video Tracks (#195) (Friday, 7 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Thursday, 6 January)
• Closed: [webrtc-extensions] RTCRtpSender.getCapabilities() may not return correct information in sync (#49) (Thursday, 6 January)
• Re: [webrtc-extensions] RTCRtpSender.getCapabilities() may not return correct information in sync (#49) (Thursday, 6 January)
• Re: [webrtc-extensions] Add normative steps to getCapabilities() or deprecate it in favor of an async API (#57) (Thursday, 6 January)
• [webrtc-extensions] Deprecate audio/video enumeration in getCapabilities in favour of Media Capabilities API (#95) (Thursday, 6 January)
• Re: [webrtc-extensions] RTP Header Extension Encryption (#47) (Thursday, 6 January)
• Re: [webrtc-extensions] Consider an API for non-delivered messages in SCTP datachannels (#50) (Thursday, 6 January)
• Closed: [webrtc-extensions] Consider an API for non-delivered messages in SCTP datachannels (#50) (Thursday, 6 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Tuesday, 4 January)
• [webrtc-encoded-transform] How to manage key frames in case of SFrameTransform key rotation (#127) (Tuesday, 4 January)
• [mediacapture-transform] Compare callback-based and ReadableStream-based exposure of video MediaStreamTrack media flow (#69) (Tuesday, 4 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Monday, 3 January)
• Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846) (Monday, 3 January)

Last message date: Monday, 31 January 2022 23:18:32 UTC