WebRTC 屏幕共享不是视频，原因何在？
内容提要
WebRTC屏幕共享与摄像头视频不同：内容分辨率高、运动少，应优先保证清晰度而非帧率。需将contentHint设为“detail”，采用AV1屏幕内容编码，码率随内容动态调整。建议摄像头与屏幕共享使用两条PeerConnection，避免带宽均分。同时需注意共享界面类型、音频权限及独立监控指标。
延伸解读
屏幕共享与摄像头视频的本质差异
文章指出，屏幕共享内容以高分辨率、低运动为特征，与摄像头视频的窄带运动相反。摄像头优化帧率，屏幕共享应优先清晰度。编码器假设失效，需区别对待。这解释了为何统一处理会导致文字模糊、延迟和CPU飙升。
优化屏幕共享的关键技术选择
文章建议将contentHint设为“detail”，采用AV1屏幕内容编码（SCC），并让码率随内容动态调整。同时，摄像头与屏幕共享应使用两条PeerConnection，避免带宽均分。这些措施能提升清晰度，减少资源浪费。
实施中的注意事项与潜在风险
需注意共享界面类型（标签页、窗口、显示器）影响分辨率和隐私；音频权限需检查实际批准情况；避免“镜子大厅”效应。此外，应为屏幕共享建立独立监控指标，如冻结率、发送分辨率等，而非混入通用看板。
Q&A
为什么WebRTC屏幕共享不能像摄像头视频一样处理？
屏幕共享内容是高分辨率、低运动量的，与摄像头视频正好相反。摄像头视频需要优先保证帧率，而屏幕共享应优先保证清晰度。如果同等对待，会导致文字模糊、幻灯片延迟、CPU飙升等问题。
在WebRTC中如何设置contentHint来优化屏幕共享？
在屏幕共享轨道上应将contentHint设为“detail”（或“text”），以偏向清晰度而非运动平滑度。当共享视频片段时，应设为“motion”。
为什么AV1编解码器适合屏幕共享？
AV1自带屏幕内容编码工具（SCC），能用少得多的比特把文字编码好，提升屏幕共享质量。即使摄像头仍用其他编解码器，屏幕共享也可切换到AV1。
摄像头和屏幕共享应该使用一条还是两条PeerConnection？
建议使用两条独立的PeerConnection。单条连接会导致带宽平均分配，可能不是期望的优先级，且无法自动将静态流节省的带宽转移给另一条轨道。两条连接虽然会争抢带宽，但浏览器实现更好。
屏幕共享时有哪些音频权限和采集注意事项？
调用getDisplayMedia()时可加audio: true请求音频，但用户可能拒绝。需检查实际批准的轨道，并考虑麦克风可能采集到扬声器声音。Chrome提供systemAudio、windowAudio、suppressLocalAudioPlayback、restrictOwnAudio等选项来控制音频行为。
如何为屏幕共享建立独立的监控指标？
应为屏幕共享流引入应用层信号，标明是屏幕共享还是摄像头，以便调试时关联统计数据。建议监控冻结率、发送分辨率与采集分辨率的差异、fps、编码器CPU等独立指标，而不是混入通用视频质量看板。
