Open youennf opened 2 weeks ago
Strictly speaking, degradation-preference is a sender property, while mst-content-hint is a track property. So a track spec shouldn't want to talk about degradation preference - we have webrtc-pc referencing mediacapture-main, and not the other way around.
We could add a section to the mst-content-hint section on how to deal with tracks that don't have a hint.
Well, this spec is defining both content-hint track property and degradationPreference parameter so either we migrate this spec to webrtc-pc and mediacapture-main and do the work in webrtc-pc, or we keep this spec and we do the work here.
https://w3c.github.io/mst-content-hint/#behavior-of-an-rtcpeerconnection is about RTCPeerConnection behaviour when there is an explicit content-hint. It might be worth adding guideline in that section when there is no explicit contentHint.
From https://codepen.io/youennf/pen/JjgaxmQ, it appears that:
maintain-resolution
for screen share feeds (and probablymaintain-framerate
for camera feeds)maintain-framerate
for both screen share and camera feeds.While it is always difficult to mandate a particular degradation preference (if screen sharing a movie,
maintain-framerate
might be better), the spec could provide guidance and suggest some default behaviours for the various track types.