Skip to main content
本页是类型参考。所有类型都从 srtc 直接导出:

枚举

Codec

编解码格式。数值是国际标准的编码标识,与其它端一致。 配套函数:codecSdpName(codec)codecIsVideo(codec)codecIsAudio(codec)codecFromSdpName(name)codecFromValue(v)ALL_CODECS
H264 / H265 在 HarmonyOS 上只有硬编、没有软编兜底。设备不支持时 SDK 不报错而是静默退回 VP8,请用 isCodecSupported(Codec.h264)videoCodecReport() 核对,详见错误码

TrackKind

ConnectionState

MediaConnectionState

媒体面(PeerConnection)连接状态,由 channel.mediaState 读取、onMediaStateChange 上报。 配套函数:mediaConnectionStateName(s)
它与 ConnectionState 不是同一条线,不要合并成一个状态。信令面(MQTT)与媒体面(PeerConnection)会各自独立地断开和恢复:信令断了媒体流往往照旧(SFU 不经信令通道转发媒体),反过来媒体通路失败时信令通常一切正常。把两者当成一条线会导致两种故障:只看信令 → “网络恢复提示已消失、画面还是黑的”;只看媒体 → 成员列表早已不再更新却毫无提示。UI 上的网络异常提示应当同时接这两条线。disconnected 意味着 SDK 已经放弃重连、不会再自行恢复,此时应引导用户重新入会。

DisconnectReason

配套函数:disconnectReasonFromValue(v)

DeviceType

上报的端侧类型。HarmonyOS 是 8(与错误码前缀 108 配套)。 常量 CURRENT_DEVICE_TYPEDeviceType.harmonyOS。配套 deviceTypeFromValue(v)

DeviceKind

VideoRotation

CameraPosition / CaptureOrientation / ScreenCaptureMode

TrackPriority / DegradationPreference

配套函数:trackPriorityBitrateWeight(priority)

AudioRoute / AudioRouteTarget / AudioCallState

AudioRouteAudioRouteTarget 多三个成员,是因为蓝牙与有线耳机由系统接管 —— SDK 能上报你现在走的是它们,但不能主动切到某个具体外设 配套函数:audioRouteNameaudioRouteTargetNameaudioRouteTargetAsRouteaudioRouteIsExternalaudioRouteIsBuiltInaudioCallStateName

ConnectionQuality

配套函数:worseQuality(a, b) —— 取两者中较差的一个。

StreamVendor

由服务端下发决定,配套 streamVendorFromValue(v)

LogLevel

SRTCLogger 的级别。设置方式是 srtc.logLevel = LogLevel.info。 配套函数:logVerbose / logDebug / logInfo / logWarning / logError, 以及可替换的 LogHandler

入会与频道

JoinOptions

defaultJoinOptions() 返回一份全默认的选项。
两个 autoSubscribe* 默认都是 false,与部分同类 SDK 相反。典型现象是 “入会成功但听不到、看不到别人”。

ChannelInfo

配套:channelInfoFromJson / channelInfoToJson

UserInfo

配套:userInfoFromJson / userInfoToJson

轨道

TrackInfo

配套:trackInfoFromJson / trackInfoToJson / cloneTrackInfo

SimulcastInfo

配套:simulcastInfoFromJson / simulcastInfoToJson

采集参数

MicCaptureOptions

CameraCaptureOptions

采集分辨率受设备档位限制,档位表因机型而异。 底层会把请求宽高吸附到最近的档位, 所以实际拿到的尺寸可能与设定值不同。这也是必须调用 SRTC.init(context) 的原因 —— 没有 Context 就查不到档位表。

ScreenCaptureOptions

ScreenAudioCaptureOptions

其它

  • VideoCaptureParamswidth / height / frameRate
  • CaptureSizewidth / height,配套 orientCaptureSize(size, orientation)
  • ZoomRangemin / max / supported。设备变焦范围,由 track.zoomRange() 返回。 supported === falsemin / max 均为 1,调用方不必判空。 ⚠️ 它反映的是当前这一刻能不能变焦而不是设备能力,详见 轨道接口
  • 默认值函数:defaultMicCaptureOptions() / defaultCameraCaptureOptions() / defaultScreenCaptureOptions() / defaultScreenAudioCaptureOptions()
  • 合并函数:mergeMicCaptureOptions() / mergeCameraCaptureOptions() / mergeScreenCaptureOptions() / mergeScreenAudioCaptureOptions()

发布参数

AudioPublishOptions

VideoPublishOptions

默认值:defaultAudioPublishOptions() / defaultVideoPublishOptions(); 合并:mergeAudioPublishOptions() / mergeVideoPublishOptions()

预设

预设是「采集参数 + 发布参数」的成对封装,直接传给 createLocalXxxTrack 现成预设:

质量与信令消息

QualitySample

QualityReport

QualityEvaluation / ConnectionQualityChange

活跃说话人

LayerSwitchedInfo

Simulcast 层切换。 配套解析函数:qualityReportFromJsonactiveSpeakersFromJsonlayerSwitchedFromJsonsignalMessageType

RtcStatsSnapshot

channel.getStats() 返回的一次采集快照。

OutboundStreamStats

判断”某条轨道的 RTP 有没有在发”必须用 trackIdentifier 匹配,不能只看”有任意一条 outbound 的 packetsSent > 0”。取消发布后 transceiver 只是 stop、不从连接上移除,它那条旧统计会一直留在报告里(真机实测:关掉摄像头再重开,旧统计的 packetsSent 卡在原值不动)。
qualityLimitationReason 是弱网排障的第一现场:bandwidth 说明码率被带宽估计压了,cpu 说明设备扛不住,两者的处理完全不同。

InboundStreamStats

kindssrc?codec?bitrateKbpspacketsReceived?packetsLost?(本端统计)、jitter?,不是毫秒)、frameWidth? / frameHeight?framesPerSecond?totalFreezesDuration?(累计冻结秒数,卡顿的直接指标)。

ConnectionStats

availableIncomingBitrateKbps 实测恒为 undefined 海思平台(nova 12 Pro / OpenHarmony-6.1.1.120)的 candidate-pair 统计里没有这个字段(上行那个有)。W3C 规范里它本就是可选的,底层只在部分路径上填。保留该字段是为了对齐 W3C 与其它端的结构,不要在 UI 上依赖它 —— 要展示下行状况请用 inbound 各路 bitrateKbps 求和。
配套函数:emptyStatsSnapshot()(空快照,取不到统计时返回它而不抛错)、 statsSummary(s)(压成便于阅读的多行文本,形如 发送 video H264 1180kbps 1280x720@30 (bandwidth) 丢包=3)。

协商结果

这是”视频到底是不是 H264”唯一可靠的判据。要传 answer(本端发布看远端 answer,本端订阅看远端 offer)—— offer 里是候选列表,只有 answer 才代表最终选中的那一个。不要拿 videoCodecReport() 核对:它回答的是设备能不能 H264,而静默降级恰恰发生在能力表漂亮、协商结果却是 VP8 的情况下,拿它核对等于没核对。SDK 内部在每次协商后已自动打日志,真机排障可直接 hdc shell hilog -x | grep -a 协商结果

设备与消息

DeviceInfo

配套:deviceKindFromValuedeviceListEqualsdeviceListDiff

AudioRouteInfo

CustomMessage / ImMessage

content 统一是字符串 —— 需要结构化数据请自己 JSON.parse

Token

解析与校验:decodeChannelToken(str)decodeImToken(str)isTokenExpired(token) Token 由业务后端签发,SDK 只负责解析与过期判断。

服务端配置

由入会响应下发,一般不需要直接构造: MqttServerWebrtcServerTurnServerUploadServerRtmpServerChannelJoinResponse 解析函数:mqttServerFromJsonwebrtcServerFromJsonchannelJoinResponseFromJsonchannelJoinResponseAsChannelInfo

工具类型

JSON 读取工具(ArkTS 禁止对任意对象下标访问,所以统一走这层): asObjectgetStringgetNumbergetBoolgetObjectgetArraygetStringMapgetAnyMapmapToObjectputIfPresent

相关阅读