官网页面很简单清晰,其中在Download页面会有Source code available on GitHub,点进去就是源码。
暂时建议初学者只需要下载老版的先学习,OBS作者在GitHub的网址: https://github.com/jp9000
在Popular repositories下你可以看到OBS和obs-studio,前者就是老版的,仅支持windows系统,后者就是多平台的,支持windows、MAC OS和Linux。
这个项目最早由Fabrice Bellard发起,现在由Michael Niedermayer维护。许多FFmpeg的开发人员都来自MPlayer项目,而且当前FFmpeg也是放在MPlayer项目组的服务器上。项目的名称来自MPEG视频编码标准,前面的"FF“代表"FastForward“,
项目组成
FFmpeg是一套可以用来记录、转换数字音频、视频,并能将其转化为流的开源计算机程序。它包括了目前领先的音/视频编码库libavcodec等。
libavformat
和读取音视频帧等功能;
libavcodec
libavutil
libswscale
libpostproc:用于后期效果处理;
ffmpeg
ffsever
ffplay
多媒体处理功能
多媒体视频处理工具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
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
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
相关版权
FFmpeg被许多开源项目采用,比如ffmpeg2theora,VLC, MPlayer, HandBrake, Blender, Google Chrome等。还有DirectShow/VFW的ffdshow(externalproject)和QuickTime的Perian (external project)也采用了FFmpeg。
FFmpeg耻辱柱(Hall Of Shame):
由于FFmpeg是在LGPL/GPL协议下发布的(如果使用了其中一些使用GPL协议发布的模块则必须使用GPL协议),任何人都可以自由使用,但必须严格遵守LGPL/GPL协议。目前有很多播放软件都使用了FFmpeg的代码,但它们并没有遵守LGPL/GPL协议,没有公开任何源代码。我们应该对这种侵权行为表示耻辱。
2009年加入FFmpeg的播放软件:暴风影音、QQ影音、KMP都在其列。
2009年2月,韩国名软KMPlayer被FFmpeg开源项目发现使用了它们的代码和二进制文件,但是没有按照规定/惯例开放相应说明/源码。因此被人举报,进入了FFmpeg官网上的耻辱黑名单。
2009年5月,网友cehoyos下载了暴风影音软件,解压之后发现其安装程序内包含了大量的开源和私有解码器:avcodec,avformat,avutil,x264,xvid,bass,wmvdmod等,之后暴风影音被正式加入到FFmpeg耻辱名单。
2009年11月,网友roo_zhou向FFmpeg举报,指出QQ影音的credit只给出了修改的FFmpeg源码下载,声称是LGPL许可证。但实际是修改过的ffdshow,采用的是GPL许可证,之后QQ影音被正式加入到FFmpeg耻辱名单之列。
http://blog.csdn.net/leixiaohua1020/article/details/38283297
UDP
1.1. 发送H.264裸流至组播地址
注:组播地址指的范围是224.0.0.0—239.255.255.255
下面命令实现了发送H.264裸流“chunwan.h264”至地址udp://233.233.233.223:6666
注1:-re一定要加,代表按照帧率发送,否则ffmpeg会一股脑地按最高的效率发送数据。
注2:-vcodec copy要加,否则ffmpeg会重新编码输入的H.264裸流。
1.2. 播放承载H.264裸流的UDP
注:需要使用-f说明数据类型是H.264
播放的时候可以加一些参数,比如-max_delay,下面命令将-max_delay设置为100ms:
1.3. 发送MPEG2裸流至组播地址
下面的命令实现了读取本地摄像头的数据,编码为MPEG2,发送至地址udp://233.233.233.223:6666。
1.4. 播放MPEG2裸流
指定-vcodec为mpeg2video即可。
2. RTP
2.1. 发送H.264裸流至组播地址。
下面命令实现了发送H.264裸流“chunwan.h264”至地址rtp://233.233.233.223:6666
注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。
3. RTMP
3.1. 发送H.264裸流至RTMP服务器(FlashMedia Server,Red5等)
面命令实现了发送H.264裸流“chunwan.h264”至主机为localhost,Application为oflaDemo,Path为livestream的RTMP URL。
3.2. 播放RTMP
注: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(内容分发网络)技术原理
链接: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
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
采集,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解决的。总之带宽非常贵。
链接: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、时间成本:等我辛辛苦苦搞了大半年开发了一个直播产品时,直播这场战争或许已经死去了很多家,这个时候活下的直播产品已经拥有了大量用户,我拿什么和他们竞争。