FFMPEG,vlc介绍和视频直播,obs(zz)

最新推荐文章于 2025-07-05 16:59:15 发布

转载最新推荐文章于 2025-07-05 16:59:15 发布 · 1w 阅读

obs 专栏收录该内容

5 篇文章

订阅专栏

本文详细介绍音视频处理的关键技术和直播系统的实现流程，包括不同编解码器的性能比较、视频播放器的工作原理、流媒体协议的应用以及直播平台的技术挑战。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

点击打开链接

1. 有用的资料

http://blog.youkuaiyun.com/fireroll/article/details/18903843

http://blog.youkuaiyun.com/leixiaohua1020/article/details/39803457

http://blog.youkuaiyun.com/leixiaohua1020/article/details/15814587

http://www.zhiboyun.com/zh/document/newbie/concept

目前有另外一个OBS是专门做直播的,开源项目:

https://obsproject.com/

有问源代码的，你只需到OBS官网看下就能找到： https://obsproject.com/
官网页面很简单清晰，其中在Download页面会有Source code available on GitHub，点进去就是源码。
暂时建议初学者只需要下载老版的先学习，OBS作者在GitHub的网址： https://github.com/jp9000
在Popular repositories下你可以看到OBS和obs-studio，前者就是老版的，仅支持windows系统，后者就是多平台的，支持windows、MAC OS和Linux。

关于x265和x264的比较： http://yeyingxian.blog.163.com/blog/static/344712420164309341140/

http://x265.readthedocs.io/en/default/presets.html#presets

结论：

1、x264 veryfast和fast之间速度相差一倍，但是PSNR相差1dB。

2、x264 slow与medium速度差距明显，medium与fast差距不那么明显。medium应该是速度与压缩率之间最好的平衡

~~3、x265 ultrafast与x264 medium速度差不多，但是压缩率还不如x264，没有实用价值~~

4、x265 superfast压缩率全面略胜过x264了，速度跟x264 slow差不多

5、x265 veryfast与faster速度与压缩率几乎没有变化。veryfast对比superfast没有提升。要快，就选superfast

6、x265 medium与fast之间psnr提升很小，甚至倒退。因此fast一档实用性高

7、x265 slow比medium提升很大，展现HEVC压缩率最好选这档

8、x265 slower以下就太慢了，实用性不高

关于业务逻辑的解释：这里

hadoop和spark：视频

详细探究Spark的shuffle实现

VLC：

视频播放的基本原理

当初看VLC代码花了不少时间，其中很大的原因是不太了解视频播放的基本原理。现在看来，几乎所有的视频播放器，如VLC、MPlayer、Xine，包括DirectShow，在播放视频的原理和架构上都是非常相似的，理解这个对理解VLC的源码会有事半功倍的效果。
大致的来说，播放一个视频分为4个步骤：
1. acess 访问，或者理解为接收、获取、得到
2. demux 解复用，就是把通常合在一起的音频和视频分离(还有可能的字幕)
3. decode 解码，包括音频和视频的解码
4. output 输出，也分为音频和视频的输出（aout和vout）
拿播放一个UDP组播的MPEG TS流来说吧，access部分负责从网络接收组播流，放到VLC的内存缓冲区中，access模块关注IP协议，如是否IPv6、组播地址、组播协议、端口等信息；如果检测出来是RTP协议（RTP协议在UDP头部简单得加上了固定12个字节的信息），还要分析RTP头部信息。这部分可以参看VLC源码 /modules/access/udp.c 。在同目录下还可以看到大量的access模块，如file、http、dvd、ftp、smb、tcp、dshow、mms、v4l…等等
而demux部分首先要解析TS流的信息。TS格式是MPEG2协议的一部分，概括地说，TS通常是固定188字节的一个packet，一个TS流可以包含多个program（节目），一个program又可以包含多个视频、音频、和文字信息的ES流；每个ES流会有不同的PID标示。而又为了可以分析这些ES流，TS有一些固定的PID用来间隔发送program和es流信息的表格：PAT和PMT表。关于TS格式的详细信息可以去google一下。
VLC专门做了一个独立的库libdvbpsi来解析和编码TS流，而调用它的代码可以参见VLC源码 /modules/demux/ts.c。
其实之所以需要demux，是因为音视频在制作的时候实际上都是独立编码的，得到的是分开的数据，为了传输方便必须要用某种方式合起来，这就有了各种封装格式也就有了demux。
demux分解出来的音频和视频流分别送往音频解码器和视频解码器。因为原始的音视频都是占用大量空间，而且冗余度较高的数据，通常在制作的时候就会进行某种压缩。这就是我们熟知的音视频编码格式，包括MPEG1（VCD）、MPEG2（DVD）、MPEG4、H.264、rmvb等等。音视频解码器的作用就是把这些压缩了的数据还原成原始的音视频数据。VLC解码MPEG2使用了一个独立的库libmpeg2，调用它的源文件是 /modules/codec/libmpeg2.c。VLC关于编解码的模块都放在/modules/codec目录下，其中包括著名的庞大的ffmpeg。
解码器，例如视频解码器输出的是一张一张的类似位图格式的图像，但是要让人从屏幕看得到，还需要一个视频输出的模块。当然可以像一个Win32窗口程序那样直接把图像画到窗口DC上——VLC的一个输出模块WinGDI就是这么干的，但是通常这太慢了，而且消耗大量的CPU。在Windows下比较好的办法是用DirectX的接口，会自动调用显卡的加速功能。
这样的功能分解使得模块化更容易一点，每个模块住需要专注于自己的事；从整体来说功能强大而且灵活。
但是事情总是不会那么简单。就拿access来说，媒体的访问是分层的，如RTSP就涉及到IPv4、TCP、UDP、RTCP、RTSP等多个层次的协议。有些视频格式包括了传输、封装格式和编辑码格式如MPEG系列，有些封装格式是独立的容器，但是很多人会误解它是编解码格式，如mkv、avi这些。
音频和视频在demux之后就是独立的，但是需要有一套机制把它们同步起来。同时我们需要有一套机制来控制速度、暂停、停止、跳进，获取各种媒体信息，这些都是很复杂而又很重要的事情。
另外也许需要在某个地方插入一些修改，来实现某种效果。如音频的EQ，视频的亮度调整之类的，VLC专门设计了access_filter、audio_filter和video_filter类型的模块来做这一类事情。
VLC比较独特的地方是集成了原来的VLS的功能，这依赖于VLC中stream_output类型的模块，它们可以把正在播放的视频以某种方式重新转码和发送出去，如http、UDP、文件等等。
MPlayer的结构与此是类似的，如/stream目录对应的是access的功能，/mpdemux对应的demux功能，/libmpcodecs是解码器，/libvo和/libao2分别是视频和音频的输出。
DirectShow也是类似的，不过分类更多一些更复杂一点。DirectShow里面的模块叫做“filter”，filter之间通过”pin”来连接。access的模块对应于DirectShow中的Source FIlter，这一类Filter只有输出pin没有输入pin。demux模块对应于splitter filter，这种filter有一个输入pin，多个输出pin。解码模块是一类transform filter，有一个输入pin、一个输出pin，输出模块对应于readering filter，有一个输入pin，没有输出pin。当然transform filter不一定是解码器，也可能是某种其他的处理。

Libav、FFmpeg、mplayer、VLC开源项目、FFDshow

这个项目最早由Fabrice Bellard发起，现在由Michael Niedermayer维护。许多FFmpeg的开发人员都来自MPlayer项目，而且当前FFmpeg也是放在MPlayer项目组的服务器上。项目的名称来自MPEG视频编码标准，前面的"FF“代表"FastForward“，

项目组成

　　FFmpeg是一套可以用来记录、转换数字音频、视频，并能将其转化为流的开源计算机程序。它包括了目前领先的音/视频编码库libavcodec等。

　　libavformat ：用于各种音视频封装格式的生成和解析，包括获取解码所需信息以生成解码上下文结构

　　和读取音视频帧等功能；

　　libavcodec ：用于各种类型声音/图像编解码；

　　libavutil ：包含一些公共的工具函数；

　　libswscale ：用于视频场景比例缩放、色彩映射转换；

　　libpostproc：用于后期效果处理；

　　ffmpeg ：该项目提供的一个工具，可用于格式转换、解码或电视卡即时编码等；

　　ffsever ：一个 HTTP 多媒体即时广播串流服务器；

　　ffplay ：是一个简单的播放器，使用ffmpeg 库解析和解码，通过SDL显示；

多媒体处理功能

　　多媒体视频处理工具FFmpeg有非常强大的功能^[1]包括视频采集功能、视频格式转换、视频抓图、给视频加水印等。

视频采集功能

　　FFmpeg是在Linux下开发出来的，但它可以在包括Windows在内的大多数操作系统中编译。这个项目是由Fabrice Bellard发起的，现在由Michael Niedermayer主持。

　　ffmpeg视频采集功能非常强大，不仅可以采集视频采集卡或USB摄像头的图像，还可以进行屏幕录制，同时还支持以RTP方式将视频流传送给支持RTSP的流媒体服务器，支持直播应用。

　　ffmpeg在Linux下的视频采集

　　在Linux平台上，ffmpeg对V4L2的视频设备提高了很好的支持，如：

　　./ffmpeg -t 10 -f video4linux2 -s 176*144 -r 8 -i /dev/video0-vcodec h263 -f rtp rtp://192.168.1.105:5060 > /tmp/ffmpeg.sdp

　　以上命令表示：采集10秒钟视频，对video4linux2视频设备进行采集，采集 QCIF(176*144)的视频，每秒8帧，视频设备为/dev/video0，视频编码为h263，输出格式为RTP，后面定义了IP地址及端口，将该码流所对应的SDP文件重定向到/tmp/ffmpeg.sdp中，将此SDP文件上传到流媒体服务器就可以实现直播了。

　　ffmpeg在windows下的视频采集

　　在windows下关于ffmpeg视频采集的资料非常少，但是ffmpeg还是支持windows下视频采集的。ffmpeg支持windows下video for windows(VFW)设备的视频采集，不过VFW设备已经过时，正在被WDM的视频设备所取代，但是ffmpeg还没有支持WDM的计划，不过好像有将WDM转为VFW的工具，因此ffmpeg还是可以在windows下进行视频采集的。

视频格式转换功能

　　ffmpeg视频转换功能。视频格式转换，比如可以将多种视频格式转换为flv格式，可不是视频信号转换，，

　　ffmpeg可以轻易地实现多种视频格式之间的相互转换(wma,rm,avi,mod等)，例如可以将摄录下的视频avi等转成现在视频网站所采用的flv格式。

视频截图功能

　　对于选定的视频，截取指定时间的缩略图。视频抓图，获取静态图和动态图，不提倡抓gif文件;因为抓出的gif文件大而播放不流畅

给视频加水印功能

　　使用ffmpeg 视频添加水印(logo)。

支持的格式和协议

支持的编码

　　源自FFmpeg项目组的两个视频编码：

　　Snow

　　FFV1

　　FFmpeg实现的其它音频视频编码：

　　ITU-T video standards: H.261,[5]H.262 (aka MPEG-2Video), H.263[5], H.263v2 and H.264/MPEG-4 AVC[5]

　　ITU-T vocoder standards: G.711µ-law, G.711 A-law, G.722.2 (aka AMR-WB. supports via OpenCORE) andG.726

　　ISO/IEC MPEG video standards: MPEG-1Video, MPEG-2 Video (aka H.262),MPEG-4 Visual and H.264/MPEG-4 AVC

　　ISO/IEC MPEG audio standards: MP2,MP3, AAC and MPEG-4 ALS

　　ISO/IEC/ITU-T JPEG image standards:JPEG and JPEG-LS

　　SMPTE video standards: VC-1 (akaWMV3), VC-3 (aka AVID DNxHD) and DPX image

　　DVD Forum standards related audio codecs: MLP and AC-3

　　3GPP vocoder standards: AMR-NB,AMR-WB (aka G.722.2. supports via OpenCORE)

　　Windows Media Player related video codecs: Microsoft RLE, Microsoft Video 1, Cinepak, Indeo 2, 3 and 5[5],Motion JPEG, Microsoft MPEG-4 v1, v2 and v3, WMV1, WMV2 and WMV3

　　Windows Media Player related audio codecs: WMA1, WMA2, WMA Pro and WMA Voice

　　Real Player related video codecs:Real Video 1, 2, 3 and 4

　　Real Player related audio codecs:Real Audio 1, 2, 3, 4, 5, 6, 7, 8 and 9

　　QuickTime related video codecs:Cinepak, Motion JPEG and Sorenson 3 Codec

　　QuickTime related audio codecs:QDesign Music Codec 2 and ALAC

　　Adobe Flash Player related video codecs: Sorenson 3 Codec, VP6 and Flash Screen Video

　　Xiph-Org: Theora, Speex (vialibspeex), Vorbis and FLAC

　　Sony: ATRAC1 and ATRAC3[5]

　　NTT: TwinVQ

　　On2: Duck TrueMotion 1, DuckTrueMotion 2, VP3, VP5[5] and VP6[5]

　　RAD Game Tools: Smacker video andBink video

　　Truespeech

　　TXD[6]

支持的格式

　　ASF

　　AVI

　　BFI[7]

　　IFF[8]

　　RL2[9]

　　FLV

　　MXF, Material eXchange Format, SMPTE 377M

　　Matroska

　　Maxis XA[10]

　　MSN Webcam stream[11]

　　MPEG transport stream

　　TXD[6]

　　OMA[12]

　　GXF, General eXchange Format, SMPTE 360M

　　mov,mp4,m4a,3gp,

支持的协议

　　HTTP

　　RTP

　　RTSP

　　RealMedia RTSP/RDT

　　TCP

　　UDP

　　Gopher

　　RTMP

　　RTMPT, RTMPE, RTMPTE, RTMPS (via librtmp)

　　SDP

　　MMS over TCP

UDP

1.1. 发送H.264裸流至组播地址

注：组播地址指的范围是224.0.0.0—239.255.255.255

下面命令实现了发送H.264裸流“chunwan.h264”至地址udp://233.233.233.223:6666

 
     [plain] 
     
     view plain
      copy
    
 ffmpeg -re -i chunwan.h264 -vcodec copy -f h264 udp://233.233.233.223:6666

注1：-re一定要加，代表按照帧率发送，否则ffmpeg会一股脑地按最高的效率发送数据。

注2：-vcodec copy要加，否则ffmpeg会重新编码输入的H.264裸流。

1.2. 播放承载H.264裸流的UDP

 
     [plain] 
     
     view plain
      copy
    
 ffplay -f h264 udp://233.233.233.223:6666

注：需要使用-f说明数据类型是H.264

播放的时候可以加一些参数，比如-max_delay，下面命令将-max_delay设置为100ms：

 
     [plain] 
     
     view plain
      copy
    
 ffplay -max_delay 100000 -f h264 udp://233.233.233.223:6666

1.3. 发送MPEG2裸流至组播地址

下面的命令实现了读取本地摄像头的数据，编码为MPEG2，发送至地址udp://233.233.233.223:6666。

 
     [plain] 
     
     view plain
      copy
    
 ffmpeg -re -i chunwan.h264 -vcodec mpeg2video -f mpeg2video udp://233.233.233.223:6666

1.4. 播放MPEG2裸流

指定-vcodec为mpeg2video即可。

 
     [plain] 
     
     view plain
      copy
    
 ffplay -vcodec mpeg2video udp://233.233.233.223:6666

2. RTP

2.1. 发送H.264裸流至组播地址。

下面命令实现了发送H.264裸流“chunwan.h264”至地址rtp://233.233.233.223:6666

 
     [plain] 
     
     view plain
      copy
    
 ffmpeg -re -i chunwan.h264 -vcodec copy -f rtp rtp://233.233.233.223:6666>test.sdp

注1：-re一定要加，代表按照帧率发送，否则ffmpeg会一股脑地按最高的效率发送数据。

注2：-vcodec copy要加，否则ffmpeg会重新编码输入的H.264裸流。

注3：最右边的“>test.sdp”用于将ffmpeg的输出信息存储下来形成一个sdp文件。该文件用于RTP的接收。当不加“>test.sdp”的时候，ffmpeg会直接把sdp信息输出到控制台。将该信息复制出来保存成一个后缀是.sdp文本文件，也是可以用来接收该RTP流的。加上“>test.sdp”后，可以直接把这些sdp信息保存成文本。

2.2. 播放承载H.264裸流的RTP。

 
     [plain] 
     
     view plain
      copy
    
 ffplay test.sdp

3. RTMP

3.1. 发送H.264裸流至RTMP服务器（FlashMedia Server，Red5等）

面命令实现了发送H.264裸流“chunwan.h264”至主机为localhost，Application为oflaDemo，Path为livestream的RTMP URL。

 
     [plain] 
     
     view plain
      copy
    
 ffmpeg -re -i chunwan.h264 -vcodec copy -f flv rtmp://localhost/oflaDemo/livestream

3.2. 播放RTMP

 
     [plain] 
     
     view plain
      copy
    
 ffplay “rtmp://localhost/oflaDemo/livestream live=1”

注：ffplay播放的RTMP URL最好使用双引号括起来，并在后面添加live=1参数，代表实时流。实际上这个参数是传给了ffmpeg的libRTMP的。

有关RTMP的处理，可以参考文章：ffmpeg处理RTMP流媒体的命令大全

mplayer的架构
如果说MPC是Windows上的元祖，那么mplayer就是linux上媒体播放的元祖了。mplayer使用ffmpeg作为解码核心，也是与 ffmpeg结合最紧密的项目，ffmpeg的代码就是由mplayer来host，开发者群也有非常大的交集。借助linux开发/使用者的强大实力，mplayer建立了要比DirectShow稳定的多的工作流程。超越ffmpeg本身的功能外，后来又通过反向工程使之可以调用Windows上的DirectShow Filter DLL，让mplayer架构越来越吸引人，成为兼具稳定性和性能的优秀作品。

优点：稳定，兼容性也可以说相当不错
缺点：代码结构不清晰；纯C语言开发，难于阅读；显卡硬件加速还需要越过更多障碍

VLC的架构
VLC是个后起之秀，开发速度的进展可以说是一只奇葩。虽然同样基于ffmpeg，但可能是相对于“左三年右三年缝缝补补又三年”的mplayer架构来说，VLC的架构在设计之初就很好的考虑到模块化开发，所以使它更吸引年轻的开发人员。成为近年发展非常快的架构。

优点：稳定，兼容性也可以说相当不错
缺点：纯C语言开发，难于阅读；硬件加速略有障碍

说起视频捕捉问题，我们先要来看一下视频捕捉卡。根据使用的驱动程序的不同来分类
，目前市场上大致有两种捕捉卡：VFW (Video for Windows)卡和WDM (Windows Driver
Model)卡。前者是一种趋于废弃的驱动模型，而后者是前者的替代模型；WDM还支持更多
新的特性，比如直接支持电视接收、视频会议、1394接口的设备、桌面摄像机、多条视
频流（Line-21或Closed-Caption等）同时输出等等。采用VFW的一般都是些以前生产的
卡；市面上新出现的，一般都是采用了WDM驱动程序。另外，视频捕捉卡的接口，可以是
以PCI或AGP的方式插入PC机箱，也可以直接以USB接口的方式外挂；还有就是通过1394接
口与PC机相连的数码摄像机等等。

使用DirectShow来处理一般的视频捕捉问题，是相对比较简单的。这当然得益于DirectS
how这一整套先进的应用架构。捕捉卡通常也是以一个(Capture) Filter的形式出现的。
处理视频捕捉，我们同样是使用Filter Graph，同样是操作Filter；控制起来，就似于
操作媒体文件的播放。当然，这主要是从应用程序控制层面上来说的；视频捕捉的应用
场合比较多，视频捕捉本身的一些处理还是有它的特殊性的，而且牵涉面比较广

HTML5 视频直播

CDN（内容分发网络）技术原理

说说CDN技术

HLS-P2P直播： lava-tech / hls-p2p

http://www.gensee.com/blog_31cc34624d7811e58d0290b11c0ec861.html

zhihu的一些评论

https://www.zhihu.com/question/42162310

作者：姚冬
链接：https://www.zhihu.com/question/42162310/answer/93858266
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

视频直播，可以分为采集，前处理，编码，传输，解码，渲染这几个环节，下面分别说下：

采集，iOS是比较简单的，Android则要做些机型适配工作，PC最麻烦各种奇葩摄像头驱动，出了问题特别不好处理，建议放弃PC只支持手机主播，目前几个新进的直播平台都是这样的。

前处理，现在直播美颜已经是标配了，80%的主播没有美颜根本没法看。美颜算法需要用到GPU编程，需要懂图像处理算法的人，没有好的开源实现，要自己参考论文去研究。难点不在于美颜效果，而在于GPU占用和美颜效果之间找平衡。GPU虽然性能好，但是也是有功耗的，GPU占用太高会导致手机发烫，而手机发烫会导致摄像头采集掉帧，iPhone6尤其明显，因为iPhone6的CPU和前置摄像头很近。

编码，肯定要采用硬编码，软编码720p完全没希望，勉强能编码也会导致CPU过热烫到摄像头。硬编码兼容性又是一个大坑，android上要有人去填。编码要在分辨率，帧率，码率，GOP等参数设计上找到最佳平衡点。

传输，自己做不现实，交给CDN服务商吧，也就是贵了点，相信有志于做直播平台改变世界的你不差钱。假设2W PCU大约每月带宽费用100万左右，因为清晰流畅的720p要1.5mbps左右。CDN只提供了带宽和服务器间传输，发送和接收端的网络连接抖动缓冲还是要自己写的。不想要卡顿，必然要加大缓冲，会导致延迟高，延迟高影响互动性，要做权衡。

解码，也肯定要硬解码，目前手机普遍支持硬解了，只是android上还是有兼容性大坑要填。

渲染，这个难点不在于绘制，而在于音画同步，目前几个直播做得都不好。

此外音频还有几个坑要填，比如降噪，音频编码器的选择，各种蓝牙耳机，各种播放模式的适配等，如果你想做主播和观众连线聊天，还有个回声消除问题。

以上是媒体模块，还有信令控制，登录、鉴权、权限管理、状态管理等等，各种应用服务，消息推送，聊天，礼物系统，支付系统，运营支持系统，统计系统等。

后台还有数据库，缓存，分布式文件存储，消息队列，运维系统等。

这些显然不是一个程序员能解决的，如果真的有这样的高手，请联系我，无论你现在薪水多少，我都出两倍。

第一期至少要融资2000万RMB，组建至少10人的技术团队，10人的产品运营团队，争取3个月产品上线，半年达到5W在线（2w 根本不够）然后融资1个亿，或许还有希望一搏。

也许有人对带宽问题存疑，请参考欢聚时代15年四季度财报，带宽成本为人民币1.611亿元，折合每月5000+万，当然不能用这个数去推算在线人数，因为YY采购量很大所以带宽平均成本低，而且YY不只是高清直播，还有很大比例的500kbps左右码率的直播，还有相当一部分带宽是靠P2P解决的。总之带宽非常贵。

作者：姚冬
链接：https://www.zhihu.com/question/42162310/answer/93858266
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

作者：郑岐
链接：http://www.zhihu.com/question/41868659/answer/102475774
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

回答这个问题，我们先看看一个直播产品的功能模块，根据功能模块才好分析所需要的技术人才和判断难点。
1、从 推流到拉流的通道，这当中包括数据采集→数据编码→数据传输(流媒体服务器) →解码数据→播放显示整个流程；因此，需要懂流媒体处理的技术；
2、 内容复制分发，也就是cdn这块，服务器收集到主播视频后再通过在全国各地的节点将视频内容分发到终端。cdn是直播中最贵的，技术难度较高，一般都是采用第三方的；如果自己做的话，也需要和cdn厂商对接有经验的技术；
3、美颜：美颜涉及到复杂的算法和图像处理技术，美颜起初是用于图片上，目前图片上的美颜技术已经较为成熟，然而在视频上的美颜还需要很长的路要走。这里就需要图像处理算法工程师；
4、 聊天室：我们在看直播的时候，还可以在聊天室中聊天，这是应用了im及时通讯中的聊天室功能，聊天室和群聊的区别是，只有用户进入聊天室才能发言，看到好友，退出聊天室后就类似于退群，就收不到消息，看不到用户，看不到聊天记录了。因此，聊天室这块需要在即时通讯方面经验丰富的工程师；
5、 服务器：对于直播产品来说，流量变化是非常大的，一天中直播的流量高峰期基本在晚上，有时候搞个活动，或周杰伦跑来直播了，那这个时候流量可能是平时的几十倍。流量忽高忽低对服务器自然提出了很高的要求。

二、难点
从客户终端来看，一个简单的直播产品，在技术底层的操作确实如此之多，每一项技术都是一个行业。
1、开发量大：上面已经提了最基本的几项开发，每一项开发工作都是很耗费时间的；
2、技术要求高：以聊天室举例，聊天室看似只是直播中的一个小功能，然而对消息处理做不好，就直接导致闪退、卡顿等问题。尤其是在一个聊天室中用户并发量上万的时候，想想1s种要送多少礼物，多少点赞，多少发言，在这种高并发的场景，对im的要求极其高；
3、烧钱，以cdn为例，目前企业自建的平均成本是1.3万元/G/月，刚开始用第三方会便宜一些。但是，可以看看YY的财报，一大部分成本都在cdn上，映客CEO也表示过目前成本最大的还是在于cdn；
4、坑多：第一部分提到的技术，如果在最开始没有把选型做好，或者技术能力不够，那么以后就走上了漫漫的填坑路，新的功能来不及做，老的坑还没有填好；
5、时间成本：等我辛辛苦苦搞了大半年开发了一个直播产品时，直播这场战争或许已经死去了很多家，这个时候活下的直播产品已经拥有了大量用户，我拿什么和他们竞争。