摄像头采集；
1、音视频编解码；
3、音视频流推送到流媒体服务器；
4、流媒体网络分发；
5、用户播放器；
6、音视频同步；
7、网络延迟自适应；
8、需要录制，多种视频文件的格式和封装；
9、语言：C、C、html、php、mysql
10、开发环境：嵌入式，Linux，Windows，Web
还有就是视频播放解决方案（卡顿、延迟）：
1、CDN加速；
2、自己架服务器；
3、用别人的云服务。
用CDN加速，可以尽量减少延迟。目前业内水准来看，视频延迟都在3-6秒之间。也就是在视频直播时，你看到的是几秒以前的画面。
自己架服务器，如果部署的数据中心不够多，那么遇上跨网、跨省的传输，还是得用CDN加速。那么为了尽可能降低延迟，你就需要在全国各省市都部署数据中心，来解决跨网、跨省的传输。用云服务的话，就是别人把服务器给你架好了，你只要傻瓜式的用就行了。当然，不管用哪种方式，综合权衡利弊，找到适合的方案就是最好的方案。
开发视频直播的流程有哪些：
1、采集；
2、前期处理；
3、编码；
4、传输；
5、解码；
6、渲染。
采集：iOS是比较简单的，Android则要做些机型适配工作。PC最麻烦各种奇葩摄像头驱动，出了问题特别不好处理，建议放弃PC只支持手机主播，目前几个新进的直播平台都是这样的。
前期处理：现在直播美颜已经是标配了，80%的主播没有美颜根本没法看。美颜算法需要懂图像处理算法的人，没有好的开源实现，要自己参考论文去研究。算法设计好了还要优化，无论你打算用CPU还是GPU优化，算法优化本身也需要专业知识支持。GPU虽然性能好，但是也是有功耗的。GPU占用太高会导致手机发烫，而手机发烫会导致摄像头采集掉帧。而这一切都是需要经验支撑。
编码：如果你要上720p，肯定要采用硬编码。软编码720p完全没希望，硬件编码不灵活。兼容性也有问题。如何适应纷繁复杂的网络和纷繁复杂的上下行设备？安卓和芯片的坑，开发过的人都知道。那有人问，要求不高，上软编码低分辨率360p行不行？就算上低分辨率，软编码还是会让CPU发烫，CPU过热烫到摄像头，长期发烫不仅直接反应是费电。既然是手机直播，插着电源和充电器实在说不过去吧。还有，CPU发烫会降频，怎么办？这还是只说性能方面。和前处理只影响图像质量和功耗不同，视频编解码技术还关联成本计算和网络对抗。考虑性能、功耗、成本、网络这四个之后你编码的码率、帧率、分辨率。软硬件开发该如何选择？
传输：自己做不现实，交给第三方服务商吧。
解码：如果你用硬解码，一定要做容错处理，一定要做适配。突然一个crash导致手机重启不好吧。安卓的硬解码，不说了。如果你加了网络目前手机的硬解码还不一定支撑用软解码，功耗发热的问题又来了。
渲染：为什么手机明明解码出好多帧数据。就是渲染不出来。为什么画面就是不同步。
以上是媒体模块，还有信令控制，登录、鉴权、权限管理、状态管理等等，各种应用服务，消息推送，聊天，礼物系统，支付系统，运营支持系统，统计系统等。后台还有数据库，缓存，分布式文件存储，消息队列，运维系统等。
以上技术要点的小结，确实能说明开发一个能用于生产环境的实时视频直播平台确非易事，跟IM里传统的实时音视频一样，这样的技术都是音视频编解码网络传输技术的综合应用体。
需要安装Broadcaster软件，Broadcaster是一款专业的多媒体直播和录制软件，它支持对MP4、MOV、FLV等多种视频格式做编解码 *** 作，并通过RTMP,>局域网里的流媒体服务器会卡。根据查询相关公开信息显示，流媒体服务器使用的编解码器不够高效会卡，如果局域网中的其他设备正在使用大量带宽，流媒体服务器会受到影响，导致卡顿，流媒体服务器的性能不足，例如处理器速度或内存容量不足，会卡顿或崩溃。一、直播的技术架构：
直播视频采集SDK（PC/IOS/Anddroid）——直播CDN
（直播流分发加速）——直播视频播放器SDK（PC/IOS/Android）
二、音视频处理的一般流程：
数据采集→数据编码→数据传输(流媒体服务器)→解码数据→播放显示
1、数据采集：
摄像机及拾音器收集视频及音频数据，此时得到的为原始数据
涉及技术或协议：
摄像机：CCD、CMOS
拾音器：声电转换装置（咪头）、音频放大电路
2、数据编码：
使用相关硬件或软件对音视频原始数据进行编码处理（数字化）及加工（如音视频混合、打包封装等），得到可用的音视频数据
涉及技术或协议：
编码方式：CBR、VBR
编码格式
视频：H265、H264、MPEG-4等，封装容器有TS、MKV、AVI、MP4等
音频：G711μ、AAC、Opus等，封装有MP3、OGG、AAC等
3、数据传输：
将编码完成后的音视频数据进行传输，早期的音视频通过同轴电缆之类的线缆进行传输，IP网络发展后，使用IP网络优传输
涉及技术或协议：
传输协议：RTP与RTCP、RTSP、RTMP、>
控制信令：SIP和SDP、SNMP等
4、解码数据：
使用相关硬件或软件对接收到的编码后的音视频数据进行解码，得到可以直接显示的图像/声音
涉及技术或协议：
一般对应的编码器都会带有相应的解码器，也有一些第三方解码插件等
5、播放显示：
在显示器（电视、监视屏等）或扬声器（耳机、喇叭等）里，显示相应的图像画面或声音
涉及技术或协议：
显示器、扬声器、3D眼镜等
三、常见的视频直播相关协议：
1、RTMP(RealTimeMessagingProtocol，实时消息传送协议)
RTMP是AdobeSystems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。它有三种变种：
1）、工作在TCP之上的明文协议，使用端口1935；
2）、RTMPT封装在>
3）、RTMPS类似RTMPT，但使用的是>
RTMP协议是被Flash用于对象、视频、音频的传输。这个协议建立在TCP协议或者轮询>
2、RTSP(RealTimeStreamingProtocol，实时流传输协议)
RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接，为选择发送通道如UDP、组播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。
RTSP语法和运作跟>
3、RTP(Real-timeTransportProtocol，实时传输协议)
RTP是针对多媒体数据流的一种传输层协议，详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通系统（配合H323或SIP），使它成为IP电话产业的技术基础。
RTP是建立在UDP协议上的，常与RTCP一起使用，其本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。
RTP并不保证传送或防止无序传送，也不确定底层网络的可靠性，只管发送，不管传输是否丢包，也不管接收方是否有收到包。RTP实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，如在视频解码中，就不需要顺序解码。
4、RTCP(Real-timeTransportControlProtocol，实时传输控制协议）
RTCP是RTP的配套协议，为RTP媒体流提供信道外的控制。RTCP和RTP一起协作将多媒体数据打包和发送，定期在多媒体流会话参与者之间传输控制数据。
RTCP的主要功能是为RTP所提供的服务质量（QoS）提供反馈，收集相关媒体连接的统计信息，例如传输字节数，传输分组数，丢失分组数，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息来提高服务质量，比如限制流量或改用压缩比小的编解码器。
流媒体技术也称流式媒体技术。所谓流媒体技术就是把连续的影像和声音信息经过压缩处理后放上网站服务器,由视频服务器向用户计算机顺序或实时地传送各个压缩包，让用户一边下载一边观看、收听，而不要等整个压缩文件下载到自己的计算机上才可以观看的网络传输技术。
该技术先在使用者端的计算机上创建一个缓冲区，在播放前预先下一段数据作为缓冲，在网路实际连线速度小于播放所耗的速度时，播放程序就会取用一小段缓冲区内的数据，这样可以避免播放的中断，也使得播放品质得以保证。
扩展资料：
流式传输技术又分两种，一种是顺序流式传输，另一种是实时流式传输。
（1）顺序流式传输是顺序下载，在下载文件的同时用户可以观看，但是，用户的观看与服务器上的传输并不是同步进行的，用户是在一段延时后才能看到服务器上传出来的信息，或者说用户看到的总是服务器在若干时间以前传出来的信息。
在这过程中，用户只能观看已下载的那部分，而不能要求跳到还未下载的部分。顺序流式传输比较适合高质量的短片段，因为它可以较好地保证节目播放的最终质量。它适合于在网站上发布的供用户点播的音视频节目。
（2）在实时流式传输中，音视频信息可被实时观看到。在观看过程中用户可快进或后退以观看前面或后面的内容，但是在这种传输方式中，如果网络传输状况不理想，则收到的信号效果比较差。
参考资料来源：百度百科-流媒体技术
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）