Akagi201
11/25/2015 - 3:29 AM
srs.md
时间戳矫正
- https://github.com/ossrs/srs/issues/425
- http://blog.csdn.net/zjqlovell/article/details/51791989
- https://github.com/ossrs/srs/wiki/v2_CN_TimeJitter
公司
- 观止创想: http://www.chnvideo.com/
调试
- http://ossrs.net:1985/console/ng_index.html#/vhosts?host=127.0.0.1&port=1985
- 可以看到服务器的状态。包括上面的vhost和流。把host和port换成你的服务器的ip和端口。
ffmpeg
- 直接在服务器中用 ffmpeg 的库, 有几个问题, 首先, srs 是单进程的, 调用这种库消耗太多 CPU, 会影响其他连接. 其次, ST的切换, 在纯粹 CPU 运算时是不会切换的, 也就是说系统误差会变大.再次, ffmpeg 那个库太复杂, 容易出问题, 一挂的话服务器就挂了. 最后, ST 最擅长是做IO, 而且, 这种很偏的库, 超过它的最常用场景, 会不太好.
- 所以, 应该把所有复杂协议, 还有 CPU 密集型运算变成 IO. 也就是外挂 golang 进程, 服务器和 golang 用 http api 通信. 这样就无形中用了多进程了, 很松散的架构.
多进程
- 多进程这个也是, srs 不做多进程, 因为复杂了. 可以 fork golang 的进程, 用来做数据处理, 譬如: bitch, 或者混音, 或者协议转换, 如bocar. 这样, 流媒体还是简单的单进程, 但是周边复杂的运算可以把 CPU 耗了.
- 悟空你们是服务器多进程, 我们是业务分离的多进程. 而业务的实现是golang, 所以, 也是协程加多进程. 这种架构会比较好维护.
混音
- 服务器把包送给 golang 进程, golang 解码 PCM 了混音再编码为 AAC 送给服务器.
- 音频本身就是有 pts 的, 采样个数和采样率就能决定 pts 了. 视频就不行, yuv没有说一秒钟多少个.