这个音视频领域主要集中在流媒体这一块，主要讲解视频会议、直播与点播。由于曾供职于一家传统视频会议厂商，后供职于一家互联网公司（需要做点播服务），因而对本人的经历进行总结。其中音视频领域分布很广，就我所知在这其中还有信令与编码两块主要内容，我主要关注于相对简单的信令层面。
视频会议、直播与点播的异同
视频会议
视频会议基本认知
视频会议的本质就是要保证视频双方能够互相实时的交流沟通。
无论中间经过多少个MCU与桥接，都是为了互连互通，保证实时的交流沟通。
市场格局
如题主要专注于专业视频会议这一块儿。区别与微信，qq，facebook等互联网视频互连，视频会议对于画质成像，音频音质，网络带宽，私有部署等都有着较高的要求。
这一块市场各方势力犬牙交错，有着CISCO、HUAWEI、宝利通等老牌厂商，也有诸如小鱼,VHD,腾讯视频会议,钉钉会议等新入局的硬件或软件企业。其中腾讯视频会议、钉钉会议主要解决的是传统厂商领域无法触及的公共视频服务领域，但是就本人观察而言他们与传统视频会议领域有一定的重合性。例如，在一些非重要场合有些部门仍采用公共视频服务。在疫情新新形势下，专业视频会议与公共视频服务的更是用激烈来形容。后续的发展如何就看各家本事了！
专业视频会议领域主流的协议为SIP与H323，其中SIP由于其简单与可定制的特性深受互联网企业的喜爱（现在的SIP也不简单了）。即时目前由于传统音视频领域厂商与各种老系统兼容原因采用了H323，但是观察CISCO MEETING SEVER与HUAWEI的MCU会发现全部采用SIP，传统厂商这边SIP显然是未来的主要发展方向。新兴互联网企业这边如FACEBOOK,微信,QQ等主要公共音视频媒体服务这一块的企业全是SIP的修改。当然，H323协议栈也有其可借鉴性，由于本人对H323协议栈研究不深，不敢妄下断言。本人就目前而言接收到的信息表明，H323与SIP有融合趋势，至于怎么融合或以谁为主的融合就全凭各位看官评判。
讲完协议来简单的讲一下GOOGLE这个新入的搅局者提出的解决方案WebRTC。
本人对于WebRTC了解有限，仅对其ICE协议框架和原理有简单的认识，但是并不妨碍我对其产生基本认知（嘿嘿）。本人将其单独拎出来是因为WebRTC不拘泥于通信协议（你完全可以自己写一个交互协议）、对音视频质量保证和跨平台的特点，注定WebRTC是一款不仅适用于传统音视频厂商，也适应互联网传输特点的端的解决方案。就目前的发展趋势而言，WEBRTC的解决方案不仅能适用于视频会议，在直播方面也能大展拳脚（“点播”黑人问号？）
当然对于WEBRTC在MCU这方面的商业案例，就目前而言本人还没听说有谁采用WebRTC，有待后续观察。就个人猜想而言，稳定、兼容与代码转移成本等都会是其难点，传统厂商大多也只是将WebRTC作为端的补充。
视频会议特点
- 延时低：视频会议要求延时低于400ms，否则会影响视频通话的质量
- 音视频质量高：要求音视频的质量，音视频质量稳定
- 带宽大：为了保障音视频质量，需要占用大量的带宽
视频会议技术
- 通信协议：SIP或H323两分天下
- 媒体流传输：RTP与RTSP的媒体流传输协议
- 音频编码：OPUS与G711
- 其中OPUS在低带宽与高带宽下都能保证较好的音频质量
- G711有各种衍生型号，其采用占用较高的带宽来获取更好的音频质量
- 视频编码：H264,H264HP
- 一般采用H264视频编码
- MCU解决方案：
- 闭源：CMS(CISCO MEETING SERVER)、华为、宝利通等
- 开源：FreeSWITCH、Asterisk、OpenSIPS、。目前主流采用FreeSWITCH，Asterisk由于开发较早，有更好的硬件支持能力
- 客户端解决方案：
- 闭源：宝利通、好视通、Cisco各种硬件端、VHD各种硬件
- 开源：LinePhone、WebRTC
直播
直播的基本认知
直播的本质就是能够实时的批量分发流。
其着重点在于实时与实时分发流。不同于视频会议，虽然强调了实时性，但是其着眼点落在了分发流，而视频会议落在了交流沟通
市场格局
几年前的直播大战，虽只是偶有听闻，但仍对其中的波澜壮阔感到心惊。但是，这些上层应用于商战上面的内容对于我们这些技术而言只能做个趣闻罢了。技术领域的你死我活才作为技术人员的关注重点。
由于本人未曾供职于直播领域的相关行业，只能作为从视频会议的角度观察直播，如有遗漏或缺憾，请谅解。
直播领域的大战在技术层面，其实从乔布斯时代就已经开始。当时的主流直播协议分为Adobe的RTMP协议，与苹果的基于http的HLS协议。其中RTMP能够用于推流与拉流，而HLS只能用于拉流。为什么HLS只能用于拉流呢？可以参考本文
到目前由于RTMP拉流端与FLASH是强绑定关系，且Chrome宣布不再支持FLASH的，那么是否RTMP就此会淡出拉流端呢?答案是不会。因为Adobe妥协了，推出了HTTP-FLV，延续RTMP在拉流端的生命。
直播特点
没从事过直播行业，对于其有什么特点也不知从何总结。如有知道的可以发邮件给我hepingadjust@163.com
直播技术
- 音频编码：AAC
- 直播领域的音频编码一般采用AAC，主要是AAC的编解码器开源库很多，且直播对于时延要求没视频会议那么高
- 视频编码：H264,
- 祖传H264，听说国内平台要支持H265了
- 通信协议：RTMP，HLS，HTTP-FLV
- 流的主要传输一般就采用这三种，具体的技术对比可以自行百度与参考
- 开源解决方案：Nginx-RTMP，SRS
- 就我所知的商业公司大部分采用SRS作为直播系统开发，其后续路线图也会支持WebRTC作为补充，降低直播中的延迟。
- 闭源解决方案：这就不清楚了
直播发展
直播目前发展出了连麦，连麦的本质属于上面的视频会议。当然相较于传统的视频会议，直播连麦不需要有那么高的要求，但是也展示出了直播在技术上面的发展方向。而传统的视频会议这一块，目前也支持将视频会议以直播的形式推流出去。
由此观之，直播与视频会议的发展都在向对方趋同。至于最后的发展结果，有待后续观察
点播
点播的基本认识
点播的本质是对音视频的分发
很显然，从上面的用词已经可以发现，点播已经没有了实时。这取决于点播是保留的视频快捷索引与访问。
市场格局
点播视频的玩家目前主要分布在短视频与长视频，短视频以抖音，快手为主要玩家，长视频中本人认知中有Youtuber、Bilibili网站、爱优腾等主要玩家。短视频与长视频的竞争，爱优腾的爱恨情仇，本文统统不关注。这种商业战场上的内容也不是本人这种小民能参与的！
从传输方式上，点播分为文件下载、http渐进式下载、http流式下载、实时流媒体传输。其中的具体区别请参照本文，此文对其中的区别点有较好的认识。其中的HTTP流式传输本人理解为渐进式下载与实时流媒体传输的一个概念化产物，其用HTTP实现流媒体传输，本质还是采用实时流媒体传输手段，区别与实时流媒体的是HTTP流式传输用于传输压制好的视频。
这方面杰出的代表有http-flv与hls，当然也有老将rtmp，至于如HDS就不要碰了（Adobe的东西如果不流行不要碰）。在那个flash风靡年代，rtmp更是独占鳌头；在后续hls加入战场后，外加flash自身的安全问题，hls更是成了点播的头号选择。
但是随着业务的发展，点播行业需要更高的码率，更流畅的视频体验，更多的音频轨道选择等一系列的需求。hls作为十多年前提出的协议，即时采用二级索引m3u8能满足分发要求，也无法解决多音频轨道问题。对于此，国际标准组MPEG制定了新的协议，Dash协议。本人对Dash还没有深入研究，至于dash有哪些优缺点，后续将持续更新。
就目前头部视频网站，Youtuber与Bilibili都采用了Dash协议，且Google与Bilibili在开源社区都有维护跨平台的支持Dash协议的播放器。当然，国内爱优腾仍然采用hls作为点播协议。后续点播市场仍处于变化中，但是点播的专业肯定是未来的趋势！
点播特点
- 高效分发：通过各个CDN节点，高效分发视频资源
- 高码率：通过高效分发带来的便利性，根据CDN在各个地区建立的中心，提供更高的码率支持
- 动态切换：动态监控用户的网络状态，并动态切换视频的码率，提供更高质量的视频服务
点播技术
- 协议：dash，hls，http-flv
- 音频编码：mp4
- 视频编码：mp4,flv
- 服务端开源解决方案：srs的hls点播，nginx-rtmp的点播
- 闭源解决方案：
- 端的开源解决方案：dash的端、vlc、flashjs
总结
视频会议领域是以技术驱动型，市场上主要检验标准是以你达到多好的效果和多高的稳定性，并且具有很强的依赖性
直播与点播是以内容为驱动型，市场上主要的检验标准是你能产出多少有趣的内容，只要你的音视频播放能够正常流畅即可（特别是国内）。你不会为了b站的4k视频去专门开会员吧（玩笑）！