2016年11月 – 大蕉

WebRTC Native code在MacOS编译踩坑记

想编译WebRTC的源代码，想测试下一些东西。其实官方有说明怎样编译的。理论上也是比较简单的。但是非常不幸的是。webrtc的源代码在墙外。这个源代码据称有8G那么大。不过最后发觉压缩后还有10G多。

代码怎样下载？虽然webrtc用的是git管理代码，但是他的下载是用另外一套工具下载的，具体为什么我也不知道。而且我发觉他下载的代码除了webrtc外还包含了chrome的代码，还有一些第三方的工具。下载这个代码最困难的是由于是巨大的容量，而且不支持断点续传。google是怎样想的，这么大的容量还不支持断点。虽然可以挂VPN进行代码下载。但是需要非常稳定的VPN。而且速度也要快。我想不出哪里可以提供这么稳定的vpn，有时候不是vpn不稳定，而是自身网络也不一定稳定。现在想到的办法是在海外创建VPS服务，把代码拉好了。然后打包下载回来。

由于本身在DigitalOcean有VPS。所以就在上边进行拉取。由于用的是最低的配置，没有拉多久，git就报内存不足了。TMD的。谁叫你穷，买的是512M的内存服务器，现在手机的内存都比你多尼？最后找了国内的云主机供应商的香港云主机。搞个4G内存。下载代码就是非常快了。最后把代码拉到Mac上。不过发觉编译有问题。

第一个问题：

>gn gen out/mac –args=’target_os=”mac” target_cpu=”x64″ is_component_build=false’
gn.py: Could not find gn executable at: /Users/daozhao/Documents/sourcecode/WebRTCdemo/webrtc_macos_test/src/buildtools/mac/gn

找不到命令，怎么搞的。居然找不到命令。看了看gn的代码，发觉有一个chromium编译路径可设置在环境变量的。然后我设置了这个，在这个目录下再创建了一个mac的目录。把depot tools工具都放在这个mac目录中。

export CHROMIUM_BUILDTOOLS_PATH=XXXXXXXX

这样重要可以运行gn生成工具了。结果有悲剧了。又显示了一个错误。

gn fork: Resource temporarily unavailable

网上google了这个错误。没有发现编译webrtc的时候有别人出现这个错误，在其他地方会会出现这个错误，原因是mac os系统有限制创建线程数量。大家可以输入。

>launchctl limit
cpu unlimited unlimited
file size unlimited unlimited
data unlimited unlimited
stack 8388608 67104768
core 0 unlimited
rss unlimited unlimited
memlock unlimited unlimited
maxproc 709 1064
maxfiles 256 unlimited

最后把参数调大。但是还是报同样的错误。现在我怀疑mac有专用的gn工具的。在同步代码的时候应该是根据系统下载相关的工具。由于我是使用linux系统下载的代码，下载了linux的编译工具，没有下载mac的工具。需要再次运行gclient sync，当然运行这个命令是需要vpn的。但是由于有之前的下载，不用所有东西都重新下载，只是下载很少一部分工具而已。

rm src/links ＃需要先删除这个文件，要不然会报错。
gclient sync
rm -rf src/third_party/llvm-build
gclient sync

这时候可以从新运行gn生成工具了。

>gn gen out/mac –args=’target_os=”mac” target_cpu=”x64″ is_component_build=false’
Done. Made 347 targets from 107 files in 5461ms

到了这里就可以编译了，编译时间比较久，

WebRTC入门指导

这篇文章是记录之前研究的webRTC的记录，最近准备再次走进WebRTC，所有写下一些资料，以免忘记的时候可以看看。

入门看什么文章比较好，当然是WebRTC的官方网站的Getting Started。不过资料比较多，而且上边列表的资源重复也不少。

Getting started的推荐的2013的google IO关于WebRTC的视频就别睇了，没有什么营养。大家看这三篇对webRTC入门的文章比较好，Getting Started with WebRTC和WebRTC in the real world: STUN, TURN and singling，WebRTC data channels，基本上把WebRTC的结构说得个明白。可以对WebRTC有一个很好的整体了解。

对于入门的代码例子就看这个codelab，进阶少少的例子就看WebRTC samples和WebRTC-Experiment，还有一个完全可以用的Demo的线上例子，别忘记了这个Demo的有很多参数可以调整的，请查看参数设置。

看完上边的资料，你已经对WebRTC有了基本的了解了。如果你做WebRTC的前端或者关于Signaling的后端开发，这些知识基本够用了。不够如果要深入研究WebRTC，需要做二次开发或者做MCU的话就需要进入步研究了。

由于WebRTC是P2P的，首先需要研究的了解UDP打洞。关于打洞的问题请看Peer-to-Peer Communication Across Network Address Translators这个是关于P2P的网络神作。如果觉得文章复杂，不如先看看这些入门级的文章:穿越防火牆技術，P2P通信原理与实现。再找些开源的STUN服务器研究下。

其实需要研究的东西还是比较多的，不过站在巨人的肩膀好办事。这里列几个比较出名的WebRTC开源项目吧，

1. http://www.kurento.org/

2.Licode

3 https://doubango.org/ 这个是项目有SIP的部分，有webrtc2sip的转换。兼容SIP系统较好选择。

4. https://mediasoup.org/ 这个是nodejs ＋ c的项目，属于SFU，不是mcu。

5. https://janus.conf.meetecho.com/ Janus一个比较出名的项目，纯C写的项目。

WebRTC有一个比较烦人的问题，Web服务必须使用https来部署，要不然浏览器不给使用相关的api，这样做开发测试的时候比较麻烦。

golang 与cgo的跨平台编译

golang语音本身是支持跨平台编译的，只要在编译的时候添加相应的选项就可以了。不过有一个问题是不支持带有cgo的程序。如果需要支持cgo还需要配置编译cgo的环境，如果一个带cgo的程序需要编译成多个平台的支持，那是一件痛苦的事情，或者需要编译成非开发机本机运行版本，也是一件麻烦事。特别是开发嵌入式arm程序的时候就编译环境的配置就特别麻烦。不过现在有万能的docker对配置进行了简化。

由于工作需要，之前自己做了一个docker编译go 和cgo在android上运行的images，不过当时是手工制作images，并没有记录制作步骤和写下dockerfile。由于目前go和android的版本升级比较快。所以原来的docker images已经不合时宜了。不想再自己去做这个images了。在网上搜索了一个Go CGO cross compiler这个docker images比自己做的强大很多，支持很多平台的编译。使用起来比较方便。大家可以看看说明就可以了。非常方便。

由于这个docker的操作非常自动，可以说太自动了。例如，编译的项目必须在git上，自动下载项目和项目相关的库。对于一些不在git上的公司内部项目不是很友好。而且好像每次都重新下载项目和关联的代码库。导致编译速度非常慢，本来就是比较慢了。所以我没有使用它提供的的xgo工具。只使用它的docker images。

这个docker images的使用方法官方并没有说明。不过通过其dockerfile可以窥探其秘密。

进入这个docker的命令是：

docker run -it –entrypoint /bin/bash karalabe/xgo-latest

因为这个docker设置了entrypoint是根目录的build.sh，需要把它替换成bash。这个docker的go path位于/go目录中，代码需要放在/go/src目录中。然后可以运行/build.sh XXXX 进行项目编译。当然可以归宿主机的代码映射到docker目录中并自动运行编译那时最方便的。

docker run –rm -it \
-v “$PWD”:/build \
-v “$PWD”/vendor:/go/src \
-v “$PWD”:/go/src/XXXXX \
karalabe/xgo-latest XXXXX

＃XXXX代表你的项目目录名称。这里把项目需要包含的依赖包也一并映射到docker的/go/src中。

这样就可以很方便编译出各个平台运行的版本可执行文件，包括windows，macOS，iOS，android，linux，arm等。不过大多数我们并不需要编译这么多平台的版本，很多时候我们只需一个版本就够了。这样可以节省很多的编译时间。

docker run –rm -it \
-v “$PWD”:/build \
-v “$PWD”/vendor:/go/src \
-v “$PWD”:/go/src/XXXXX \
-e TARGETS=android/arm \
karalabe/xgo-latest XXXXX

这样写就可以只编译android的arm的版本。具体TARGETS支持什么参数，请参考官方说明。

RTMP转换成TS流的注意事项

RTMP转换成TS流的注意事项,

一需要注意PCR的标记，虽然有人说PCR不是必须的，但是如果你标记PCR的话，必须写对PCR，开始做的时候，因为看见网上的评论说，ipad和苹果的系统并不检查PCR的。所以我就乱打，结果在windows上播放出问题，windows上的媒体播放器会播放得特别快，他是根据PCR的时间播放的。

另外PCR的字段生成，不是简单的＝DTS就可以了。PCR的组成是33(PCR_Base)+6(PCR_const)+9(PCR_Ext) ，计算方法参考下边，此方法是参照SRS的计算方式，另外stackoverflow有另外一个方式计算。我觉得SRS的计算方式更加好理解。
PCR_Ext = 0; PCR_Const = 0x3F; int64_t pcrv = PCR_Ext & 0x1ff; pcrv |= (PCR_Const << 9) & 0x7E00; pcrv |= (PCR_Base << 15) & 0xFFFFFFFF8000LL;

pp = (char*)&pcrv;
data[ 6] = pp[5];
data[ 7] = pp[4];
data[ 8] = pp[3];
data[ 9] = pp[2];
data[10] = pp[1];
data[11] = pp[0];

programClockReferenceBase := (pcrv & 0xFFFFFFFF8000) >> 15
programClockReferenceExtension := pcrv & 0x1FF
constValue := (pcrv & 0x7E00) >> 9
s =float64(programClockReferenceBase * 300 + programClockReferenceExtension) / 27000000

继续阅读“RTMP转换成TS流的注意事项”