2.3 老师推流：摄像头、麦克风与屏幕共享

老师端是整堂课的音源和画面源

进房通之后，下一个目标是让老师端稳定推流。说稳定，是因为推流环节的变量比进房多得多：摄像头可能被占用、麦克风可能有电流声、屏幕共享可能掉帧，老师还可能在上课途中换设备。学生端只要拉到一条流，老师端要同时管理好几条。这一节把推流涉及到的设备管理、屏幕共享、热切换和降级策略一次讲透。

推流设备管理表

培训机构的老师不是技术岗，设备状态千奇百怪：有老师用八年前的笔记本，有老师用教学一体机，还有人外接采集卡。我把见过的设备问题整理成下面这张表，排故障时直接按行对照：

回声是扬声器行最容易踩的坑：老师图省事用外放，麦克风把外放的声音再收一遍，学生听见双重讲话声，久了还会啸叫。我们的规矩是强制老师戴耳机上课，第一次进课堂页面时就提示连接耳机，这一条比任何降噪算法都管用。

设备授权是另一个高频问题：浏览器默认会问用户是否允许使用摄像头和麦克风，老师手快点了个拒绝，页面就永远黑屏，而且拒绝之后不会弹第二次——得去浏览器设置里手动改。我们的做法是在页面显眼位置放一个设备检测入口，授权失败时给出图文引导，告诉他怎么在浏览器里恢复授权。光是这一个引导，就把开课十分钟里最常见的求救量砍掉一半。

屏幕共享的三种场景

编程课的最高频动作就是屏幕共享：老师敲代码给学生看。共享方式有三种，适合的场景完全不同：

我们最后选共享窗口为主、共享屏幕为辅：编程课九成时间在编辑器里，单窗口共享最干净；个别需要切浏览器查资料的环节，切到整屏。这个组合是观察了两位老师实际上课之后定下来的，光在控制台里想是想不到的。

还有一个细节：共享整屏时系统通知要关掉，否则学生能看到老师收到的全部消息提示，既难看也可能有隐私问题。Windows 系统的通知开关在设置里，Mac 上更彻底，直接在控制中心开勿扰模式，我们把这一步也写进了备课清单。

屏幕共享和摄像头能同时开吗

这是被老师问得最多的问题，答案是可以，但有代价。同开两路采集意味着编码压力翻倍，中低端电脑推流帧率会明显下降；网络上传带宽也得够，两路流加起来码率不低。我们的做法是：默认只开一路（要么摄像头要么共享），需要同开时把摄像头画面缩成小窗压在共享画面角落，并且摄像头流降一档分辨率。同时页面上实时显示帧率，老师自己能看到卡不卡，不用等技术告诉她。

第一次做同开的那天踩了个小坑：共享窗口打开之后，摄像头流的渲染容器被挤到屏幕外，学生只能看见共享画面里有个小黑角。这类布局问题在那之后统一用固定比例的容器解决，容器尺寸一旦定死，流怎么变都不会乱跑。

设备异常排查表

上课中设备出问题，排查时间按秒计。下面这张表是我们从二十多节课的事故记录里提炼的，助教人手一份：

排查顺序有个小窍门：先问声音还是画面，再看自检面板对应的电平或帧率，两秒定位到是采集、推流还是渲染环节。比一上来就让老师重启电脑快得多——重启十分钟课就上不了了。

设备热切换：上课中途换摄像头

热切换指的是推流过程中不停机地换设备。最典型的场景是老师上课上到一半，发现摄像头画面糊了，想换另一个。实现要点有三个：一是切换前先确认新设备已经采集成功，不要先断旧的再等新的，画面会黑屏好几秒，学生会以为是掉线；二是切换动作要做防抖，避免老师误点连切两次，加个一秒的节流就够了；三是切完之后立刻在监看面板里给老师一个反馈，告诉她切换成功了。我们第一版没做反馈，老师连点三次，自己也不知道切到哪台了，反而以为坏了叫技术支援。

虚拟背景这行也有故事。机构要求老师出镜讲课增加亲和力，有些老师家里背景杂乱不想露脸，我们就上了虚拟背景。结果第一版在差点的电脑上疯狂占性能，推流帧率直接掉一半，画面反而更卡。最后的处理是虚拟背景作为可选项，并且只在检测到机器性能富余时才开放——性能不够的老师只能选不模糊的纯色遮罩。功能让位于体验，这条原则在有弱网压力的教学场景里尤其重要。

另外一个隐藏问题：拔插 USB 摄像头后系统设备列表会刷新一次，已经失效的设备 ID 还留在页面缓存里，老师点一个不存在的设备当然黑屏。我们的处理是监听设备变化事件，列表变了就清缓存重建，宁可用的时候慢半秒，也不要给老师一个点不了的选项。

一堂推流事故的复盘

讲了这么多预防手段，反面案例更能说明问题。有一节数学思维课，老师用外接 USB 摄像头，上课中途不小心碰松了线，画面瞬间定住。当时热切换逻辑只做了主动切换，没处理设备掉线，链条断了：页面还以为在推流，实际采集已经停了，学生对着定格画面听了八分钟。助教从自检面板看到帧率归零才打电话过去，老师重启了摄像头，剩下半节课才恢复正常。

复盘时我们加了三层保险：一是监听到设备掉线立刻提示老师并暂停推流，绝不允许空推流占着房间；二是画面定格超过 10 秒主动在学生端打一行提示（持续黑屏不说话，学生会以为是自己网络问题）；三是把摄像头线材换了磁吸接口的，物理层面也加固一下。三层保险的成本都很低，但每一层都解决一个具体环节：发现、通知、根因。这件事之后我们内部的规矩是：所有故障复盘必须落到三个动作上——怎么更早发现、怎么更快告知用户、怎么从根上避免重演，光靠老师注意是不够的。

推流质量自检清单

老师端推流一旦出问题，整堂课都受影响，所以我们给老师端做了一套自检面板：推流帧率、码率、分辨率、网络质量、采集设备状态全部实时显示。老师看不见这些数据没关系，技术巡课的助教看得见。这套面板救过好几次场——有一次老师没发现摄像头被另一软件占用，画面定住整整三分钟，助教在监控里看到帧率归零，直接电话打过去提醒重启。

自检面板要看哪些项，整理如下：

面板不需要做得多酷炫，把数字摆清楚就行。关键是让运维和助教能在上课时不依赖学生反馈就发现问题——等学生投诉再排查，课已经上完一半了。

网络质量回调与降级策略

TRTC 在通话过程中会周期性抛出网络质量回调，把上下行质量分成优、良、中、差几档。我们在老师端监听这个回调做两件事：第一件是把质量画进老师的监看面板，让老师自己知道当前网速，网差时她可以主动少动屏幕、少切窗口；第二件是触发降级。降级顺序我们固定下来：先降远端视频（关学生画面保老师画面），再降帧率，最后降分辨率；音频永远不降，宁可学生看不清楚，也得听见老师讲话。这套顺序不是拍脑袋定的，是两次翻车之后调出来的，具体怎么定档在下一节展开。

备课资料的沉淀也值得花心思，我们后来把每节课的素材、代码和笔记放到站点上供学生复习，相关的组织做法可以翻翻Discuz 社区站实战的资料管理思路，论坛化的目录比网盘好找得多，学生还能在帖子里提问。

网络质量回调拿到手之后，比回调本身更重要的是怎么用它做决策。我们的经验是别在每一帧的波动上做反应——质量回调本来就是周期性的采样，一次波动不代表什么。真正稳定触发降级的信号是连续多次回调都是差：我们取连续三次差才降级，连续三次良以上才升档。这样既避免了误降，也给恢复留了观察窗口。阈值定多少不神秘，先把课上常见的网络环境测一遍，取中间值留余量即可。

老师不会操作：一页备课清单

技术方案再好，老师不会用都是零。我观察了几次实际上课，发现开课前五分钟最兵荒马乱：不是找不到共享按钮，就是麦克风没声音，最离谱的一次有老师对着黑屏讲了十分钟。于是做了一页图文备课清单贴在讲台边，要求课前逐项打勾：

清单看着土，但把每节课的开课事故率降了七成。所谓开课事故，十次里有八次不是技术问题，而是流程问题——老师不知道该先做什么。页面的交互设计也有讲究，我们把清单做进了课堂页的开课引导里，一步一步带着点，老师再也不用同时面对十几个开关，这方面AI 网站搭建实战的引导式表单思路可以借鉴。

延伸阅读

• 腾讯云五件套实战：网络质量与监控指标的基础概念。
• 轻量建站实战：课堂站点与服务器的配合部署。
• AI 网站搭建实战：课堂页面交互与开课引导的设计。