存档

2016年11月 的存档

WebRTC Native code在MacOS编译踩坑记

2016年11月28日 3 条评论

想编译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

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

分类: IT, 编程 标签: , ,

WebRTC入门指导

2016年11月14日 没有评论

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

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

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

对于入门的代码例子就看这个codelab,进阶少少的例子就看WebRTC samplesWebRTC-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

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,这样做开发测试的时候比较麻烦。

分类: IT, 编程 标签:

golang 与cgo的跨平台编译

2016年11月2日 2 条评论

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支持什么参数,请参考官方说明。

分类: IT, 编程 标签: , , , , ,

RTMP转换成TS流的注意事项

2016年11月1日 没有评论

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];

另外PCR转换成播放时间的秒的方法,具体方法可以参考stackoverflow的帖子:

pcrv = 0
pcrv |= uint64(pcr[0]) << 40
pcrv |= uint64(pcr[1]) << 32
pcrv |= uint64(pcr[2]) << 24
pcrv |= uint64(pcr[3]) << 16
pcrv |= uint64(pcr[4]) << 8
pcrv |= uint64(pcr[5])

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

阅读全文…

分类: IT, 编程 标签: , , , , , , ,