当完成音视频采集后,可以有3个API可以将媒体流添加到PeerConnection中,本文简单聊下这几个API的使用与区别:
-
addStream
-
addTrack
-
addTransceiver
前提
-
通过getUserMedia采集后的数据类型为MediaStream,MediaStream里面一般包含一个音频和一个视频的MediaStreamTrack(详细了解看这里:juejin.cn/post/692456...
-
WebRTC的sdp有2种类型,一种为plan-b,一种为unified-plan,简单来说unified-plan是一个新的标准(详细了解看这里:juejin.cn/post/689865...
使用姿势
根据历史出现的顺序,分别为 addStream -> addTrack -> addTransceiver,从中可以看到一些信息,一开始是以stream维度来操作,后面变成了以track为维度,可以更精细化控制
addStream
使用方式就是 pc.addStream(mediaStream)
,把整个流添加到pc中,这个API已经被标记为废弃,但是在plan-b模式下还可以使用,如果想要在unified-plan下使用的话,则会报错:
scss
bool PeerConnection::AddStream(MediaStreamInterface* local_stream) {
RTC_DCHECK_RUN_ON(signaling_thread());
RTC_CHECK(!IsUnifiedPlan()) << "AddStream is not available with Unified Plan "
"SdpSemantics. Please use AddTrack instead.";
...
}
addTrack
addTrack是3个API中各个教程、课程出现频率最多的一个API,使用方式也非常简单:
ini
mediaStream.getTracks().forEach(track => {
pc.addTrack(track)
});
addTrack其实是有返回值的,类型为RTCRtpSender
,是一个发送的控制器,这个控制器的用法会在下面讲。
addTransceiver
addTransceiver的使用方式相对来说比较复杂,参数也多,addTransceiver的返回值为RTCRtpTransceiver
是一个收发控制器,包括了一个RTCRtpSender
和一个RTCRtpReceiver
,不但可以控制发布,也可以控制接收。
看下简单的用法和参数:
less
mediaStream.getTracks().forEach(track => {
pc.addTransceiver(track, {
streams: [mediaStream],
direction: 'sendonly', // recvonly sendrecv
sendEncodings: {...}
})
});
可以看到有一个direction的参数,这个实际上对应的是sdp对应audio/video MediaSection部分的direction,通过API设置的direction不同,就可以控制MediaSection的行为:
-
只准备发送:a=sendonly
-
只准备接收:a=recvonly,此时没有track,可以直接填字符串如'audio'
-
既发送又接收:a=sendrecv
sendEncodings里可以控制发送码率,simulcast什么的,设置完成后,也可以通过RTCRtpSender
去修改(通过getParameters和setParameters)
总结
addTransceiver是推荐使用的API,兼容性也不错,Chrome M69就可以使用。
同时也能优雅地实现只生成recvonly的sdp,比如我们准备生成sdp去订阅,这时没有对应的API,这此只能使用下面的方式强行生成sdp中的audio/video MediaSection部分,但是这2个属性已经被标记为废弃了,强烈不推荐使用了
php
pc.createOffer({
offerToReceiveAudio: true,
offerToReceiveVideo: true
});
使用addTransceiver就可以:
css
pc.addTransceiver('audio', { direction: 'recvonly' })
pc.addTransceiver('video', { direction: 'recvonly' })
pc.createOffer()