如何解决WebRTC对等端间发送重复音视频轨道的问题

问题1：为何getUserMedia()返回的同类轨道ID不同？ #

每次调用getUserMedia()，浏览器都会创建全新的MediaStreamTrack实例，哪怕使用同一设备、相同参数。这意味着确实存在两条独立的音/视频数据流——每个轨道实例都会从设备发起独立的采集会话，生成各自的媒体流，并非同一数据流复用不同ID。

问题2：getSenders()返回4条轨道是否正常？是否会导致远端数据量翻倍？ #

这种情况不正常，属于错误用法导致的冗余。每条轨道都会对应一条独立的传输流，远端会接收到2条音频和2条视频数据流，数据量确实会翻倍，还会额外占用带宽、设备资源与编码性能，甚至可能引发远端播放异常（比如双音频流叠加产生杂音、回声）。

问题3：应由谁负责消除重复轨道？ #

必须由发送端程序负责，浏览器不会自动处理重复轨道。正确的实现逻辑是：

• 初始化阶段仅调用一次getUserMedia()，将获取到的音视频轨道保存为全局变量
• 监听negotiationneeded事件时，先通过peerConnection.getSenders()检查对应类型的轨道是否已存在
• 若已存在，调用sender.replaceTrack(existingTrack)更新轨道（轨道无变化时可直接跳过操作）；若不存在，再调用addTrack()添加轨道

备注：本文中的streams并非指MediaStream对象，而是指WebRTC对等端间传输的真实音视频数据流。

内容的提问来源于stack exchange，提问作者Tobic