Home  >  Article  >  Web Front-end  >  网络视频直播系统开发需要用到哪方面的知识?

网络视频直播系统开发需要用到哪方面的知识?

不言
不言Original
2018-05-16 11:19:306813browse

网络视频直播系统需要用到哪些知识?用什么语言开发?什么开发环境?除了HTML5之外还需要哪些方面的知识?

回复内容:

一、直播的技术架构:
直播视频采集SDK(PC/IOS/Anddroid)——直播CDN

(直播流分发加速)——直播视频播放器SDK(PC/IOS/Android)

二、音视频处理的一般流程:

数据采集→数据编码→数据传输(流媒体服务器) →解码数据→播放显示

1、数据采集:

摄像机及拾音器收集视频及音频数据,此时得到的为原始数据

涉及技术或协议:

摄像机:CCD、CMOS

拾音器:声电转换装置(咪头)、音频放大电路

2、数据编码:

使用相关硬件或软件对音视频原始数据进行编码处理(数字化)及加工(如音视频混合、打包封装等),得到可用的音视频数据

涉及技术或协议:

编码方式:CBR、VBR
编码格式
视频:H.265、H.264、MPEG-4等,封装容器有TS、MKV、AVI、MP4等
音频:G.711μ、AAC、Opus等,封装有MP3、OGG、AAC等

3、数据传输:

将编码完成后的音视频数据进行传输,早期的音视频通过同轴电缆之类的线缆进行传输,IP网络发展后,使用IP网络优传输

涉及技术或协议:

传输协议:RTP与RTCP、RTSP、RTMP、HTTP、HLS(HTTP Live Streaming)等

控制信令:SIP和SDP、SNMP等

4、解码数据:

使用相关硬件或软件对接收到的编码后的音视频数据进行解码,得到可以直接显示的图像/声音

涉及技术或协议:

一般对应的编码器都会带有相应的解码器,也有一些第三方解码插件等

5、播放显示:

在显示器(电视、监视屏等)或扬声器(耳机、喇叭等)里,显示相应的图像画面或声音

涉及技术或协议:

显示器、扬声器、3D眼镜等

三、常见的视频直播相关协议:

1、RTMP(Real Time Messaging Protocol,实时消息传送协议)

RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。它有三种变种:

1)、工作在TCP之上的明文协议,使用端口1935;

2)、RTMPT封装在HTTP请求之中,可穿越防火墙;

3)、RTMPS类似RTMPT,但使用的是HTTPS连接;

RTMP协议是被Flash用于对象、视频、音频的传输。这个协议建立在TCP协议或者轮询HTTP协议之上。RTMP协议就像一个用来装数据包的容器,这些数据既可以是AMF格式的数据,也可以是FLV中的视音频数据。一个单一的连接可以通过不同的通道传输多路网络流,这些通道中的包都是按照固定大小的包传输的。

2、RTSP(Real Time Streaming Protocol,实时流传输协议)

RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架,数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接,为选择发送通道如UDP、组播UDP与TCP提供途径,并为选择基于RTP上发送机制提供方法。

RTSP语法和运作跟HTTP/1.1类似,但并不特别强调时间同步,所以比较能容忍网络延迟。代理服务器的缓存功能也同样适用于RTSP,并且因为RTSP具有重新导向功能,可根据实际负载情况来切换提供服务的服务器,以避免过大的负载集中于同一服务器而造成延迟。

3、RTP(Real-time Transport Protocol,实时传输协议)

RTP是针对多媒体数据流的一种传输层协议,详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统(配合RTCP协议),视频会议和一键通系统(配合H.323或SIP),使它成为IP电话产业的技术基础。

RTP是建立在UDP协议上的,常与RTCP一起使用,其本身并没有提供按时发送机制或其它服务质量(QoS)保证,它依赖于低层服务去实现这一过程。

RTP 并不保证传送或防止无序传送,也不确定底层网络的可靠性,只管发送,不管传输是否丢包,也不管接收方是否有收到包。RTP 实行有序传送,RTP中的序列号允许接收方重组发送方的包序列,同时序列号也能用于决定适当的包位置,如在视频解码中,就不需要顺序解码。

4、RTCP(Real-time Transport Control Protocol,实时传输控制协议)

RTCP是RTP的配套协议,为RTP媒体流提供信道外的控制。RTCP和RTP一起协作将多媒体数据打包和发送,定期在多媒体流会话参与者之间传输控制数据。

RTCP的主要功能是为RTP所提供的服务质量(QoS)提供反馈,收集相关媒体连接的统计信息,例如传输字节数,传输分组数,丢失分组数,单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息来提高服务质量,比如限制流量或改用压缩比小的编解码器。

四、利益相关

我们团队是做直播技术的,底层架构都是做好的,开放给开发者sdk和api接口,开发者接入后就可以实现直播的功能。欢迎和我们交流学习。我的qq2479775187

这个知识的范围真的很大,涉及到编程功底、网络、流媒体、CDN、等等等等... 与其说知识不如说需要用到哪些技术,用这些开源的技术你可以在一周之内搭一个完整的网络视频直播系统。然后你再用这些技术反推你需要的知识,这样就不会导致学到没用的知识。

链接:
如何搭建一个完整的视频直播系统? - 网络主播

七牛云移动端推流开源SDK:
GitHub - pili-engineering/PLCameraStreamingKit: Pili RTMP Streaming SDK for iOS, H.264 and AAC hardware encoding supported. Camera and Microphone as input source.

完整的基于IOS手机直播:
GitHub - songsmith/LiveVideoCoreSDK

OBS-PC端主播推流工具,斗鱼等游戏直播都在用
GitHub - jp9000/obs-studio: OBS

RTMP直播可以用nginx-rtmp
GitHub - arut/nginx-rtmp-module: NGINX-based Media Streaming Server

开源播放器也很多,ffplay、jwplayer、ijkplayer等等,我就不一一给你发了,哈哈
其实最难的难点是提高首播时间、服务质量即Qos。要想在技术上把别的直播站PK下去,可以考虑这几种方案:
1. gop缓存,为加快首播时间
2. gop丢帧,为解决延时,为什么会有延时,网络抖动、网络拥塞导致的数据发送不出去,丢完之后所有的时间戳都要修改,切记要不客户端就会卡一个 gop的时间,是由于 dts 和 pts 的原因,或者播放器修正 dts 和 pts 也行(推流端丢gop更复杂,丢 p 帧之前的 p 帧会花屏)
3. 纯音频丢帧,要解决音视频不同步的问题,要让视频的 delta增量到你丢掉音频的delta之后,再发音频,要不就会音视频不同步  
4. 源站主备切换和断线重连
5. 根据TCP拥塞窗口做智能调度,当拥塞窗口过大说明节点服务质量不佳,需要切换节点和故障排查
6. 增加上行、下行带宽探测接口,当带宽不满足时降低视频质量,即降低码率
7. 定时获取最优的推流、拉流链路IP,尽可能保证提供最好的服务
8. 监控必须要,监控各个节点的Qos状态,来做整个平台的资源配置优化和调度
9. 如果你家产品从推流端、CDN、播放器都是自家的,保障 Qos 优势非常大.
10. 当直播量非常大时,要加入集群管理和调度,保障 Qos 对于做了腾讯视频多年的表示,如果要全国用户跨平台流畅观看,这个东西复杂到我已经很难在知乎上回答了;对于要简单的看了w3school然后用chrome写个hello world,可以apache搭个服务器,html5设置src就行了,不过这是点播,要模拟直播,把MP4转一个M3U8修改src过去就行了。 实在不行找团队,美丽播视频直播团队搜美丽播 如果是做直播平台,最难的是从摄像头(包括移动端、PC)推流到服务器这一段,各种bug太多了
从直播服务器分发到用户这一段,基本就是把流复制到CDN而已,包括多码流输出都是CDN做。能怎么样取决于CDN的良心
如果还要把视频保存下来,做后续处理。那就是另外一个问题了。 HTML5对直播支持很烂!所以在移动端主要使用APP实现,在PC端需要flash player。
所以HTML5的知识对直播毫无帮助。
假设你只是准备搭一套测试系统。你需要熟悉ffmpeg的使用,对http、HLS、RTMP协议有初步的了解,加上能用google的网络环境,一周之内能够拼凑出一个能用的系统。 这是看到的第N个某某怎么开发出来的问题,,, 没什么难度的东西,只要熟悉HTML5就够了。我认为一个熟悉HTML5的人大约7个工作日内就可以开发出来了。 ucloud能为你解决大部分事情 OK,虽然不是纯技术,这种问题强答一发,行家多多指正
1.编解码-视频相关,不解释
2.流媒体分发-CDN,运维
3.音视频采集
4.数据库
5.安卓和IOS的开发
6.UI
7.测试
H5可以实现直播的功能,但是效果不好,不推荐用H5,但如果在微信推广就得用H5做了。
或者你也可以直接找我们,反正我们有成熟的方案,联调一周即可上线~

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn