python升级导致yum命令无法使用的解决办法

1、报错信息如下：

[plain]view plain copy

 print?

  1. [root@develop bin]# yum  
  2. [root@develop local]# yum -y install prce  
  3. There was a problem importing one of the Python modules  
  4. required to run yum. The error leading to this problem was:  
  5.   
  6.   
  7.    No module named yum  
  8.   
  9.   
  10. Please install a package which provides this module, or  
  11. verify that the module is installed correctly.  
  12.   
  13.   
  14. It’s possible that the above module doesn’t match the  
  15. current version of Python, which is:  
  16. 2.6.1 (r261:67515, Aug 7 2010, 11:36:17)  
  17. [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)]  
  18.   
  19.   
  20. If you cannot solve this problem yourself, please go to  
  21. the yum faq at:  
  22. http://wiki.linux.duke.edu/YumFaq  









错误原因：错误信息描述为 yum 所依赖的python 不相符，请安装相对应的python即可





2、查看yum版本

[root@develop local]# rpm -qa |grep yum

yum-3.2.8-9.el5.centos.1

yum-metadata-parser-1.1.2-2.el5





3、查看python版本

[plain]view plain copy

 print?

  1. [root@develop local]# whereis python  
  2. python: /usr/bin/python2.4 /usr/bin/python /usr/lib/python2.4 /usr/local/bin/python2.6 /usr/local/bin/python2.6-config /usr/local/bin/python /usr/local/lib/python2.6 /usr/share/man/man1/python.1.gz  







果然装了两个版本python





4、执行python，查看到使用2.6.1的版本

[plain]view plain copy

 print?

  1. [root@develop local]# python  
  2. Python 2.6.1 (r261:67515, Aug 7 2010, 11:36:17)  
  3. [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2  
  4. Type “help”, “copyright”, “credits” or “license” for more information.  
  5. >>>  









5、猜测yum调用了高版本的python。





6、解决方法：

查找yum和 yum-updatest文件,并编辑此py文件

[plain]view plain copy

 print?

  1. [root@develop local]# which yum  
  2. /usr/bin/yum  
  3. [root@develop local]# vi /usr/bin/yum  
[plain]view plain copy

 print?

  1. [root@develop local]# vi /usr/bin/yum-updatest  







将

#!/usr/bin/python

改为:

#!/usr/bin/python2.4





然后保存OK.


如果不修改/usr/bin/yum ,则yum无法使用

如果不修改/usr/bin/yum-updatest  会出现如下错误

 File “/usr/sbin/yum-updatesd”, line 35, in <module>
    import dbus
ImportError: No module named dbus

ffmpeg对mp4视频进行TS切片及m3u8索引文件支持hls

要想利用HLS来实现视频的在线播放，就得需要将一个完整的视频文件切割成多个ts视频流，然后利用m3u8的索引文件来播放。基本是利用开源的ffmpeg对mp4视频进行TS切片及建立m3u8索引文件支持hls，提升播放速度。

1.ffmpeg切片命令，以H264和AAC的形式对视频进行输出

ffmpeg -i input.mp4 -c:v libx264 -c:a aac -strict -2 -f hls output.m3u8

2.ffmpeg转化成HLS时附带的指令 

-hls_time n: 设置每片的长度，默认值为2。单位为秒

-hls_list_size n:设置播放列表保存的最多条目，设置为0会保存有所片信息，默认值为5

-hls_wrap n:设置多少片之后开始覆盖，如果设置为0则不会覆盖，默认值为0.这个选项能够避免在磁盘上存储过多的片，而且能够限制写入磁盘的最多的片的数量

-hls_start_number n:设置播放列表中sequence number的值为number，默认值为0

3.对ffmpeg切片指令的使用

ffmpeg -i output.mp4 -c:v libx264 -c:a aac -strict -2 -f hls -hls_list_size 0 -hls_time 5 output1.m3u8 

将输出的 M3u8 可直接使用vlc打开，发现拖动的时候会出现画面丢失的现象，待解决。

ffmpeg  -i output.mp4 -vcodec h264 -vb 1000k -profile baseline -acodec aac -ac 1 -ar 44100 -ab 24 -hls_list_size 0 -hls_time 10 -f hls output.mp4.m3u8

ffmpeg处理RTMP流媒体的命令大全

 ffmpeg处理RTMP流媒体的命令大全,将文件当做直播送至live,将直播媒体保存至本地文件,将其中一个直播流，视频改用h264压缩，音频不变，送至另外一个直播服务流,将其中一个直播流，视频改用h264压缩，音频改用faac压缩，送至另外一个直播服务流,将一个高清流，复制为几个不同视频清晰度的流重新发布，其中音频不变,功能一样，只是采用-x264opts选项….

1、将文件当做直播送至live

[plain] view plain copy

  1. ffmpeg -re -i localFile.mp4 -c copy -f flv rtmp://server/live/streamName  

2、将直播媒体保存至本地文件

[plain] view plain copy

  1. ffmpeg -i rtmp://server/live/streamName -c copy dump.flv  

3、将其中一个直播流，视频改用h264压缩，音频不变，送至另外一个直播服务流

[plain] view plain copy

  1. ffmpeg -i rtmp://server/live/originalStream -c:a copy -c:v libx264 -vpre slow -f flv rtmp://server/live/h264Stream  

4、将其中一个直播流，视频改用h264压缩，音频改用faac压缩，送至另外一个直播服务流

[plain] view plain copy

  1. ffmpeg -i rtmp://server/live/originalStream -c:a libfaac -ar 44100 -ab 48k -c:v libx264 -vpre slow -vpre baseline -f flv rtmp://server/live/h264Stream  

5、将其中一个直播流，视频不变，音频改用faac压缩，送至另外一个直播服务流

[plain] view plain copy

  1. ffmpeg -i rtmp://server/live/originalStream -acodec libfaac -ar 44100 -ab 48k -vcodec copy -f flv rtmp://server/live/h264_AAC_Stream  

6、将一个高清流，复制为几个不同视频清晰度的流重新发布，其中音频不变

[plain] view plain copy

  1. ffmpeg -re -i rtmp://server/live/high_FMLE_stream -acodec copy -vcodec x264lib -s 640×360 -b 500k -vpre medium -vpre baseline rtmp://server/live/baseline_500k -acodec copy -vcodec x264lib -s 480×272 -b 300k -vpre medium -vpre baseline rtmp://server/live/baseline_300k -acodec copy -vcodec x264lib -s 320×200 -b 150k -vpre medium -vpre baseline rtmp://server/live/baseline_150k -acodec libfaac -vn -ab 48k rtmp://server/live/audio_only_AAC_48k  

7、功能一样，只是采用-x264opts选项

[plain] view plain copy

  1. ffmpeg -re -i rtmp://server/live/high_FMLE_stream -c:a copy -c:v x264lib -s 640×360 -x264opts bitrate=500:profile=baseline:preset=slow rtmp://server/live/baseline_500k -c:a copy -c:v x264lib -s 480×272 -x264opts bitrate=300:profile=baseline:preset=slow rtmp://server/live/baseline_300k -c:a copy -c:v x264lib -s 320×200 -x264opts bitrate=150:profile=baseline:preset=slow rtmp://server/live/baseline_150k -c:a libfaac -vn -b:a 48k rtmp://server/live/audio_only_AAC_48k  

8、将当前摄像头及音频通过DSSHOW采集，视频h264、音频faac压缩后发布

[plain] view plain copy

  1. ffmpeg -r 25 -f dshow -s 640×480 -i video=”video source name”:audio=”audio source name” -vcodec libx264 -b 600k -vpre slow -acodec libfaac -ab 128k -f flv rtmp://server/application/stream_name  

9、将一个JPG图片经过h264压缩循环输出为mp4视频

[plain] view plain copy

  1. ffmpeg.exe -i INPUT.jpg -an -vcodec libx264 -coder 1 -flags +loop -cmp +chroma -subq 10 -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -flags2 +dct8x8 -trellis 2 -partitions +parti8x8+parti4x4 -crf 24 -threads 0 -r 25 -g 25 -y OUTPUT.mp4  

10、将普通流视频改用h264压缩，音频不变，送至高清流服务(新版本FMS live=1)

[plain] view plain copy

  1. ffmpeg -i rtmp://server/live/originalStream -c:a copy -c:v libx264 -vpre slow -f flv “rtmp://server/live/h264Stream live=1″ 

Centos67一键安装pptpd VPN

之前有折腾过CentOS 6、7下IPSEC/L2TP VPN一键安装脚本，但是不稳定、不支持IOS，因此换成pptp，并编写一个shell脚本，这个脚本可以单独使用，直接复制或下载执行即可，不用依赖安装包的其它脚本，完成CentOS 6、7下pptpd vpn一键安装脚本，安装如下：

Bare Bones (PPTP) VPN Installer for CentOS6、CentOS7

Installation

To get started with your own secure VPN, simply execute the following commands at your servers command-line: 

yum -y install git
cd /root && git clone https://github.com/MonsterWang/VpnForCentos67.git
cd /root/VpnForCentos67/ && bash vpn_centos67.sh

Statement

This script by other scripts to modify,The original script address is https://github.com/drewsymo/VPN

linux iptables连续端口配置和不连续端口配置

linux iptables可以方便的配置多个端口。其中根据端口的连续性，又可分为连续端口配置和不连续端口配置。

1、连续端口配置

如： 

iptables -A INPUT -p tcp –dport 21:25 -j DROP

注：这里是英文状态下的冒号。

2、使用multiport参数配置不连续端口

如： 

iptables -A INPUT -p tcp -m multiport –dport 21:25,135:139 -j DROP

inotify-tools的inotifywait工具用exclude 和 fromfile 排除指定后缀文件

今天打算使用 inotify-tool 来对线上程序文件进行监控, 因为有些目录是缓存目录, 所以要进行排除, 同时还要排除一些指定的后缀的文件, 比如 .swp 等

需要递归监控的目录为:　/tmp/inotify-test-dir

需要排除的目录为: /tmp/inotify-test-dir/cache

需要排除特定后缀文件: .log .swp 文件

根据网上看的一些资料, 我先做了如下尝试:

/usr/local/bin/inotifywait -mr -e close_write,modify,create,move,delete –exclude ^.*\.(log|swp)$ –exclude “^/tmp/inotify-test-dir/cache” –timefmt %Y/%m/%d %H:%M –format %T %w%f %e /tmp/inotify-test-dir

发现无论如何改, 第一个排除指定后缀 .log 和 .swp 都不生效, 我以为是我写的正则有问题, 又修改了很多次, 还是不行. 没办法再次google, 最终还是让我发现了问题的所在, 原来 inotifywait 不支持两次 –exclude , 否则,后面的规则将覆盖前面的规则.

明白问题的所在后, 再次修改:

/usr/bin/inotifywait -mr -e modify,create,move,delete –exclude ‘^/tmp/inotify-test-dir/(cache|(.*/*\.log|.*/*\.swp)$)’ –timefmt ‘%Y/%m/%d %H:%M’ –format ‘%T %w%f %e’ /tmp/inotify-test-dir

这次ok 通过

———–

inotifywait 有 –fromfile 选项, 可以直接从文件中读入要监控的目录,和排除的目录. 在这里我使用 –fromfile ‘/tmp/inotify-file-list’ 选项

/tmp/inotify-file-list 文件的内容如下:

/tmp/inotify-test-dir

@/tmp/inotify-test-dir/cache

以@开头的路径代表的是要排除的目录和文件,其他的为要监控的文件

假如：我要递归监控　/tmp/inotify-test-dir　目录下的所有的所有的 .php 文件, 但是排除 /tmp/inotify-test-dir/cache 目录下的所有文件

我就可以这样写

/usr/bin/inotifywait -mr -e modify,create,move,delete –exclude ^.+\.[^php]$ –fromfile ‘/tmp/inotify-file-list’ –timefmt ‘%Y/%m/%d %H:%M’ –format ‘%T %w%f %e’

注意：

1、此种写法可以不用加“/tmp/inotify-test-dir”路径，fromfile中写有即可，经测试，加“/tmp/inotify-test-dir”路径也是可以正常运行

2、fromfile指向的文件，刚开始我是Notepad++创建，不知道是因为文件格式问题还是什么原因，导致在文件中写的规则出现莫名其妙的问题，后来通过touch命令新建一个文件，然后再在里面写入规则，测试后全部正常，害我白研究了一天时间。

附我在生产服务器上的自动同步脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#!/bin/sh
SRC=/data/wwwroot/web/ #代码发布服务器目录
DST=/data/wwwroot/web/ #目标服务器目录
IP="192.168.20.7"    #目标服务器IP，多个以空格隔开
USER=www
INOTIFY_EXCLUDE="--fromfile /data/conf/shell/inotify_exclude.list"
RSYNC_EXCLUDE="--include-from=/data/conf/shell/rsync_include.list --exclude-from=/data/conf/shell/rsync_exclude.list"
 
#su - $USER
inotifywait -mrq --exclude "(.swp|.inc|.svn|.rar|.tar.gz|.gz|.txt|.zip|.bak)" -e modify,delete,create,close_write,attrib $INOTIFY_EXCLUDE | while read D E F 
    do 
        for i in $IP
        do
            /usr/bin/rsync -e 'ssh -p 5000' -ahqzt $RSYNC_EXCLUDE --delete $SRC $USER@$i:$DST          
        done       
    done

inotify-tools相关文章：

CentOS使用inotify+rsync实时文件监控的同步备份

inotify文件监控工具inotify-tools使用方法介绍

直播平台大火，最赚钱却是CDN网宿、帝联、快网、蓝汛、ucloud、腾讯云

   在十年前，视频网站刚刚兴起时，也是这般光景，当时视频网站也有数十家，其中两大巨额的开支，一是带宽支出，二是版权内容的购买成本，这两大成本支出让大多数独立视频网站难以为继，直至消失。最终的结局是优酷、土豆这两家最大的视频网站完成合并，而后又被阿里巴巴全资收购，腾讯视频和爱奇艺风靡，网络视频行业最终成为了互联网巨头们的独角戏。

直播平台步视频网站后尘，钱被传统CDN赚走，最终被巨头收割？

如今，直播平台似乎又要重蹈覆辙。根据IT桔子的数据统计，国内的直播创业平台多达288家，有很多直播平台还融到千万甚至过亿的融资。比如2015年11月，斗鱼TV获腾讯、南山资本、红杉1亿美元B轮融资；B站获超2亿人民币D轮融资；2016年3月易直播获A轮6000万人民币融资等等，而更多的直播创业平台都还在处在A轮。

不过，目前为止，这些直播平台基本上都未盈利，一边需要支付高额的带宽成本，另一边只是高价对明星主播资源的签约争夺，这看起来似乎又是一场类似于网络视频行业的“烧钱大战”，而结局似乎早已写好，在弹药补充足的情况下，有很多直播创业很可能将要倒在黎明之前。尤其是，近一年以来，国内的融资形势不容乐观，这更需要直播创业小心谨慎的“花钱”。

而与直播创业平台们面临的危险境遇形成鲜明对比则是，传统CDN厂商却在这一波直播平台创业浪潮当中，利用自身垄断的带宽资源优势大赚特赚。根据网宿科技助理总裁孙孝思在接受界面新闻记者采访时就表示，目前行业里80%的直播平台是网宿科技的客户。而目前直播创业平台最大的开支来自于带宽成本，在30%到50%之间，这是一家直播创业平台的最大头的运营成本支出，而这些支出基本上都流入了传统CDN厂商手里。

实际上，这些带宽成本的开支完全可以省下来一大半。目前国内能够为直播平台提供CDN服务的并不是仅仅只有传统CDN厂商，此外还有以阿里云、腾讯云为首的云服务厂商，以及以星域CDN为代表的创新型CDN服务商，他们提供的服务成本都要远低于传统CDN厂商。以星域CDN为例，其在今年5月份曾发布专为直播平台提供服务的产品，极速版的价格仅为传统CDN厂商的十分之一，仅为0.5元/Mbps/天；而旗舰版产品的价格更低，仅为0.27元/Mbps/天，只相当于传统CDN厂商的5%。这样的价格可以让直播创业平台的运营成本直线下降，可以使得直播平台逃离开烧钱大战的魔咒，从而能够将钱花在其他增加自身竞争力的用处上。

直播创业平台选择传统CDN，缘于三大行业认知误区

不过，既然创新CDN厂商的产品如此便宜，为何这些直播平台还是愿意选择网宿科技这样的传统CDN厂商呢？这可能是由于直播创业平台对于创新型的CDN服务商的认知误区所造成的，主要有以下三个方面：

第一，直播创业平台对于创新CDN厂商的产品和技术能力没有认识。对于直播平台而言，用户的观看体验至关重要，尤其是需要保证视频的清晰流畅的播放不发生卡顿，因此他们在选择CDN厂商时更倾向于选择传统CDN厂商，认为他们网络节点多，可以最大程度的得到保障。实际上，现在整个CDN行业已经进入到技术革新的阶段，而不再是原来那个粗放发展到时代。很多创新型的CDN厂商通过技术手段突破了原来的行业限制，从而能够以更低的成本提供更好的服务。以星域CDN为例，其首创“无限节点”技术，已经拥有了在全国布建百万量级服务节点的能力，其中包括400余个骨干节点和百万量级末梢节点，并且通过推出智能硬件产品赚钱宝以共享经济的方式首次实现了下沉至家庭内拉取内容数据，从而开辟出了一条总量更庞大、分布更均匀，数据传输距离可近至1km的网络加速通道，此外星域还有其独特的调度技术，以及动态防御和弱网加速技术等，这就意味着，在服务质量方面，创新型CDN厂商丝毫不输传统CDN厂商。

第二，很多直播创业平台对于创新CDN厂商的服务质量没有信心，误认为传统CDN厂商的成立时间更久，技术可能更加成熟。实际上，事实可能恰恰相反，尽管传统CDN厂商运营时间很长，但由于在云服务商和创新型CDN厂商出现之前，面临的竞争压力很小，导致传统CDN厂商在产品方面缺乏更多的创新，更多的是通过在全国各地架设节点来提高加大自己的带宽，而在具体的产品服务方面，尤其是针对不同的垂直行业方面，并不会及时的推出专业化的解决方案。相较而言，新兴的CDN服务商以产品创新立足，创新的意愿更为强烈，以星域CDN为例，其在今年5月推出了针对直播行业的新产品，而且还具体到了泛娱乐直播、教育直播、事件直播、移动户外直播、/全景直播等几个方面，这使得不同的直播创业平台可以选择更加专业化的服务。显然，在成本更低的情况下，创新CDN厂商对于直播创业平台的服务可能更加到位。

第三，很多直播创业平台选择传统CDN厂商主要看重其行业知名度，迷信其之前服务过的知名企业案例，而不是选择能够与其共进退的合作伙伴。实际上，在服务的主动性方面，创新CDN厂商可能更好，而传统CDN厂商由于长期以来占据着资源的垄断优势，普遍缺乏服务意识，更多的将直播平台看作是客户关系，而并不是合作伙伴，这就意味着并不会真正从合作伙伴的角度去着手解决问题，而更多的看重其营业收入，因此在这些年以来，带宽价格从来没有主动降价过，直到像星域这样的创新CDN厂商出现之后，带宽价格才有了小幅降低，但是仍然比云服务商和创新CDN厂商的价格高出许多。而早在2015年6月，网心科技CEO陈磊在接受媒体采访时就指出，传统CDN厂商的服务心态有问题。相较而言，创新CDN厂商更愿意与直播创业平台一起发展，也因如此，在星域CDN直播产品的发布会上，获得了包括小米直播、大鹏VR、触手TV等多家直播创业平台的力挺。

总体而言，在直播创业大火的当下，创业公司随时面临倒闭危险，而传统CDN厂商却赚的盆满钵满，这是非常不合理的现象。如此下去，独立的直播创业平台可能最终也只能是投入到巨头的门下，而如果想要改变这种不利的局面，第一步或许可以从降低带宽成本开始，而创新的CDN服务商无疑是一个不错的选择。

全民大直播，流媒体选择Nginx是福还是祸？

CDN，视频云，已经“僧多粥少”

视频直播的持续升温，无意间也让带宽生意的争夺变得异常残酷。一时间，各种云计算、CDN、视频云提供商都在视频尤其是直播上投入重兵，揭竿而起的新生起义军们也正马不停蹄的赶往这方战场，各种号称可以在IaaS、PaaS、SaaS不同层面提供平台级、接口级以及产品级服务的花式作战口号此起彼伏，让人眼花缭乱，“僧多粥少”可能成为了当前支撑视频技术解决方案市场最恰当的提法。如此局面之下，视频云和CDN们，技术上到底是在竞争什么？作为视频平台和即将要进入视频领域的运营者，在技术平台的选型和搭建上又如何才能避免掉入大坑？

一个播放器的背后

谁都知道视频直播最重要的是流畅和高清，但这光鲜亮丽的背后是技术和成本的双高门槛，是诸多技术环节艰难积累和苦逼的人肉运维。主播发起一个简单的直播，主干流程就历经了采集、编码、推流、转码、分发、拉流、解码和播放这么多环节，还要求在数秒内完成，除此之外直播还有如录制、流控、安全、审核等等诸多复杂功能需求。

再如下图，仅一个屌丝观众从播放器看这个主播，就可能出现如此多不可知情形发生。这个屌丝的接入网络怎么样？使用的系统环境又怎么样？一个观众尚且如此，要保障百万千万级别流畅的观看，难度可想而知。

高清流畅到底靠的是什么

也许对于部分视频运营商和新进入者来说，直播推流端和播放器端依然觉得头大，但整体来说，除移动端外，PC端推流和播放技术已经比较成熟。难，主要难在传输和分发！正常情况下，只要推流端网络状况良好，传输和分发决定着直播是否能够流畅。

传输和分发，涉及到了视频最核心技术、巨额服务器和带宽成本以及国内网络环境极度错综复杂。也因为如此，视频平台基本上都将传输和分发环节交由专业的第三方视频云服务商或CDN服务商来完成。我们从网络传输的七层中拿出与视频传输分发相关的四层，如下图：

L2资源层：对视频云和CDN来说，资源的确存在差别，但在其可承受范围内，可以视为差别不大；

L4传输层：传输层可针对不同业务场景，比如针对超低延迟可以基于UDP做私有协议等。本文侧重阐述视频流畅的保障，不同应用场景的支持后续文章将专门介绍；

L3网络层：视频云和CDN公司在该层实现各运营商网间打通、多层Cache系统设计以及用户就近调度。该层的设计及优化对访问质量极为重要，随着CDN技术的日益成熟，虽然各家可能存在架构区别，但基本都能保障网络路由正常运转；

L7应用层：抛开细枝末节，视频流的主线还是输入、传输与输出，承担这些工作的就是视频平台最核心组件流媒体服务器，这就是视频直播分发最本质的特点，需要专门的流媒体服务器来分发，所有视频云和CDN，都需要在中心层和边缘层部署流媒体Server。

 

通过以上逐层分析可知，当资源和网络层面相差不大的情况下，流媒体Server的性能决定了视频流分发的效果和质量，故流媒体Server才是视频云和CDN技术竞争的至高点。



市面主要的流媒体服务器对比

目前市面上主流的流媒体服务器，有以Adobe FMS、Real Helix、Wowza为代表的第一代产品，它们的特点是单进程多线程。基于Linux2.7 epoll技术，出现了以多进程单线程为特点的第二代流媒体服务器，NginxRTMP、Crtmpd为其优秀的代表，另外还有基于JAVA的流媒体祖先Red5等。

观止云开源流媒体服务器SRS（Simple RTMP Server），凭借其功能强大、轻量易用、特别适合互动直播等诸多特点备受海内外视频从业者的青睐。蓝汛Chiancache曾用SRS承载其直播边缘分发业务，高升CDN基于SRS搭建其流媒体基础平台，其它还有赛维安讯、VeryCDN、VeryCloud、云博视等也将SRS应用到了自身的业务当中。各家视频云、云计算平台在源站的对接上也非常注重对SRS的支持。SRS作为纯国产的开源Server，在中国流媒体业界实属难能可贵。

观止云源站集群BMS（Bravo Media Server）是SRS的商业版，BMS在SRS基础上增强了11项大功能，新增了9个大功能：

增项的11项大功能：



新增的9项大功能：





流媒体Server的话说来也不短，上述列举的目前市面上主流流媒体服务器中，有名副其实的先烈RED5，有生不逢时的CRTMPD，都未大规模商用就不过于讨论了。其中应用最为广泛莫属nginx-rtmp，以下是nginx-rtmp几个盛行于世的重要因素：

  • 2012年CDN业务开始极增长，随之直播需求也多了起来，彼时业界都还没有一套公认的特别满意的流媒体服务器；

  • Nginx是HTTP领域绝对的霸主，大家（尤其是CDN运维）对Nginx熟悉程度很高，便于上手维护；

  • 基于Nginx，直播点播使用一套服务器，这也极具诱惑力，一套管理起来总比多套要简单；

  • CDN是靠运维的行当，运维的信心都是长年运出来的，Nginx在图文上那么优秀，Nginx RTMP也差不了。



nginx-rtmp确实生来就自带光环外，性能也的确是高，比Crtmpd还要高。然而，时过境迁，随着互动直播、移动直播的强势兴起的大直播时代，选择nginx-rtmp到底是福还是祸？

下面小编将从协议支持、体系架构、核心功能支持、配置运维、性能、服务器日志、数据这七大维度将目前市面主流的流媒体Server做一个横向对比，供视频从业者根据自身业务场景特性择优选用。



1
网络协议对比

BMS支持HDS、DASH、RTMPE/S/T等协议的分发，这将支持更多业务应用场景，FLASH P2P的支持能够显著降低网络带宽成本。



2
体系架构对比

架构方面，较之于nginx-rtmp的16万行代码，SRS仅用了6.5万行代码就实现了比nginx-rtmp 多了230%的功能，nginx-rtmp注释率为3%，而SRS是23.7%。由此可见SRS在体系架构上的轻，Simple。

观止云BMS在SRS的基础上新增了多进程支持、源站集群、动态配置、可追溯日志等方面能力。源站集群子系统打通了跨网跨地区的源站分布式部署难题；动态配置子系统从业务系统读取配置，依据更新机制动态更新配置，保证直播业务配置变化时依然不中断；端到端的可追溯日志及监控排错子系统将直播故障定位时间缩短到了分钟级别。



3
核心功能对比

核心功能方面，BMS支持了当期互动直播、移动直播急需的大规模直播流实时转码、大规模录制、秒级低延迟、HLS+、并发回源等其它所有流媒体系统不具备的功能。HLS+基于每个播放请求实现了流媒体的“虚拟连接 ”（UUID标识），在减小回源量、排错、防盗链、移动Web端低延迟等方面具有诸多优势。并发回源能够解决回源网络状况差、跨国传输丢包严重等方面能够显著提升回源质量。



4
配置运维对比

以下仅是流媒体众多配置之中几个常用例子，运维日常工作中，需要操作的配置数量更多。

（1）vhost配置

FMS

拷贝默认vhost目录：sudo cp -r conf/_defaultRoot_/_defaultVHost_ conf/_defaultRoot_/bravo.sina.com



nginx-rtmp

不支持



SRS/BMS

动态获取配置文件：vhost bravo.sina.com { }

结论：BMS动态获取配置最简单

（2）app配置

 FMS

拷贝默认app目录：cp applications/live applications/mylive -r



nginx-rtmp

修改配置文件，增加如下内容：application live {  live on; }



SRS/BMS

无需配置

结论：BMS无需配置，最简单 

（3）http配置

在输出为hls、http-flv等基于http协议的直播流时，需要配置http服务

FMS

配置FMS内置的Apache服务器文件：Apache2.2/conf/httpd.conf

再修改如下字段：

<Location /hds-live>

    HttpStreamingEnabled true

    HttpStreamingLiveEventPath “../applications” 

    HttpStreamingContentPath “../applications” 

    HttpStreamingF4MMaxAge 2

    HttpStreamingBootstrapMaxAge 2

    HttpStreamingFragMaxAge -1

    Options -Indexes FollowSymLinks

</Location



nginx-rtmp

nginx本身就是一个http服务器，

修改其配置文件：

conf/nginx.conf

设置端口和根目录：

http {

    include       mime.types;

    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

    server {

        listen       80;

        server_name  localhost;

        location /dash {

            root /tmp;

            add_header Cache-Control no-cache;

        }

    }

}



SRS/BMS

修改其配置文件：

conf/http.hls.conf

设置端口和根目录：

http_stream {

    enabled         on;

    listen          8080;

    dir             ./objs/nginx/html;

}

结论：nginx-rtmp需指定与app对应的ts文件存放目录，SRS/BMS会自动生成，更简单。

（4）推流、播放URL配置

RTMP直播时，各大服务器推流、播流URL均为：

rtmp://server_ip_or_dns/app/stream



用作HLS直播时，

FMS 

推流域名：

rtmp://fms-ip-or-dns/app/stream?adbe-live-event=liveevent

播流域名：

http://fms-ip-or-dns/hds-live/app/_definst_/liveevent/stream.f4m



nginx-rtmp

推流域名：

rtmp://server_ip_or_dns/app/stream

播流域名：

http://server_ip_or_dns/app/stream.m3u8



SRS/BMS

同nginx-rtmp

结论：nginx-rtmp、SRS/BMS均简单，FMS较复杂。



5
性能

先说结论：

SRS单进程能支持9000并发，nginx-rtmp单进程最多支持3000个，单进程的性能SRS是nginx-rtmp的三倍。单进程性能SRS > nginx-rtmp > crtmpd > wowza > fms > RED5

 

再例举SRS性能如此高的几个原因：

1. st-load，这个是SRS能做到高性能的最重要的原因，一个st-load可以模拟2000+的客户端，如果没有st-load，如何知道系统的性能瓶颈在哪里？总不能打开3000个flash页面播放rtmp流吧？开启3000个ffmpeg来抓流？高性能不是想象和猜测出来的，而是反复测试、调试和改进出来的。

2. gperf/gprof性能，编译SRS时，就可以打开gcp或者gprof的性能分析选项，非常方便的拿到数据。缩短了改进和优化开发周期。

3. 引用计数的msgs避免内存拷贝。

4. 使用writev发送chunked包，避免消息到chunked包的内存拷贝。

5. mw(merged-write)技术，即一次发送多个消息。

6. 减少timeout recv，每个连接都是一个st-thread在服务。

7. fast buffer和cache。

8. vector还是list？vector！vector比list高10%性能。



6
服务器日志

日志是定位故障的唯一途径，定位故障才能快速排错。可以这么说，对于直播，10分钟的排错，谁都会觉得长。然而，当前的视频云或CDN，谁又能做到10分钟呢？

来看看日志吧。

FMS的日志是这样的，恕我愚钝，你能看得出什么信息么？

2015-03-24 12:23:58 3409 (s)2641173 Accepted a connection from IP:192.168.1.141, referrer:http://www.ossrs.net/players/srs_player/release/srs_player.swf?_version=1.23,pageurl: http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935-

702111234525315439     3130         3448         normal      livestream         –        –         rtmp://192.168.1.185:1935/live/livestream     rtmp://192.168.1.185:1935/live/livestream        –        flv     –        –        0       –        0       0         –        –    http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935    -1      -1.000000         

crtmpd的日志详细，但我又愚钝，若是上千人在线，你又能看出什么有用的东西么？

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/netio/epoll/iohandlermanager.cpp:120Handlers count changed: 15->16 IOHT_TCP_CARRIER

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/netio/epoll/tcpacceptor.cpp:185Client connected: 192.168.1.141:54823 -> 192.168.1.173:1935

/home/winlin/tools/crtmpserver.20130514.794/sources/applications/appselector/src/rtmpap

nginx支持中文文件名方法

nginx支持中文文件名方法载过来与大家一起分享！该方法还没有亲自测试，所以不太确定是否真有用！

方法一（已经测试OK）：

搞了大半天nginx下无法访问中文文件名的问题，现在看来是secureCRT的问题？
看来还是字符集的问题了。
看来nginx不需要象apache那样要单独加载支持中文模块。

服务器端字符集如下
[root@test]# locale
LANG=en_US.UTF-8
LC_CTYPE=”en_US.UTF-8″
LC_NUMERIC=”en_US.UTF-8″
LC_TIME=”en_US.UTF-8″
LC_COLLATE=”en_US.UTF-8″
LC_MONETARY=”en_US.UTF-8″
LC_MESSAGES=”en_US.UTF-8″
LC_PAPER=”en_US.UTF-8″
LC_NAME=”en_US.UTF-8″
LC_ADDRESS=”en_US.UTF-8″
LC_TELEPHONE=”en_US.UTF-8″
LC_MEASUREMENT=”en_US.UTF-8″
LC_IDENTIFICATION=”en_US.UTF-8″
LC_ALL=

在nginx.conf文件里配置的字符集也是utf-8
server {
listen 80;
server_http://www.dnsdizhi.com/zixun/aggregation/11696.html”>name test.cn;
root /data;
index index.html index.jsp;
charset utf-8;

客户端用的是secureCRT，字符集用的是defalut，用rz上传后在服务器上用ls显示乱码，用ie怎么浏览都不能正常看到。
找朋友测试了一下他那边的nginx，中文显示居然一切正常，后来他告诉我他的secrueCRT用的字符集是utf-8，我改用uft-8后再用rz上传文件，在ie下中文可以正常显示了。

方法二：

一：确定你的系统是UTF编码

[root@Tserver ~]# env|grep LANG
LANG=en_US.UTF-8

二：NGINX配置文件里设置为

server
{
   listen       80;
   server_name  .dnsdizhi.com ;
   index index.html index.htm index.php;
   root  /usr/local/nginx/html/inginx.com;
   charset utf-8;
   }

三：如果使用putty

windows  –> translation –>UTF-8

mkdir NGINX中文技术站
echo NGINX中文技术站 > 中国.html

四，如果是用securecrt 上传文件，请选择 回话–>外观–UTF-8

五，如果出现文件名乱码显示

执行
for f in `ls *.html` ; do mv $f `ls $f|iconv -f GBK -t UTF-8`; done

另一位朋友的解决方案是：

我现在用的方法是
在后端个别目录用APACHE代理了 。。
APACHE支持中文码。。

location /~doc/ {
   proxy_pass http://127.0.0.1:81/;#apache server
}

以上供大家参考！

curl实践HTTP206状态:部分内容和范围请求

HTTP 2xx范围内的状态码表明了:”客户端发送的请求已经被服务器接受并且被成功处理了”.HTTP/1.1 200 OK是HTTP请求成功后的标准响应,当你在浏览器中打开www.cyberciti.biz后,你通常会得到一个200状态码.HTTP/1.1 206状态码表示的是:”客户端通过发送范围请求头Range抓取到了资源的部分数据”.这种请求通常用来:

  1. 学习http头和状态.
  2. 解决网路问题.
  3. 解决大文件下载问题.
  4. 解决CDN和原始HTTP服务器问题.
  5. 使用工具例如lftp,wget,telnet测试断电续传.
  6. 测试将一个大文件分割成多个部分同时下载.

查明远程服务器是否支持HTTP 206

首先你需要知道文件大小以及远程服务器是否支持HTTP 206请求.使用curl命令可以查看任意资源的HTTP头,使用下面的curl命令可以发送一个HEAD请求: 

$ curl -I http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png

输出结果为: 

HTTP/1.0 200 OK
Content-Type: image/png
Content-Length: 36907
Connection: keep-alive
Server: nginx
Date: Wed, 07 Nov 2012 00:44:47 GMT
X-Whom: l3-com-cyber
Cache-Control: public, max-age=432000000
Expires: Fri, 17 Jul 2026 00:44:46 GMT
Accept-Ranges: bytes
ETag: "278099835"
Last-Modified: Mon, 05 Nov 2012 23:06:34 GMT
Age: 298127

其中有两个我们比较关注的请求头:

Accept-Ranges: bytes – 该响应头表明服务器支持Range请求,以及服务器所支持的单位是字节(这也是唯一可用的单位).我们还能知道:服务器支持断点续传,以及支持同时下载文件的多个部分,也就是说下载工具可以利用范围请求加速下载该文件.Accept-Ranges: none 响应头表示服务器不支持范围请求.

Content-Length: 36907 –  Content-Length响应头表明了响应实体的大小,也就是真实的图片文件的大小是36907字节 (37K).

如何发送一个range请求头?

现在,你知道了该图片所在的服务器支持范围请求,你需要发送一个包含Range请求头的GET请求: 

Range: bytes=0-1024

完整的请求数据应该是这样的.首先第一行是: 

GET /images/misc/static/2012/11/ifdata-welcome-0.png HTTP/1.1

然后需要发送Host请求头来指定请求资源所在的主机和端口号: 

Host: s0.cyberciti.org

最后是要发送的Range请求头,指定了你想要的字节范围: 

Range: bytes=0-1024

使用telnet命令

telnet命令允许你使用Telnet协议来与远程主机(服务器)进行通信.所有的类Unix操作系统以及MS-Windows都包含有Telnet客户端.启动Telnet客户端并进入Telnet提示符,要执行命令: 

telnet your-server-name-here www
telnet your-server-name-here 80

想要通过端口号80连接远程服务器s0.cyberciti.org,输入: 

telnet s0.cyberciti.org 80

输出结果为: 

Trying 54.240.168.194...
Connected to d2m4hyssawyie7.cloudfront.net.
Escape character is '^]'.

在本例中,使用范围请求(0-1024 字节)来请求s0.cyberciti.org上的/images/misc/static/2012/11/ifdata-welcome-0.png文件,输入: 

GET /images/misc/static/2012/11/ifdata-welcome-0.png HTTP/1.1
Host: s0.cyberciti.org
Range: bytes=0-1024

输出结果为:

Fig.01: Telnet command Range-requests bytes header example (HTTP 206)

上图中,

  1. 区域1 – GET请求以及请求头.
  2. 区域2 – 206状态以及响应头.
  3. 区域3 – 二进制数据.

使用curl命令

curl命令是一个和远程服务器交换数据的工具.它支持HTTP/FTPSFTP/FILE协议上的范围请求,在下例中,使用两段范围来请求远程文件ifdata-welcome-0.png,然后使用cat命令将两段数据合并成完整文件: 

curl  --header "Range: bytes=0-20000" http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png -o part1
curl  --header "Range: bytes=20001-36907" http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png -o part2 cat part1 part2 >> test1.png
gnome-open test1.png

还可以使用-r选项(可以同时添加-v选项查看请求头和响应头): 

curl  -r 0-20000 http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png -o part1
curl  -r 20001-36907 http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png -o part2 cat part1 part2 >> test2.png
gnome-open test2.png

如何开启Accept-Ranges响应头?

大部分web服务器都原生支持字节范围请求. Apache 2.x用户可以在httpd.conf中尝试mod_headers: 

Header set Accept-Ranges bytes

Lighttpd用户尝试在lighttpd.conf中进行下面的配置: 

## enabled for all file types ##
server.range-requests = "enable" ## But, disable it for pdf files ##
$HTTP["url"] =~ "\.pdf$" { server.range-requests = "disable" }