Unity发布Web端后SRS Player异常，是否为Bug？

针对你遇到的两种启动顺序下的视频异常问题，结合WebRTC和SRS的特性，给出以下排查和解决方向：

1. 检查Unity WebRTC视频轨道的生命周期管理 #

• 页面刷新后，Unity发布端的视频轨道可能未重新初始化。确保在页面load事件触发时，重新创建VideoTrack并添加到PeerConnection，而非仅在Unity启动时初始化一次。
• 排查Unity代码中是否存在视频轨道被意外销毁的逻辑，比如页面刷新后未重新激活Camera的视频捕获流程。

2. 验证SRS服务器的流处理配置 #

• 检查SRS配置文件中的auto_unpublish和stream_timeout参数，若流超时设置过短，可能导致刷新后视频流被服务器自动回收，建议将stream_timeout调整为30秒以上。
• 查看SRS日志（objs/srs.log），搜索subscribe、video track相关内容，确认播放器刷新或发布端先启动时，视频流的订阅状态是否正常，是否存在视频轨道未被识别的报错。

3. 排查WebRTC SDP协商的完整性 #

• 通过chrome://webrtc-internals/对比两种场景下的SDP内容：
  • 若发布端先启动时SDP中缺少m=video行，说明Unity发布端未正确将视频轨道添加到PeerConnection，需检查AddTrack方法的调用时机。
  • 确认SDP中的视频编码格式（如VP8、H.264）在发布端和播放器端一致，避免因编码不兼容导致视频无法播放。

4. 修复播放器的流重新订阅逻辑 #

• 播放器页面刷新后，必须重新创建PeerConnection并发起新的订阅请求，不能复用旧的连接实例。检查播放器代码是否在页面加载后重新执行SRS流订阅流程。
• 确保播放器在订阅时明确指定音视频流类型，避免仅订阅音频轨道。

5. 检查媒体轨道的激活状态 #

• 在chrome://webrtc-internals/中查看视频轨道的readyState和trackEnabled：
  • 若刷新后视频轨道readyState为ended，需确认Unity发布端是否在页面刷新后重新启动了视频捕获。
  • 发布端先启动时，若视频轨道trackEnabled为false，需排查Unity代码中是否存在视频轨道未激活的逻辑。

快速排查步骤 #

1. 打开浏览器控制台，查看WebRTC相关错误日志，定位是否存在轨道添加失败、SDP协商错误等问题。
2. 在Unity代码中添加调试日志，记录视频轨道创建、添加到PeerConnection、激活的时间点，确认流程是否完整。
3. 用SRS官方Web播放器订阅同一流，验证问题出在Unity发布端还是播放器端。

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