ApiRTC带系统音频的屏幕共享isScreensharing参数异常及配置咨询

• 触发该问题的核心原因是ApiRTC在推送「屏幕共享+系统音频」的组合流时，会将内容拆分为两条独立流传输：一条为屏幕视频流，一条为系统音频流。仅屏幕视频流的isScreensharing参数值为true，系统音频流的该参数默认为false，你可在事件回调中先判断流的type属性为video后再读取isScreensharing参数即可拿到正确值。
• 若上述操作后仍未拿到正确值，可检查调用createScreenShareStream方法时是否添加了publishScreensharingTag: true配置，该参数默认关闭，开启后平台才会为屏幕共享流打上对应标记，事件回调才会返回正确的isScreensharing值。

你提供的配置如下：

{
    qos: {
        videoStartQuality: 'excellent',
        videoMinQuality: 'excellent',
        videoMinBitrate: 1500,
        videoStartBitrate: 2500
    },
    simulcast: {
        encodings: {
            high: {
                maxBitrate: 2500 // kbps
            },
            medium: {
                maxBitrate: 1500, // kbps
                scaleResolutionDownBy: 2
            },
            low: {
                maxBitrate: 800, // kbps
                scaleResolutionDownBy: 4
            }
        }
    }
}

该配置的适配场景及可优化点如下：

• QoS配置：当前videoMinQuality设为excellent、最低码率1500kbps的配置，仅适配高清屏幕共享为主的场景（如代码评审、设计稿演示），如果是通用视频会议场景，该配置阈值过高，弱网用户会出现频繁卡顿、断流问题，可调整videoMinQuality为low，videoMinBitrate下调至300-500kbps兼容弱网环境。
• simulcast配置：当前三层编码的层级划分合理，若主要用于屏幕共享场景，可做两处优化：
  1. 为每层编码添加maxFramerate限制，high层设为15，中低层设为10，屏幕共享多为静态内容，降帧率后清晰度感知差异极小，可节省20%-30%带宽
  2. 若产品支持4K分辨率屏幕共享，可将high层的maxBitrate上调至4000-6000kbps，避免文字、细线条内容发虚；若最高仅支持1080P共享，当前2500kbps的配置足够使用
• 额外注意：全局的simulcast配置默认仅对摄像头流生效，若需要为屏幕共享流开启simulcast，需要在调用createScreenShareStream时单独传入对应simulcast配置。

内容的提问来源于stack exchange，提问作者Giovanni Cucè