问题场景
开发者在接入实时音视频终端组件 TRTC SDK时，开发者或者线上用户难免会遇见进房失败、接受到的观看端画面卡顿等情况。开发者可以通过 腾讯云实时音视频（TRTC）控制台 的 【监控仪表盘】功能来快速定位问题。另外，TRTC SDK 也有仪表盘，里面的指标数据也能用来排查定位问题。
本地预览仪表盘
其中上行仪表盘各个指标含义如下：
仪表字段 | 字段含义 | 示例指标 | 指标含义说明 |
|---|---|---|---|
LOCAL | 用户Id | 572389 | userId, 即您在 TRTCParams 的 userId 字段中所指定的用户名 |
RTT | 网络延迟 | 13ms | SDK 跟服务器一来一回之间所消耗的时间，这个值越小越好，一般低于 50ms 的 RTT 是比较理想的情况，而高于 100ms 的 RTT 会引入较大的通话延时。 |
SEND | 发送端总速率 | 471kbps | 每秒钟发送的音视频数据是多少 |
LOSS | 网络丢包率 | 0-0-0-0 | 0-0-0-0 | 0% | 视频最终丢包率 - 视频FEC恢复了几个包 - 视频ARQ恢复了几个包 - 视频原始丢包率 | 音频最终丢包率 - 音频FEC恢复了几个包 - 音频ARQ恢复了几个包 - 音频原始丢包率 | 网络丢包率 |
BIT | 音视频码率 | 175 | 0 | 40kbps | 大画面编码码率 | 小画面编码码率 | 音频码率 kbps |
RES | 分辨率 | 368x640 | 上行推流的分辨率 |
FPS | 视频帧率 | 10 - 11 | 编码帧率 - 后台实际接收帧率 |
FEC | 前向冗余数据比例 | 100% | 50% | 视频FEC比例 | 音频FEC比例 |
ARQ | 重传数据 | 0 | 0kbps | 视频ARQ码率 | 音频ARQ码率kbps |
RPS | 帧参考距离 | 0 | 两个参考帧的距离 |
CPU | CPU 使用率 | 22% | 63% | App CPU使用率 | 系统CPU使用率 |
QOS | 流控策略 | HOLD | 450kbps | 100-100 | 调控状态 | 建议视频编码码率kbps | 上次建议视频FEC比例-当前建议视频FEC比例 |
SVR | 服务器地址 | 111.230.97.102 | TRTC 后台服务器地址 |
远端视频仪表盘
其中下行仪表盘各个指标含义如下：
仪表字段 | 字段含义 | 示例指标 | 指标含义说明 |
|---|---|---|---|
REMOTE | 用户Id | 603101 B | userId(用户标识)，当前收看的流类型: B 大画面; S 小画面; Sub 辅路 |
RTT | 网络延迟 | 14ms | SDK 跟服务器一来一回之间所消耗的时间，这个值越小越好，一般低于 50ms 的 RTT 是比较理想的情况，而高于 100ms 的 RTT 会引入较大的通话延时。 |
RECV | 接受端总速率 | 272kbps | 每秒钟接受的音视频数据是多少 |
LOSS | 网络丢包率 | 0-0-0-0 | 0-0-0-0 | 0% | 视频最终丢包率 - 视频原始丢包数 - 下行视频实际丢包率 | 音频最终丢包率 - 音频原始丢包数 - 下行音频实际丢包率 | 下行网络丢包率 |
BIT | 音视频码率 | 232 | 40 kbps | 视频码率 | 音频码率 kbps |
RES | 分辨率 | 368x640 | 下行接受到的分辨率 |
FPS | 视频帧率 | 13 - 14 | 渲染fps - 网络接收帧率 |
FEC | 前向冗余数据比例 | 0 - 0 - 0% | 0 - 0 - 50% | 视频FEC恢复包数 - 视频原始丢包数 - 视频FEC比例 | 音频FEC恢复包数 - 音频原始丢包数 - 音频FEC比例 |
ARQ | 重传数据 | 0 - 0 | 0 - 0 | 视频ARQ恢复包数 - 视频ARQ请求数 | 音频ARQ恢复包数 - 音频ARQ请求数 |
CPU | CPU 使用率 | 24% | 59% | App CPU使用率 | 系统CPU使用率 |
RPS | 帧参考距离 | 1 | 两个参考帧的距离 |
LFR | 视频丢帧数 | 2 | 播放器播放远端视频流，丢视频帧的个数 |
DERR | 视频解码失败数 | 0 | 解码器解码接受到的视频帧失败次数 |
JIT | 视频解码失败数 | 160，142 | 2，0 | 2 | 音频缓存时长 ， 视频缓存时长 | 视频jitterbuffer缓存帧数， 视频解码器缓存帧数 | 音频总丢包数 |
