背景信息:csdn第一篇博客
webrtc版本,更新代码时间:2018年12月24日,分支:master
目标:打造多方音视频通讯实验平台
思路:
可选方案1: 从顶层peerconnection接口启用,此方案需要涉及大量ICE及Sdp信息的交换,理解与流程梳理,成本高,放弃;
可选方案2: 从mediaengine层api使用,此方案舍弃ICE及p2p相关逻辑,可按照多方音视频会议模式自行实现信令系统;而且mediaengine层有一些通道管理逻辑,可方便封装sdk;
综合考虑,选择方案2. 也有从更底层的call层api进行sdk封装的考虑,可以后续考察,可能灵活性强于mediaenging,工作量会增加一些,随着对webrtc理解的逐渐深入,后续可以重点考察。
win 版本具体思路,封装动态库,调用webrtc media接口:
vs 工程生成步骤:
1, 通过vs2017打开cmd 终端
2,set DEPOT_TOOLS_WIN_TOOLCHAIN=0
3. 建立特定的目录,配置args.gn:
gn生成vs2017文件时,具体参数如下:
target_os="win" target_cpu="x86" is_component_build=false is_clang=false use_rtti=true
注意:win版本不能使用clang编译器,虽然使用clang也可以编译通过,但在自定义的vs工程中无法直接使用webrtc的静态库(会有一些异常crash问题)
4. 自建dll工程,可以直接引用libwebrtc.a, 调用webrtc功能。
android版本思路与win版本一样,sdk封装成so,再引用到android studio中
1. 通过修改gn脚本文件,生成sdk编译脚本,ninja文件,然后通过ninja编译
2. gn基本知识网络上很多,有几个要点这里提一下;
关于生成so的导出函数,脚本中一定要加上下面一行,否则,无法导出纯C的接口函数:
suppressed_configs += [ "//build/config/android:hide_all_but_jni_onload" ]
踩坑经验,使用NDK编译so引入webrtc静态库的方案,坑太多,建议把经历放在gn、ninja编译环境上,笔者被虐半个月得出此经验。
未完待续