移动端互动直播(入门篇)

本文来自网易云社区

前言

本文为手机视频直播开发新手,为了快速入门,利用强大google搜索引擎结合自身理解而整理的"视频直播入门背景知识"。

背景知识

名词解释

推流协议

RTMP

Real Time Messaging Protocol（实时消息传送协议）

 

使用 Flash Player 做为播放器客户端，而Flash Player 如今已经安装在了全世界将近99%的PC上，所以通常状况下收看RTMP流媒体系统的视音频是不须要安装插件的。用户只须要打开网页，就能够直接收看流媒体，十分方便

 

1. 工做在TCP之上的明文协议，使用端口1935；

2. RTMPT封装在HTTP请求之中，可穿越防火墙；

3. RTMPS相似RTMPT，但使用的是HTTPS链接；

 

HLS

HTTP Live Streaming

 

HLS 是苹果公司QuickTime X和iPhone软件系统的一部分。它的工做原理是把整个流分红一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端能够选择从许多不一样的备用源中以不一样的速率下载一样的资源，容许流媒体会话适应不一样的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U (m3u8) playlist文件，用于寻找可用的媒体流。

 

客户端支持

 

• iOS从3.0开始成为标准功能。

• Adobe Flash Player从11.0开始支持HLS。

• Google的Android自Honeycomb（3.0）开始支持HLS。

• VODOBOX HLS Player (Android,iOS, Adobe Flash Player)

• JWPlayer (Adobe Flash)

• Flowplayer (Adobe Flash,使用hlsjs版本不使用Adobe Flash)

• Windows 10 的 EDGE 浏览器开始支持HLS。

 

H264编码

H264是一种高压缩率的编码标准，如何压缩嘞？通常的视频采集都是25帧/秒，也就是每秒截图25次，其实每一张图片的内容都相差不大，压缩的办法就是利用算法，只将每张图片变更差别化的部分保存下来，这样视频文件就小多了

 

MKV

俄文матроска是матрёшка（俄罗斯套娃）的误读，由于Matroska的工做原理就跟层层套叠的俄罗斯娃娃同样，是“愈包愈紧”的，故得名。而mkv只是Matroska媒体系列的其中一种文件格式。

 

相关术语

 

YUV

YUV主要用于优化彩色视频信号的传输，使其向后相容老式黑白电视。与RGB视频信号传输相比，它最大的优势在于只需占用极少的频宽

 

PCM

脉冲编码调制(PCM)就是把一个时间连续，取值连续的模拟信号变换成时间离散，取值离散的数字信号后在信道中传输。脉冲编码调制就是对模拟信号先抽样，再对样值幅度量化，编码的过程

 

muxer

muxer是指合并文件，即将视频文件、音频文件和字幕文件合并为某一个视频格式。好比把rmvb格式的视频，mp3格式的音频文件以及srt格式的字幕文件，合并成为一个新的mp4或者mkv格式的文件。

demuxer

demuxer是muxer的逆过程，就是把合成的文件中提取出不一样的格式文件。

总体架构

架构图

 

 

角色职能

 

App端推流

 

 

音频采集模型

 

优化策略

服务质量策略

推流端会根据当前上行网络状况控制音视频数据发包和编码，在网络较差的状况下，音视频数据发送不出去，形成数据滞留在本地，这时，会停掉编码器防止发送数据进一步滞留，同时会根据网络状况选择合适的策略控制音视频发送。

 

好比网络不好的状况下，推流端会优先发送音频数据，保证用户能听到声音，并在必定间隔内发关键帧数据，保证用户在必定时间间隔以后能看到一些画面的变化。

 

配置关键帧

合理控制关键帧发送间隔（建议2秒或1秒一个），这样能够减小后端处理过程，为后端的缓冲区设置更小创造条件。

 

云端服务器

总体结构

 

服务协议

SRS

• 开源

• 1.架构简洁，功能强大
  2.主要支持rtmp协议
  3.集群支持

 

CRTMP

• 开源

• 1.c++开发
  2.支持协议丰富
  3.对集群支持不够好

 

nginx—rtmp

• 开源

• 1.全异步模型实现，性能优点
  2.稳定性不足

 

Red5

• 开源

• 1.纯java
  2.性能不足

 

FMS

• 不开源

• 1.adobe流媒体服务器
  2.性能和功能都不错

   

视频直播转码功能问题

录制，直播转码，鉴黄，截图，分发。

 

视频直播播流端的码率是根据推流端决定的，即播流端的码率是与推流端的码率一致的。可是遇到如下场景会形成直播效果较差：

 

• 推流端码率与播流端带宽不相匹配。当推流端码率较高而客户端带宽资源有限就会致使播放出现卡顿，而当推流端码率较低可是客户端对于直播效率要求较高时会致使播放效果较差。

• 播放器插件须要实现多码率切换。前端播放器插件常能够设置码率切换，这就须要同一路推流能够同时提供多种码率的播流地址。

 

所以，视频直播提供了实时转码功能对同一路推流地址同时提供多路不一样码率播流地址提供服务。

App端拉流

 

 

编码策略

推流编码-硬

推荐Andorid4.3（API18）或以上使用硬编，如下版本使用软编；iOS使用全硬编方案；

 

拉流编码-软

Andorid、iOS播放器都使用软解码方案，通过咱们和大量客户的测试以及总结，虽然牺牲了功耗，可是在部分细节方面表现会较优，且可控性强，兼容性也强，出错状况少，推荐使用。

 

优缺点

软编/解码

• 优势

1. 兼容性强

2. 色彩比硬编码强

3. 编码课操做空间大，自由度高

• 缺点

1. 吃cpu，消耗比较大

 

硬编/解码

• 优势

1. 功耗低，执行效率高

• 缺点

1. 芯片的差别性

2. 可控性比较低

特点功能

互动白板

数据封装

 

布局结构

 

弹幕

布局结构

DanmakuFlameMaster弹幕实现

参考资料

• 开源框架 RTMP live streaming client for Android https://github.com/begeekmyfriend/yasea

• 直播架构图 https://netease.im/edu

• RTMP协议介绍 https://en.wikipedia.org/wiki/Real-Time_Messaging_Protocol

• 音频处理队列 https://developer.apple.com/library/content/documentation/MusicAudio/Conceptual/AudioQueueProgrammingGuide/AboutAudioQueues/AboutAudioQueues.html#//apple_ref/doc/uid/TP40005343-CH5-SW1

• 视频直播技术原理和方案参考 https://github.com/f2e-journey/xueqianban/issues/61

 

 

 

网易云新用户大礼包：https://www.163yun.com/gift

 

本文来自网易云社区，经做者金剑受权发布