[mediacapture-main] Pull Request: Update to latest ReSpec version 35.2.1
[webrtc-pc] Pull Request: Update to ReSpec version 35.2.1
Re: [mst-content-hint] Should the spec provide guideline on the default degradation preference to use for capture tracks? (#60)
Re: [mst-content-hint] Default degradationPreference value? (#37)
- Re: [mst-content-hint] Default degradationPreference value? (#37)
- Re: [mst-content-hint] Default degradationPreference value? (#37)
Re: [mst-content-hint] What is the value of degradationPreference over time? (replaceTrack, contentHint setter) (#36)
[mediacapture-main] new commits pushed by youennf
Closed: [mediacapture-screen-share] Should screen capture tracks expose deviceId? (#308)
[mediacapture-screen-share] new commits pushed by jan-ivar
[mediacapture-screen-share] Pull Request: Add deviceId as settings and constraints for screen share video tracks.
Re: [mediacapture-transform] MediaStreamTrackGenerator/MediaStream should buffer the current frame (#114)
Re: [mediacapture-surface-control] Is gesture forwarding tied to capture controller or to MediaStreamTrack (#45)
[webrtc-pc] Use USVString for url attributes and members (#3029)
[mediacapture-main] Pull Request: Missed a spot that should use HTMLMediaElement's potentially playing definition
[mediacapture-main] currentTime still references undefined "playing" state (#1024)
[webrtc-rtptransport] Packet sender needs to expose a signal about max packet size (#83)
Re: [webrtc-extensions] Add API to control encode complexity (#191)
Re: [webrtc-extensions] receiver.hardwareAcceleration attribute instead of disableHardware[En|De]coding() static method (#229)
Re: [mediacapture-transform] We shouldn't require track transferability (#113)
- Re: [mediacapture-transform] We shouldn't require track transferability (#113)
- Re: [mediacapture-transform] We shouldn't require track transferability (#113)
- Re: [mediacapture-transform] We shouldn't require track transferability (#113)
- Re: [mediacapture-transform] We shouldn't require track transferability (#113)
- Re: [mediacapture-transform] We shouldn't require track transferability (#113)
- Re: [mediacapture-transform] We shouldn't require track transferability (#113)
- Re: [mediacapture-transform] We shouldn't require track transferability (#113)
Re: [webrtc-pc] Spec says to send black frames for ended tracks (#3014)
Re: [mediacapture-output] Implicit consent via getUserMedia should allow access to non-miked speakers (#147)
- Re: [mediacapture-output] Implicit consent via getUserMedia should allow access to non-miked speakers (#147)
- Re: [mediacapture-output] Implicit consent via getUserMedia should allow access to non-miked speakers (#147)
- Re: [mediacapture-output] Implicit consent via getUserMedia should allow access to non-miked speakers (#147)
- Re: [mediacapture-output] Implicit consent via getUserMedia should allow access to non-miked speakers (#147)
- Re: [mediacapture-output] Implicit consent via getUserMedia should allow access to non-miked speakers (#147)
- Re: [mediacapture-output] Implicit consent via getUserMedia should allow access to non-miked speakers (#147)
- Re: [mediacapture-output] Implicit consent via getUserMedia should allow access to non-miked speakers (#147)
- Re: [mediacapture-output] Implicit consent via getUserMedia should allow access to non-miked speakers (#147)
- Re: [mediacapture-output] Implicit consent via getUserMedia should allow access to non-miked speakers (#147)
Re: [mediacapture-transform] What is the expected timing of MSTP video frame enqueuing with other track events (configurationchange, applyConstraints promise resolution) (#115)
Re: [webrtc-rtptransport] Should RTCRtpTransport(Processor) use event handlers for packet notifications? (#70)
Re: [webrtc-rtptransport] Per-packet notifications are mandatory, this is not ideal for context switching (#78)
Re: [webrtc-rtptransport] API creates per-packet temporary objects, this is not ideal for GC (#77)
Re: [mediacapture-screen-share] Should screen capture tracks expose deviceId? (#308)
- Re: [mediacapture-screen-share] Should screen capture tracks expose deviceId? (#308)
- Re: [mediacapture-screen-share] Should screen capture tracks expose deviceId? (#308)
- Re: [mediacapture-screen-share] Should screen capture tracks expose deviceId? (#308)
[mediacapture-main] new commits pushed by dontcallmedom
[mediacapture-main] Pull Request: Update to latest ReSpec version 35.2.0
[webrtc-pc] What holds on to RTCOfferOptions and its iceRestart member (#3028)
[webrtc-pc] Legacy Interface Extensions is somewhat unclear (#3027)
Re: [webrtc-pc] specify legacy onaddstream? (#1705)
Re: [webrtc-pc] Should we specify how addStream()/"addstream event" should behave? (#568)
Re: [webrtc-pc] Add remote track channelCount (#3025)
Re: [webrtc-encoded-transform] Add captureTimestamp and senderCaptureTimeOffset to frame metadata (#228)
[mediacapture-main] new commits pushed by alvestrand
Closed: [mediacapture-transform] MediaStreamTrackGenerator/MediaStream should buffer the current frame (#114)
[mediacapture-surface-control] Where do forwarded "wheel" events fire? (#51)
- Re: [mediacapture-surface-control] Where do forwarded "wheel" events fire? (#51)
- Re: [mediacapture-surface-control] Where do forwarded "wheel" events fire? (#51)
[mediacapture-surface-control] Clarify "fire a blank event" for "capturedzoomlevelchange" (#50)
Re: [mediacapture-main] What is the purpose of requiring a successful gUM call before enumerateDevices? (#1019)
- Re: [mediacapture-main] What is the purpose of requiring a successful gUM call before enumerateDevices? (#1019)
- Re: [mediacapture-main] What is the purpose of requiring a successful gUM call before enumerateDevices? (#1019)
- Re: [mediacapture-main] What is the purpose of requiring a successful gUM call before enumerateDevices? (#1019)
- Re: [mediacapture-main] What is the purpose of requiring a successful gUM call before enumerateDevices? (#1019)
[mediacapture-screen-share] Missing spec-compliant way to detect shareable surfaces (#309)
Re: [webrtc-extensions] captureTimestamp: RTCRtpContributingSource vs RTCRtpSynchronizationSource (#215)
[mediacapture-main] Pull Request: Prevent remove-a-track to recurse.
Re: [mediacapture-transform] Track transferability requirement adds complexity to some common use cases (#116)
- Re: [mediacapture-transform] Track transferability requirement adds complexity to some common use cases (#116)
- Re: [mediacapture-transform] Track transferability requirement adds complexity to some common use cases (#116)
[webrtc-encoded-transform] add receiveTime to metadata (#235)
Re: [mediacapture-screen-share-extensions] Cross-Type Surface Switching (#16)
Re: [mediacapture-screen-share-extensions] Auto-pause for Captured Surface Switching (2nd edition) (#15)
- Re: [mediacapture-screen-share-extensions] Auto-pause for Captured Surface Switching (2nd edition) (#15)
- Re: [mediacapture-screen-share-extensions] Auto-pause for Captured Surface Switching (2nd edition) (#15)
- Re: [mediacapture-screen-share-extensions] Auto-pause for Captured Surface Switching (2nd edition) (#15)
- Re: [mediacapture-screen-share-extensions] Auto-pause for Captured Surface Switching (2nd edition) (#15)
- Re: [mediacapture-screen-share-extensions] Auto-pause for Captured Surface Switching (2nd edition) (#15)
- Re: [mediacapture-screen-share-extensions] Auto-pause for Captured Surface Switching (2nd edition) (#15)
- Re: [mediacapture-screen-share-extensions] Auto-pause for Captured Surface Switching (2nd edition) (#15)
Re: [mediacapture-record] Add replaceTrack method to MediaStream (#167)
- Re: [mediacapture-record] Add replaceTrack method to MediaStream (#167)
- Re: [mediacapture-record] Add replaceTrack method to MediaStream (#167)
- Re: [mediacapture-record] Add replaceTrack method to MediaStream (#167)