做一个视频站，要什么配置的服务器？

最近听说了“两微一抖”这个词。很容易联想到，“两微”指的是微信和微博，“一抖”指的是抖音，它描述的是今年开始互联网行业呈现的一种新的变化。抖音奇迹般地杀出重围，与微博、微信一起造就了流量市场“三权分立”的现象，这一现象跟IDC行业视频服务器租用业务需求不断增长的行情是相关的。小视频服务器的需求有多大很多人咨询过来就是想要搭建自己的小视频、短视频app，和视频会议、游戏直播、在线教育等视频点播平台，这热度快赶上金融行业了。而不管是视频网站、直播平台还是短视频app都需要放置在服务器上，视频服务器，或者说流媒体服务器就是可以承载这些应用的专用服务器。视频服务器和一般服务器有所区别，它主要包含存储设备、高速缓存和控制管理单元，并增加了许多专用的软硬件功能设备，以应对媒体数据的压缩、存储、传输等功能。

当我们说到小视频、短视频这种点播平台视频服务器的配置，有三点是必须要考虑的:

一、小视频服务器的带宽需求是怎样的

首先，我们可以来看一个数据:通常一个在线观众要流畅的观看高清(480P)视频大概需要300k~400k的带宽流量。由于服务器所要负载的带宽是按可承载的最高并发流量计算出来的，所以我们假设网站同时在线人数是10人左右，那大概3M的带宽可以保证这10人能达到完全流畅播放这个视频的程度。根据带宽的换算方式:128k的流量需要1M的网络带宽，那么这时候带宽的需求至少需要20M以上。

当然视频网站就重要的就是带宽，带宽越大，承载人数就越大，网站运行起来速度流畅，用户体验度就越高。但是这里有一个问题，带宽的成本是很高的，10M、20M可能还能承受，再往上加，成本控制就很成问题了。那么要怎么解决这个问题呢答案是做CDN加速，CDN加速技术是能提高流媒体加速服务的一种关键技术。它要分发的内容预先发送到CDN节点网络，根据网络情况和节点的负载情况，自动将用户的请求引导至离客户最近的节点服务器上，从而达到解决网络拥挤，提高客户的访问速度的问题。这样做有两个好处，一是节省成本;二是更稳定的网络大大提升了用户体验。

二、部署一个短视频app服务器需要多少钱

前面说了带宽的问题，除开服务器硬件的成本，部署视频服务器要“出血”的大头算是解决了。还有什么需要花钱的地方呢视频服务器还要处理音视频存储管理、音视频转码处理、音视频加速播出等问题，具体到细节的问题，比如说滤镜、贴纸、音效等，这些都需要做特殊处理。我大致看了一下，一个要包含录制、导入、贴纸、MV、字幕功能的基础服务器，阿里云官网的报价是16万，这还不包括带宽和做CDN加速的价格!还要专门弄个存储的服务器吧总得搞个安全防护防一防网络攻击吧那这一套下来得多少钱啊不敢想，不敢想。我只是想当个短视频届的网红，你却告诉我要倾家荡产。看来下一个抖音app要拱手相让了

当然，还是有省钱的解决办法的。不过得说，该省的不能省。在前期选择做短视频app时，我们要假定我们的客户群体的数量，一般来说前期人数是很少的，这样的话我们可以选择稍微低配的服务器，在后期推广开了，人数上来之后，我们可以再重新部署嘛。

这是衡量网络视频服务器总体性能的重要指标之一。高带宽意味着网络使用费用的增加，对最终用户而言，这将动摇他们采用数字监控模式的决心，毕竟经济性是任何企业单位都不得不考虑的问题。

由于不同的图像状态（静止、正常活动、高速运动）、图像分辨率、传送图像帧数，其占用网络带宽差异很大，因此许多 网络视频服务器生产厂家在推荐产品时，总是竭力试图模糊这一指标。对此，我们可以设置一种比较统一的图像状态，即对于正常活动图像，图像分辨率达到352288，帧数为 25帧/秒的情况下，一路视频图像所占用的网络带宽。据我们了解，包括台湾、韩国的相当一部分厂家的产品的带宽要求在500-600K之间，有的甚至要求 800-900K。 虽然说，传输延时对任何一种网络视频服务器都是不可避免的，但是不同的网络视频服务器的延时值不同。延时值高低将直接影响数字监控的效果。试想一下，当监控人员在监控中心通过鼠标控制前端摄像机云台时，在五秒钟内点击了五次鼠标，而在第十秒钟后才在显示器上看到第一次点击后的云台控制效果，那会怎么样呢？

由于不同帧速率下传输延时不等（同一产品，帧速率越高，传输延时越低），为对比统一性，条件设为25帧/秒的情况下。 市场上各种网络视频服务器在录像功能上均相当完善，有实时录像、定时录像、报警录像等，报警录像又可分为移动触发录像、手动触发录像、外界传感器（比如红外线探测器）触发录像等。

但是，比如手动触发报警，基本是在事故发生后结束前才启动，录像记录的也只能是报警触发后的图像。对于事件的事后追踪而言，其记录资料是不完整的。

目前有少数厂家的 网络视频服务器已具备报警预触发录像功能，能够保存报警触发前数秒钟至数十秒钟的图像信号，这一功能对于用户事后的报警事件跟踪判断具有特别的意义。 对于大型的网络监控应用系统，由于监控点多且分散，客户端在监控管理上诸多不便，电子地图功能将大大简化用户的功能操作。

网络视频服务器管理软件具备电子地图功能，可自主配置系统监控点示意图，通过示意图的方式形象地描绘监控点的系统分布结构，对于项目系统监控点较多的情况下该功能可直观地显示各监控点分布状况信息，并且通过在示意图上直接点击选取视频监控点就可以观看实时监控图像，极大地方便了用户的操控。 常规的监控管理软件为实现功能的完整性，操作繁琐不便，甚至需要专门培训学习才能熟练掌握。

管理软件提供了适合于领导或非专业监控管理人员使用的简单的WEB版监控管理软件选择，可以IE网页形式提供单画面图像的监看、录像、控制等功能，用户无须安装专业软件，在进行监控图像选择时无须记忆输入不同 网络视频服务器的复杂IP地址，仅需访问系统的WEB服务器下载事先设定的监控点名称等配置信息控件，鼠标点击选择相关图像名称就可以实现监控功能。 市场上的网络视频服务器可支持一路或两路或四路视频图像输入。由于支持的图像路数越多，对产品技术及处理性能的要求越高，因此多数产品为单路或“准多路”产品。

我们所说的真正的多路网络视频服务器 ，能够支持每路输出25帧/秒的数字视频图像，是真正的“实时”。而“准多路”产品无论两路或四路，其输出的数字视频图像的总帧数资源为25帧/秒，也就是 多路共享25帧/秒，在图像处理技术上和单路产品几乎没有区别。这一点从价格上可以进行简单的判别，某些厂家的单路和两路产品价格仅相差数百元，基本上可以判断其两路产品为“准两路产品”。

首先，说说上网看视频，视频质量不同，占用的带快也是不同的。我一风行看**为例（这个应该是非常清晰的了），一般情况下，码率在80K左右就不卡，下面以一个视频占80K带宽来计算。（若是看优酷，带宽更低）

此20M我给你换算成一KB为单位的带宽：20000000/8=2500000，2500000/1024=24414

也就是说你的带宽是24414KB/S，每个视频占用80K的话，可以同时看的有：24414/80=3051人。

理论计算的值为3051人，这是建立在每个视频占用80K带宽和网络完全理想没有衰减的情况下的。

主要情况因看的视频不同而不同。但是和这个数字应该是相差不大。

webrtc中的带宽自适应算法分为两种：

1，　发端带宽控制，　原理是由rtcp中的丢包统计来动态的增加或减少带宽，在减少带宽时使用TFRC算法来增加平滑度。

2，　收端带宽估算，　原理是并由收到rtp数据，估出带宽；　用卡尔曼滤波，对每一帧的发送时间和接收时间进行分析，　从而得出网络带宽利用情况，修正估出的带宽。

两种算法相辅相成，　收端将估算的带宽发送给发端，　发端结合收到的带宽以及丢包率，调整发送的带宽。

下面具体分析两种算法：

2, 接收端带宽估算算法分析

结合文档http://toolsietforg/html/draft-alvestrand-rtcweb-congestion-02以及源码webrtc/modules/remote_bitrate_estimator/overuse_detectorcc进行分析

带宽估算模型： d(i) = dL(i) / c + w(i) d(i)两帧数据的网络传输时间差，dL(i)两帧数据的大小差， c为网络传输能力， w(i)是我们关注的重点， 它主要由三个因素决定：发送速率， 网络路由能力， 以及网络传输能力。w(i)符合高斯分布， 有如下结论：当w(i)增加是，占用过多带宽（over-using)；当w(i)减少时，占用较少带宽（under-using)；为0时，用到恰好的带宽。所以，只要我们能计算出w(i)，即能判断目前的网络使用情况，从而增加或减少发送的速率。

算法原理：即应用kalman-filters

theta_hat(i) = [1/C_hat(i) m_hat(i)]^T // i时间点的状态由C, m共同表示，theta_hat(i)即此时的估算值

z(i) = d(i) - h_bar(i)^T theta_hat(i-1) //d(i)为测试值，可以很容易计算出， 后面的可以认为是d(i-1)的估算值， 因此z(i)就是d(i)的偏差，即residual

theta_hat(i) = theta_hat(i-1) + z(i) k_bar(i) //好了，这个就是我们要的结果，关键是k值的选取，下面两个公式即是取k值的，具体推导见后继博文。

E(i-1) h_bar(i)

k_bar(i) = --------------------------------------------

var_v_hat + h_bar(i)^T E(i-1) h_bar(i)

E(i) = (I - K_bar(i) h_bar(i)^T) E(i-1) + Q(i) // h_bar(i)由帧的数据包大小算出

由此可见，我们只需要知道当前帧的长度，发送时间，接收时间以及前一帧的状态，就可以计算出网络使用情况。

接下来具体看一下代码：

[cpp] view

plaincopy

void OveruseDetector::UpdateKalman(int64_t t_delta,

double ts_delta,

uint32_t frame_size,

uint32_t prev_frame_size) {

const double min_frame_period = UpdateMinFramePeriod(ts_delta);

const double drift = CurrentDrift();

// Compensate for drift

const double t_ts_delta = t_delta - ts_delta / drift; //即d(i)

double fs_delta = static_cast<double>(frame_size) - prev_frame_size;

// Update the Kalman filter

const double scale_factor = min_frame_period / (10000 / 300);

E_[0][0] += process_noise_[0] scale_factor;

E_[1][1] += process_noise_[1] scale_factor;

if ((hypothesis_ == kBwOverusing && offset_ < prev_offset_) ||

(hypothesis_ == kBwUnderusing && offset_ > prev_offset_)) {

E_[1][1] += 10 process_noise_[1] scale_factor;

}

const double h[2] = {fs_delta, 10}; //即h_bar

const double Eh[2] = {E_[0][0]h[0] + E_[0][1]h[1],

E_[1][0]h[0] + E_[1][1]h[1]};

const double residual = t_ts_delta - slope_h[0] - offset_; //即z(i)， slope为1／C

const bool stable_state =

(BWE_MIN(num_of_deltas_, 60) fabsf(offset_) < threshold_);

// We try to filter out very late frames For instance periodic key

// frames doesn't fit the Gaussian model well

if (fabsf(residual) < 3 sqrt(var_noise_)) {

UpdateNoiseEstimate(residual, min_frame_period, stable_state);

} else {

UpdateNoiseEstimate(3 sqrt(var_noise_), min_frame_period, stable_state);

}

const double denom = var_noise_ + h[0]Eh[0] + h[1]Eh[1];

const double K[2] = {Eh[0] / denom,

Eh[1] / denom}; //即k_bar

const double IKh[2][2] = {{10 - K[0]h[0], -K[0]h[1]},

{-K[1]h[0], 10 - K[1]h[1]}};

const double e00 = E_[0][0];

const double e01 = E_[0][1];

// Update state

E_[0][0] = e00 IKh[0][0] + E_[1][0] IKh[0][1];

E_[0][1] = e01 IKh[0][0] + E_[1][1] IKh[0][1];

E_[1][0] = e00 IKh[1][0] + E_[1][0] IKh[1][1];

E_[1][1] = e01 IKh[1][0] + E_[1][1] IKh[1][1];

// Covariance matrix, must be positive semi-definite

assert(E_[0][0] + E_[1][1] >= 0 &&

E_[0][0] E_[1][1] - E_[0][1] E_[1][0] >= 0 &&

E_[0][0] >= 0);

slope_ = slope_ + K[0] residual; //1/C

prev_offset_ = offset_;

offset_ = offset_ + K[1] residual; //theta_hat(i)

Detect(ts_delta);

}

[cpp] view

plaincopy

BandwidthUsage OveruseDetector::Detect(double ts_delta) {

if (num_of_deltas_ < 2) {

return kBwNormal;

}

const double T = BWE_MIN(num_of_deltas_, 60) offset_; //即gamma_1

if (fabsf(T) > threshold_) {

if (offset_ > 0) {

if (time_over_using_ == -1) {

// Initialize the timer Assume that we've been

// over-using half of the time since the previous

// sample

time_over_using_ = ts_delta / 2;

} else {

// Increment timer

time_over_using_ += ts_delta;

}

over_use_counter_++;

if (time_over_using_ > kOverUsingTimeThreshold //kOverUsingTimeThreshold是gamma_2， gamama_3=1

&& over_use_counter_ > 1) {

if (offset_ >= prev_offset_) {

time_over_using_ = 0;

over_use_counter_ = 0;

hypothesis_ = kBwOverusing;

}

}

} else {

time_over_using_ = -1;

over_use_counter_ = 0;

hypothesis_ = kBwUnderusing;

}

} else {

time_over_using_ = -1;

over_use_counter_ = 0;

hypothesis_ = kBwNormal;

}

return hypothesis_;

}

因为视频需要大带宽才会流畅，可以计算一下，如果服务器的带宽为1M，那么下行速度只有100kb/s，视频每帧如果3张，每张1mb，那么一帧视频下载下来，需要30秒，视频就会变成预览，所以视频网站一定要很高带宽才可以保证流畅度。

网络视频服务器的压缩算法标准不外乎有MJPEG、MPEG-1、MPEG-4三种。

MJPEG压缩技术标准源于JPEG压缩技术，是一种简单的帧内JPEG压缩，压缩后图像清晰度较好。但由于这种方式本身的技术限制，无法作大比例压缩，数据量较高，录像每小时1-2G空间，网络传输耗费大量的带宽资源，不大适用于移动物体图像的压缩，也不大适用于国内长时间保安录像的需求。

MPEG-1压缩技术标准采用前后帧多帧预测的压缩算法，具有很大的压缩灵活性，应用最为广泛，这种算法技术发展成熟，数据压缩率相比MJPEG要高，但数据量还是较大，录像每小时300-400M空间，若用于银行长时间实时录像，占用硬盘空间较大，尤其是网络传输占用带宽较大，不大实用于视频图像远程传输。

MPEG-4压缩技术标准是目前进入实用阶段的最为先进的压缩技术，它利用很窄的带宽，通过帧重建技术压缩和传送图像，以求以最少的数据获得最佳的图像质量。MPEG-4的特点使其更适于交互AV服务以及远程监控，采用MPEG-4压缩算法，图像压缩比较高，录像每小时100-200M空间，图像清晰度高，网络传输占用带宽小，能通过各种传输方式进行远程视频图像传输。 由于网络视频监控服务器多用于对多个分散网点的远程、实时、集中监控，因此，监控中心可以同时监控、录像的视频路数是衡量远程集中监控效果的重要指标。

在理论上可同时对无限多个监控位点图像实施远程实时监控、录像。但在实际应用中受监控中心实际网络带宽的限制，如中心网络带宽为10M的话，假设每路视频占用250K，则最多可实现40路视频的录像，除非降低每路视频带宽或增加网络带宽。 在基于网络视频服务器的大型网络视频集中监控系统中，监控中心通常设置了多个监控客户端，往往存在同一时间段访问某一个前端监控网点并发出实时监控或录像调用请求的情况。当监控中心有N个监控客户端需要同时观看远程某一个监控点图像时（假设一路图像带宽占用为250K），常规模式下外网带宽占用为（N250）K，通常会导致数据堵塞从而影响监控效果，因此常规的网络视频服务器系统一般只能支持三、四个客户端的同时访问要求。

是否支持本地录像资料的远程在线智能化检索、回放和转录 针对于多个分散网点的远程、实时、集中监控系统应用情况，由于公网带宽资源的稀缺性和有偿性，出于经济方面的考虑，多数用户会采用ADSL宽带线路进行远程数字视频信号的传输。电信部门提供的包月ADSL线路带宽理论值为上行带宽512K，下行2M，但实际的上行带宽往往只有200多K。为充分满足监控应用需求，实际系统中多采用“中心远程实时轮巡监控、网点本地实时录像、中心远程随时调看录像”的功能模式。

对于网点本地录像资料的远程调看应用，多数网络视频服务器软件还不能提供有效的解决方案，多数由网点本地的工作人员选择所需的录像资料文件并远程拷贝或E-MAIL给中心监控人员，中心监控人员接收到后再打开观看，操作繁琐费时。 在基于ADSL宽带线路的网络应用环境下，电信公司提供给用户的接入方式是动态IP接入方式，即用户通过虚拟拨号技术动态获得IP地址来上网的方式：用户通过本地电脑安装的拨号程序，驱动ADSL Modem拨号接入INTERNET时，ISP通常会随机分配给用户一个公共IP地址，在断线之前这个IP地址是唯一的，其他用户可以通过这个IP地址来 访问该用户，但是一旦断线后再次连接时，ISP会重新随机分配另外一个IP地址给该用户。

在利用网络视频服务器 实现远程视频集中监控应用中，在基于ADSL宽带线路的网络应用环境下，如何简便地实现在动态IP地址条件下监控中心对监控前端的实时访问，仍是困扰诸多工程商、系统集成商以及 网络视频服务器 生产厂家的难题之一。许多网络视频服务器 不能提供动态IP接入的解决方案，一旦工程商或用户利用 网络视频服务器并通过ADSL来组建远程监控系统，很可能会导致系统无法实现预期的功能。 在某些系统应用情况下，视频监控系统仅仅是整个大型系统的一个应用子系统，如果能将视频监控系统和其它系统进行有机整合，将大大方便用户的系统操作使用。