组播和单播的知识点

一、 关于组播、单播和流媒体：

什么是组播；这个问题实际上之前我们在网站上就有相关的文章来专门介绍组播。简单概述就是基于UDP协议通过I一个组播IP传输多个直播源的数据打包和传输方式称之为组播。组播最大的优势在有限得带宽下传输多套高清直播流。这里我们讲一下目前组播最大的应用领域在广电数字电视（DVB-C），以及卫星电视传输（DVB-S/S2包括地面波DTMB实际上是DVB-T），这里可能有的人会觉得概念很模糊，实际上你可以这样理解把一个组播组理解为一个频点，我们都知道不管是卫星或者广电它的一个频点中可以包含有多个频道。

组播传输原理图：

通过上图，我们假设组播传输通道为6兆，那么通过组播数据打包方式，可以在6兆的组播通道中传输4套1080P的高清直播或者15套720P的标清直播，多个客户端观看这一通道中的频道，只需要占用额定的6兆带宽。具象化一点来说就是在一个标准的组播环境中客户端是被动接受的，是否播放该频道取决于客户端对频点的调制和对频道组播流的解包。这个就是真正意义上的组播，或者更准确的说法应该叫UDP多播。

但这种组播方式（实际上应该叫做多播），也有一个致命的缺点，那就是他需要专用的调试芯片去处理打包后的组播流，这并不是软件可以模拟的，而Android是不支持这种调制芯片的，当然也不可能支持真正意义上的组播，所以我们看到的各种包括卫星机顶盒或者广电数字电视机顶盒，他们的基础系统是嵌入式的Linux而不是Android。

IPTV业界所谓的组播是什么？

实际上这是客户最常问的一个问题，每次都要费口舌去解释，所以在这里写下来，希望图文并茂的说法能让更多人理解。已经购买过所谓的组播IPTV系统的朋友，不管你是购买的哪个厂家的产品，你可以去后台观察一下，他们所谓的组播地址一定是以一个组播IP+一个组播端口构成的；

例子：udp://226.0.0.1:1001

当你看到你的iptv系统后台频道地址中是这样的一个组播地址那么就可以确定“你购买的IPTV系统绝对不是真正意义上的组播”。简单来说这种方式应该叫做基于UDP传输的单播流，要注意这种单播流是不需要额外的芯片去解包处理的，而且任何播放器都可以支持例如windows下的vlc，以及任意一款支持H264编码或者MPEG2编码的播放器都可以支持。

UDP单播原理图：

从上图中我们可以看到每个客户端在与传输设备之间建立连接的时候都是一个独立6-8兆的带宽占用，而不是真正意义上组播多个设备只占用一个固定带宽的方式。所以有的客户跟我说为什么你们不做组播，组播占用带宽小待机量大云云，每次听到这种说法我都嗤之以鼻，背地里觉得特别可笑，当然这里没有任何嘲讽的意思，我只是在嘲笑那些给客户灌输这种错误思想的厂商有多无耻。

下面我们要说一说什么是单播：

单播传输不管是基于TCP（例如RTMP/RTP/RTSP）或者UDP（刚说完的上一章节所谓的UDP单播），都是一种稳定高效且无延迟（无延迟说法并不准确，但实际应用中单播的延迟基本可以忽略不计“大约1秒以内”）的直播传输技术，这种技术最多被应用于监控，没错就是监控系统中，做过监控特别是数字机的人都知道监控可以通过RTSP协议来播放，RTSP是一种基于MPEG2标准编码进行TCP传输的格式（我这么说是为了大多人可以理解，说的深一点我觉得很多人不会继续看下去而且篇幅会很长）。后来又有了RTMP（支持H264了），RTP等多种模式，最初RTMP也是被应用于基于Internet传输直播流的协议，实际上现在大多数的各类直播平台，包括你的QQ视频，微信视频都是RTMP协议，我前面说了这种协议是基本无延迟的，你总不想微信视频你已经说完了半天对方还没听到吧。

那么单播传输的缺点是什么呢:

单播传输对传输层的服务器要求压力非常高，因为是实时读取，实时传输的，不管是带宽占用还是服务器的编码压力都非常大（为啥你前置两千万像素的手机视频聊天依然跟200万没区别，因为带宽流量亚历山大，所以视频质量被压缩到非常低的一个层次，视频编码优化的话题不多聊）。直播平台或者微信QQ等往往需要部署大规模的服务器矩阵和边缘服务器（什么是边缘服务器，你只需要了解下这个名词就可以了）来进行优化传输，所以这种方式在IPTV领域依然不适用。

那为啥有的厂商做组播（UDP单播）？这个我要说，你把一个手机从左手换到右手不费力，让你去种果树你试试。说的直白一点就是一个转发过程，转发程序本身很简单，左手传到右手，但我也说了外网转发到内网后，你内网依然需要用大量的带宽去堆才能让更多客户端观看。那么所谓UDP单播节省带宽一说也就不攻自破了。

总结：

1：Android机顶盒或者Android设备不支持真正意义上的组播。

2：IPTV业内所谓的组播=基于UDP协议传输的单播。

3：所谓的IPTV组播节省带宽，增加带计量=谎言。

什么是HLS流媒体：

我把标题放大了一号（因为我重点要说它）。HLS（http live streaming）是Apple（没错就说那个最近发布刘海全面屏、电池又鼓包的苹果公司）公司发布的一种动态码率自适应技术，这个技术牛，牛到什么程度呢，TamronOS也在用呵呵呵，开玩笑的，在TamronOS之前你叫得出来的视频网站都在用HLS技术（优酷、乐视、爱奇艺、腾讯视频、搜狐视频等等）。HLS可以应用于点播也可以用于直播流的传输，他最大的缺点是（没错是缺点），存在传输延迟，根据设置一般延迟在10-20秒之间。现在一定有人在问为什么，都说了是图文并茂，所以看图吧。

HLS原理图：

画风不要歪，本文还算是一个正经的教程文章，目的在于传播知识（我tmd都开始不信了），其实我要表述的中心思想是“动态视频切片技术”举个栗子：例如一个1Gb的视频文件，我放到网站上然后给你一个播放地址：http://www.tamronos.com/abcd.mp4你把这个地址复制到你的播放器里去播放，此时你观察你的网络占用率就会发现，你的电脑一直在不断的吃你的流量（可能会有很小的波动）。而且此时如果我观察我网站的流量也会被你吃走，当有100个人同时去播放这个连接那么基本上你也就无法访问TamronOS官网了（每次发布新的升级包时有大把客户一起下载，网站分分钟流量爆表）。其实原因很简单，本地播放器在播放一个网络连接时会尽可能快的把目标文件缓存到本地，以此来优化你的观看体验，当然播放器肯定不会去操心吃爆你带宽后你还能不能上微信撩妹的事情。而HLS技术就是为了解决这些问题而生的，同样以这个1Gb的mp4文件为例，通过HLS技术把他切分为1000个TS切片，每个切片文件1兆大，同时生成一个以.m3u8为扩展名的播放索引文件。例如：http://www.tamronos.com/abcd.m3u8当你的播放器请求这个地址时，默认只加载三个小的ts文件，这样加载非常短的时间就可以开始播放，当播放到第三个文件时继续加载后面三个新的文件，依次循环。这时候你再去观察你的网卡流量就不难发现，他的带宽占用呈现为一种锯齿波，加载时占用，加载完毕不占用。我常说的一个栗子给你一条上下行对等100兆的专线，每个用户开10兆带宽你能带多少用户，有没有人回答是10个，显然所有人都不会这么说，这里面的道理很多人可能说不出来，但意思大家都明白，就是这个所谓的锯齿波原理，因为不可能所有人都去大量下载，肯定有人人看片、有的人看看网页、有的人可能…你懂的。

那么当HLS应用于直播流时为什么会产生延迟？其实这个我相信看到这里的人已经差不多懂了，点播的HLS应用是去切分一个已有的视频文件，而直播是需要不断的读取最新的视频流，所以HLS协议需要先读取一段时间生成TS切片然后在分发给客户端播放，那么这个预先读取的时间就是HLS直播延迟的时间。

总结：

1：HLS技术的缺点有10-20秒的直播延迟。

2：最大优势在于通过小文件切片技术优化传输和播放体验。

3：占用带宽小，不对传输网络造成压力。

4：各大视频网站都在用的技术（包括所有的安卓直播应用都是HLS）

二、 TamronOS的IPTV为什么不做组播

这个问题，其实我已经回答过无数次，所谓的组播（UDP单播）其实没有什么技术门槛，它就是一个简单的转发程序，说的更直白一点就是个静态路由（比静态路由稍微有点点复杂）。相对于HLS不管是在开发上还是代码量上做这种所谓的组播都会少很多，当然这不是TamronOS选择不做组播的理由。真正的理由如下：

1：所谓的组播（我坚持不懈的备注这个叫UDP单播），在实际部署中需要用双口光猫和支持UDP单播的机顶盒，会给后期运营带来更多成本。

2：UDP协议不能跟TCP协议并行，部署UDP协议的IPTV后无法部署基于TCP的点播服务（有一种方法可以部署就是在机顶盒的无线网卡和有线网卡之间切换来切换去，非常麻烦）。

3：因为到客户端需要一个持续稳定的带宽，所以不能通过无线传输，这会给客户在实际安装中导致必须网线直连光猫才可以（前提是客户愿意你在人家家里拉一条又长又丑的网线到盒子哪儿）。

4：对机顶盒有严格要求，如果终端客户已经购买了盒子或者家里有智能电视不能通过安装APP来支持，运营商要付出盒子的成本，客户还未必买单。

5：一旦出现光猫环路（比如把上网口和电视口给你网线直连这种情况有人遇到过了），会导致UDP组播风暴直接让整个网络瘫痪。

6：增加传输设备的负担，例如OLT交换机光猫在一个持续高占比环境中工作损坏速度更快。

7：带宽占用率高（没错是高）一个千兆口只能带400-600用户。一个万兆口也不会超过3000，TamronOS的HLS一个千兆口就可以带1500用户同时观看，一个万兆口能带8000用户同时看。

8：…

9：….

Xx：我不做假组播来忽悠人（感觉这条好牛13）

TamronOS的IPTV系统还有什么优势：

前面我们已经讲了组播、单播和流媒体三种技术的优势和缺点，我的结论就是HLS技术在IPTV领域具有占用带宽小、部署方便灵活、用户体验度好、对客户端设备要求低等诸多优点（不管你信不信，我是信了）。但这里还有一个更加关键的技术，动态内存切片技术。我们都知道硬盘是有最大读写队列数和最大读写速率这两个关键参数的。即使你HLS在牛13你也不可避免的因为硬盘读写速度问题导致多用户访问速度变慢（因为硬盘慢了），即使你使用固态硬盘，固态硬盘依然存在这个问题，而且坏的更快。当出现多频道多用户大量读取的场景，不管是磁盘阵列还是SSD都要靠边站。那么内存呢？

TamronOS通过技术手段将切片文件直接以序列方式保存在内存中，内存是没有读写速率瓶颈问题的（即使有也可以忽略不计了）。当多频道、大用户量读写时动态内存切片技术的优势就非常明显了。总结： HLS切片技术+内存序列化存储=高性能高待机量的IPTV系统。当然我们还有更多优化，例如极速转发模式等等，这些可以到www.tamronos.com去看，这里不再熬述了， 文章之初我就说过，这不是一个单纯的广告文，即使你不选择TamronOS看看也是很有益处的。

三、 关于主动式缓存（点播）：

可能很多人对主动式缓存的概念还很模糊，其实这不是一个特别新鲜的技术。这套东西最初源自CDN加速和边缘服务器加速所提出的概念。你可以看做是一个类似于CDN的分发节点，三大运营商的缓存或多或少都用了到主动式缓存技术。

主动式缓存原理图：

好吧，其实看这个图还是很模糊的，通过文字描述或许会更清晰一些，我们都只到常见的缓存是通过镜像NAT数据或者通过路由主动牵引的方式（Pa_ixcache就是牵引模式）获取到客户端的请求，然后缓存完毕后再通过302重定向给其他请求该资源的客户（这里面太复杂的东西就不说了）。这种方式适用于大多数小型网络环境，部署灵活，程序自身不需要去分析源地址而是通过监听上下保存来获取源地址。但缺点就是需要有人去点。那么所谓的主动式缓存实际上就是在缓存系统中省略了等待用户去点击的这个过程。主动式缓存在处理数据时会首先根据设置的源服务器地址进行分析，确定哪些资源是比较热门的（这是我们的逻辑，实际上这里可以深入剖析）资源，通过算法分析把源文件copy到本地缓存服务器，当客户请求该地址时自动命中。逻辑上就是这么简单。当然有人会问这样做TamronOS的点播会不会内容不够多，或者命中失败等问题。有这个担心是对的，但同样这个担心也是多余的。就内容来说我们肯定有些不能公开写在这里的算法（XD主要是怕友商们抄袭），我们通过一个相对来说较为复杂的逻辑去筛选那些热度高需要缓存的内容并缓存到本地，然乎在本地构建一个类似于聚合视频这样的播放地址库，当然这个地址肯定是原始地址，当某地址的数据缓存完毕后就开放给客户端观看，如果没有缓存完毕或者缓存中的则不在客户端进行展示。因为我们只需要命中给自己的客户端APK，自然在保证命中率上就有很多办法（普通的缓存因为要命中给各种软件或者浏览器或者请求之类的所以命中率是难以保证的，这个除了考验码农的水平外更多的还要考验性能问题）。

看图：

总结：

1：主动式缓存，采用类似模拟点击等多种方法获取到视频地址然后生成聚合数据库。

2：根据聚合数据库内容，自动缓存源文件到本地。

3：完成缓存的内容构建一个客户端可筛选的播放列表。

4：客户从播放列表中选择某个视频观看，无差别命中缓存，实现等同于本地播放的效果。

最大优势：

1：内容方面相对于那些影视采集系统更多更全面，因为所有存储内容都是缓存文件，所以不存在版权纠纷。

2：缓存视频内容合法合规符合国内对视频内容的审核。

3：无差别定向命中，百分百的命中率。

4：客户体验与本地采集视频在入库播放无差异。

四、 关于音视频编码问题：

视频编码：

视频编码就是针对直播流在传输过程中用什么样的格式进行编码（xx.AVI xx.mp4等等），目前在IPTV领域的两大视频编码格式无非就是MPEG2TS和H264（也有4K直播源实际上就是H265）。目前来说客户通过卫星码流机或者广电的卡机获取的节目源大多采用MPEG2TS格式，采集运营商的源或者互联网源多为H264格式。这两种编码格式的详细技术我在这里不做解答，但总结两点让大家一看即知。

MPEG2TS：卫星和广电前端输出大多都是这个格式，视频码流比较大，清晰度低最高720P，客户端播放时需要占用大量的硬件资源，不支持web播放。

H264：一种最常见最多用的数字编码格式，视频码流小，清晰度高最大1080P，跨平台支持好，支持web播放。对客户端播放器的硬件资源占用低。

音频编码：

非常多，常用的几十种，但对于IPTV行业来说主要有三种，MP2（一般这种音频编码的流，其视频编码也是MPEG2TS），AAC，FAAC（这两种都是新标准数字音频编码标准）。详解；

MP2：音频压缩比低，对客户端播放要求压力高，占用带宽大，失真率较低。

AAC：中等压缩比，高品质音质还原，对客户端播放要求压力较高，几部不占用服务器硬件资源。

FAAC：高压缩比，标准频道音质，对客户端播放要求压力极低，但需要占用大量服务器硬件资源。

总结：我只说IPTV行业所涉及的问题，用大白话来说，使用MP2音频编码时，对客户端的机顶盒解码能力是有一定要求的，太烂的盒子播放会大量消耗盒子CPU资源。AAC编码会对服务器构成压力，但音质最好，大多数AAC编码都是用来做高品质CD。FAAC拥有极高的压缩比和极低的服务器编码压力，客户端播放时几乎不会消耗额外的硬件资源。

盒子比较好——-选择AAC或者直接COPY（服务器压力小盒子压力大）

盒子比较烂——-选择FAAC（服务器压力大，盒子压力小）

五、 关于节目源和前端设备的问题：

这也算是一个问的比较多的问题，上IPTV系统要用什么设备，怎么部署等，随后就是让我给发个方案，每次遇到这种问题都感觉到万般无奈，因为实在没什么可说的，更别提所谓的方案了。换个说法就是我提供一个我认为是方案的东西给你，我真担心很多人看不懂。好了先不说方案的问题，我们先来谈谈节目源和前端设备。实际上前端设备这个词也不是特准确的，我一直很反感一些厂商拿编码器之类的东西给个前端设备的名称好让自己的产品感觉上高大上，编码器你就是编码器别扯些所谓高大上的名词给自己脸上贴金。

关于节目源的分类：

1、 运营商IPTV源：

这里指的是电信联通的IPTV业务开通后所拥有的源。这种源也分为2种，一种是UDP单播源（前面介绍过这种源了），另一种则是流媒体源（HLS）。区分方法也很简单。

双口猫、机顶盒直接接光猫第二口的基本就是UDP单播源。

单口猫、机顶盒可以接路由器的基本就是流媒体源。

关于UDP单播源一条线路能输出几个频道的问题实在不好回答，以前我也讲过，这个取决于组播带宽和组播组最大接入数（为什么我这里要用组播这个词，UDP就叫组播，但这里的组播和我前面说的多播完全不是一回事），例如限制组播带宽为50兆，不限制组播组最大接入数，那么一般一个标清频道6兆左右，高清12兆左右，50兆能出多少频道无非就是个小学级别的乘除法而已。同样如果不限制组播带宽，限制组播组最大接入数为10，那么不管是高清或者标清累计最大出10个频道。依我们的经验来说，国内输出最少的也是4个，最多的可以输出30几套，所以这个有点撞大运的意思，好在我们有收集了一份列表，你可先问问我们。至于流媒体格式的，只要你能抓到地址（注意这里的地址指的是节目源地址），而且这个流媒体地址可以通过VLC播放器正常观看到频道，那基本上只要带宽够出多少都行，例如100兆的带宽可以出30-40套（前面我讲过HLS省带宽了对吧，在这里体现的很淋漓呵呵）。采用这种节目源不需要其他设备，只要有个vlan交换机就可以。

2、 网络源：

网络源获取的方法有很多，比如各大直播论坛上都有人定期发布一些网络源，高清和标清都有，大多数为HLS格式（以.m3u8结尾的都是HLS）。也有少部分RTP/RTMP格式（源提供者都不差带宽）。这类源只要你带宽足够的话也是可以用的，前提是你需要找那些长期稳定的源来用。网络源同样不需要其他设备只要系统可以上网就可以采集。

3、 卫星源：

是我特别不喜欢的一种源；为什么？卫星源基本都是免费频道，所谓免费频道肯定都是标清的（有高清的，138KU、亚五、亚七都有些免费高清频道但决计不多），一些重要的频道没有（例如CCTV1 3 5 6 8）。这类源需要你装几口大锅（特别是你需要频道比较全的话），本地广电让不让你装的问题先不说了，卫星天线极其容易受到天气因素影响，比如大风吹没了，大雪压塌了，打雷…是吧。如果当地广电时不时的再给你干扰干扰呵呵。当然最主要的原因是这里源都是MPEG2TS编码格式，这类格式有些智能电视不支持（国产山寨货），另外MPEG2TS自身的码流比较大，同样是HLS输出的情况下要比H264编码的频道大2倍码率。另外对机顶盒的播放性能也有一定要求（太烂的容易音视频不同步，不过可以放心的是TamronOS的客户端APK可以完美解决这个问题呵呵呵打广告）。再就是他需要购买卫星码流机或者卫星解码卡，一般购买这些设备+天线等投入需要额外多出1万多软妹币的投入。

4、 广电源：

同样不是特别推荐，但用来解决五六套本地频道还是可以的。用广电源，需要购买广电DVB-C的大卡机+广电的智能卡和卡套，一般一台设备算下来要4K软妹币+智能卡的年费（一张卡能出四五个频道左右），除了不会被风雪雷电劈外其他方面跟卫星源没有区别，同样是MPEG2TS（高清频道是H264）。

5、 HDMI/AV源：

这个不难理解，无非就是其他机顶盒输出的HDMI信号或者AV模拟信号通过高清编码器或者标清编码器转换为IP数据流在输出给IPTV服务器。一台10路高清编码器大约9K软妹币，一台8路标清也要2K左右，算上机顶盒的投入等，我觉得我宁愿选择弄点便宜带宽拉网络源也不会用这个。当然有些特殊情况必须要用的话..这个设备开发出来自然有他存在的价值不是么。

总结：

1：运营商IPTV源/网络源 成本最低，不需要所谓的前端设备（最多需要个交换机）。

2：卫星源，码流机相对于DVB-C大卡机便宜一点，但是频道不全成本较高，会受天气影响。

3：广电源，频道全，同样成本最贵。

4：编码器源，要多少频道都能堆出来只要你不心疼钱，相对于前三个没有最贵只有更贵。

建议：这个一定要看，在实际部署过程中大多人会优先考虑运营商IPTV源，毕竟这个源是最稳定成本也最低的，但无奈的是有些地方可能一条线路只能出3-5个频道（UDP），那么这时候你可考虑复合源方案，假设你每条线路能出4个频道，那么你可申请5条线路，把一些看的多且重要的频道都从这里输出，这样就有20个，然后在通过5条线路的上网口采集一部分网络源（100兆的家庭宽带线路怎么也能搞30套直播），如果本地频道可以考虑弄台标清编码器（我一直认为各地区的本地频道给人的感受都是罗玉凤）。这种复合源采集的方式做100套节目还是很轻松的。

六、 部署方案：

现在不得不来说一下IPTV部署方案了，废话不多说先上图；

看了上面这些方案图有多少兄弟能看明白，这个问题我不会想的很乐观（如果你们都看懂了，就当我没说过这句话），所以这里还是文字说明一下。首先不要去管这些乱七八糟的架构和连接线，我们先讲一下IPTV系统在几种不同网络架构中的位置问题。

1：宽带运营商网络环境：

单口光猫FTTH/FTTB+LAN（就是交换机+网线）；这种网络模式下，一般IPTV的输出口作为核心路由的WAN口使用，也就是说客户端在访问IPTV的时候是通过路由做NAT访问的，对于Panabit来说可以增加两条IP策略路由实现，对于其他的路由（碧海威、爱快、海蜘蛛、WayOS、神行者之类）也有类似的操作（跟缓存的命中口部署方式基本一样）。可以通过策略路由对IPTV线路和上网口线路独立限速，这样做的最大优势就是机顶盒可以通过wifi连接，部署简单安装方便、对原有网络架构几乎没有改动。

多口光猫部署；总有些做事情高大上的兄弟给所有客户都配了多口猫，当然这样做可以让业务在物理层分开，这时候IPTV的输出口可以进OLT的独立上行口，在OLT中配置光猫端口绑定不同的vlan来实现，例如1号口PPPOE上网口，2号口DHCP 电视口（DHCP server需要自己做，但如果你买了TamronOS，我们有这个功能的不需要你单独装DHCP Server），优点=没有什么有点（因为这种做法多是那帮搞UDP单播的人想出来的），缺点就是机顶盒不能直接接wifi了（毕竟谁也不会傻乎乎的在家里装2个无线路由器吧）

单口猫部署能否配置只开IPTV不开上网？答案是可以的，配置方法有很多，例如创建一个独立套餐（配合地址池），让该地址池只允许访问IPTV输出口的线路，或者在OLT上划一个独立vlan，让对应光猫绑定到对应vlan上输出一个内网的DHCP地址池。

2：酒店、学校等环境的部署：

先分析上述这些场景，实际上大部分酒店学校等都采用DHCP模式（我知道很多学校在用PPPOE，所以不要纠正我只是说栗子），当采用DHCP部署时，IPTV输出口可以接顶层交换上（vlan配置要搞清楚）给一个相同网关的固定IP即可。下面是栗子（别纠正错别字“栗子”我的幽默友商不懂）

DHCP地址池：10.0.0.5-10.0.254.254

DHCP网关：10.0.0.1 IPTV输出口IP 10.0.0.2

总结：IPTV系统在部署时，不管是PPPOE网络还是DHCP网络，万变不离其宗的原则就是客户端要能访问到IPTV系统的输出口。只要符合这个规则即可。至于直播和点播服务器之间的连接等等乱七八糟的问题，很简单看教程或者打电话问我们。

七、 为什么要用两台服务器，为什么不能用一台：

如果能用一台，我干嘛要设计为用两台呢？我在此强调一下，我不是傻X。能用一台搞定的事情我绝对不会用两台去干。为什么？其实还是考虑到性能、带机量的问题。点播缓存系统在下载和输出的时候也是需要大量读写硬盘的，硬盘瓶颈问题就不再复述，我说一个很有意思的案例吧。有个客户买了一套PA的缓存，最大输出授权为600兆，服务器内存32G、硬盘ST 2T监控盘*12 高峰期在线用户数为4K左右，通过PA观察缓存输出流量基本峰值就在200兆左右，他一直认为是PA的缓存做的不够好，实际上这个是因为硬盘读写问题，后来我建议他改成RAID5阵列，虽然牺牲了部分硬盘容量不过输出速率确提高到300兆左右。我们得到的验证数据是，当硬盘处于读写不分离且多用户多请求的状态下时读写瓶颈问题很头疼（为啥不用固态？你弄20T固态试试，有钱烧的吧）。

正式因为上述的原因，所以在点播采集和输出时，我们也使用了类似HLS切片的技术（同样不深入解释这个技术的原理），所以点播同样采用大内存的机制来进行多种优化。可以说的是点播的内存大多数被用于缓存作用，用来解决多队列文件同时写入和调入的效率问题。

最后一个理由，直播需要大量运算，点播需要大量存储，所以一台运算型服务器，一台文件型服务器的CP=下图

八、 软解和硬解的知识：

这个问题真的要详细说，很多人包括已经购买过TamronOS产品的人至今为止还没搞清楚什么叫软解什么叫硬解。其实如果你是一个很早接触电脑的人（大概从IBM PC 486时代，年代嘛大概是1995年），那么一定知道早在windows3.x年代到win95时代有一种设备叫做解压卡。早期的处理器因为对多媒体处理能力比较差，如果用来播放VCD影片是需要单独配置一张解压卡来进行视频解压处理，这种方式当时就称之为硬解。一直到微软发布DirectX+win95才解决通过CPU的软处理来解压视频（这还需要配合intel发布Pentium100处理器），后来就有了在“奔腾”时代大名鼎鼎的软解播放器“豪杰超级解霸”。还有人记得什么叫MMX（多能奔腾）和3D Now（AMD SIMD）吗？

时过境迁，可能有人会奇怪我为毛要提起这段看似没啥关系的PC发展史，其实只是想抛砖引玉而已。那么现在应该能有个具象化的概念依赖硬件自身处理叫做硬解，依赖软件算法处理叫做软解。那么Android机顶盒的软解和硬解能否套用这套理论呢？

答案既不是肯定的也不是否定的，Android机顶盒基本都是工作在ARM架构的嵌入式系统，由于ARM芯片的厂商很多，而Android系统本身又是一个偏向于娱乐性平台的操作系统，那么他的ARM芯片对各种多媒体数据的处理能力就决定了Android设备本身的性能好坏。所以各大芯片厂商为了提升自己芯片在市场上的竞争优势都会提供适用于二次开发的SDK包，SDK中就包括了播放器部分。

一般意义上讲，在Android平台，基于芯片厂商提供的SDK内嵌播放器来播放视频叫做硬解，通过播放器框架或者安装自己开发的播放器叫做软解。芯片厂商SDK中提供的播放器源码是根据芯片自身定制优化过的（例如在芯片中集成视频解码核心），在播放过程中可以百分百发挥出芯片的性能。例如市场上常见的瑞芯微的系统播放器 RKplayer，华为海思的系统播放器HiPlayer等等。比较注明的Android软解播放器（第三方开源播放器）有IJKplayer FFplayer VLC等，实际上你从应用商店中下载的90%的APP他们如果自带软解功能都是使用这三种软解播放器或者基于这三种播放器的开源代码自己优化而来的。

一款好的Android播放器应用一般就同时支持硬解播放和软解播放。当然从性能上来说任何软解播放器都不可能超越硬解的处理能力。那为什么还要做软解播放器呢？

答案其实很简答，应为硬解播放器是以芯片SDK方式提供的，大多数都是依赖ARM处理器中集成的视频处理芯片，这些芯片的处理能力是物理定死的，而视频编码技术的更新速度又非常快，可能一个芯片发布没多久，又有一种新的视频编码技术产生。此时由于客户无法去升级硬解的解码芯片会导致这些设备无法播放采用最新视频编码技术压制的视频。这时候就有了软解播放器发挥作用的舞台了。现阶段ARM处理器的频率已经到了用Ghz做单位的年代，其处理能力已经在一定程度上超越了X86，利用ARM高效的处理速度+软解播放器的优化算法，目前软解播放的视频不管从质量还是效率上已经于硬解没有太大差异。随着软解技术的日新月异，通过升级软解播放器还可以让一些早期的设备来支持最新的视频编码，以及一些系统硬解播放器无法支持的视频格式（例如RKplayer早期的版本是不支持RM RMVB MKV格式的）。当然软解播放器开发能力的差异还是有的，比如同样的盒子TamronOS的软解播放器播放1080P的视频在不损失任何画质的情况下可以到60帧/秒，某友商的软解播放器只有12帧，甚至还要降低画面质量来保证播放器的流畅工作。

总结：

1：在Android平台下使用系统播放器进行播放的操作叫做硬解。

2：使用第三方播放器进行视频播放的方式叫做软解。

3：通过软解播放器可以让一些早期的设备支持最新的高清视频编码播放。