音视频技术小分享
共 1896字,需浏览 4分钟
·
2022-02-09 17:35
直播技术剖析
直播流程
直播流程: 录制->编码->网络传输->解码->播放 (中间还会有转码的过程,转成不同分辨率的流)
Ucloud 直播技术分享连载:http://blog.ucloud.cn/archives/694
- 网络接入部分,实现对用户位置的判断。(通过用户访问的dns进行判断用户所在的网络地址)
- 视频传输协议的选择
- 缓存策略
- I帧(important)表示关键帧。你可以理解为这一帧画面的完整保留;解码时只需要本帧数据就可以完成。(因为包含完整画面) GOP表示 多少秒一个I帧
- P帧表示这一帧跟之前的一个关键帧(或P帧)的差别。解码时需要用之前缓存的画面叠加上本帧定义的差别,生成最终画面。(也就是差别帧,P帧没有完整画面数据,只有与前一帧的画面差别的数据)
- B帧是双向差别帧。**B帧记录的是本帧与前后帧的差别(具体比较复杂,有4种情况)。换言之,要解码B帧,不仅要取得之前的缓存画面,还要解码之后的画面,通过前后画面的与本帧数据的叠加取得最终的画面。
视频流知识
视频质量概念
音视频计划博客 : https://juejin.im/entry/59422a015c497d006bc15b1d
- 码率
编码器每秒编出的数据大小,一般单位是kbps,比如800kbps代表编码器每秒产生800kb(或100KB)的数据。
基本的算法是:【码率】(kbps)=【文件大小】x8 x 1024/【时间】(秒)
CBR(Constant BitRate)
固定码率。
VBR(Variable BitRate)
动态码率,目前obs开播基本为动态码率
- 帧率
FPS(每秒钟要多少帧画面); 以及Gop(表示多少秒一个I帧) ,人体帧率24 FPS已经看不出区别
帧率×分辨率=压缩前的每秒数据量(这里可以算出一个字节大小)
压缩比=压缩前的每秒数据量/码率
- 码率影响体积,与体积成正比:码率越大,体积越大;码率越小,体积越小。
- 帧率影响画面流畅度,与画面流畅度成正比:帧率越大,画面越流畅;帧率越小,画面越有跳动感。如果码率为变量,则帧率也会影响体积,帧率越高,每秒钟经过的画面越多,需要的码率也越高,体积也越大。
- 分辨率影响图像大小,与图像大小成正比:分辨率越高,图像越大;分辨率越低,图像越小。
简单的比喻: 码率是自来水管的谁呀,分辨率720p/1080p就是水管网的直径,分辨率可能就是自来水龙头的粗细。最重要的是水源地的水源是否充足,即视频的源头信息是否满足
FPS: 每秒钟要多少帧画面
视频码率规格建议:
视频流协议
常见的视频流协议有 RTMP、HTTP-FLV、HLS
考虑三种协议的时延以及适用场景
详细解析:https://www.jianshu.com/p/4c89b2c83e59
- RTMP 工作于TCP上的应用层协议,默认为1935端口
RTMP协议比较全能,既可以用来推送又可以用来直播,其核心理念是将大块的视频帧和音频帧“剁碎”,然后以小数据包的形式在互联网上进行传输,而且支持加密,因此隐私性相对比较理想,但拆包组包的过程比较复杂,所以在海量并发时也容易出现一些不可预期的稳定性问题。 - FLV HTTP-FLV
HTTP-FLV协议由Adobe公司主推,格式极其简单,只是在大块的视频帧和音视频头部加入一些标记头信息,由于这种极致的简洁,在延迟表现和大规模并发方面都很成熟。唯一的不足就是在手机浏览器上的支持非常有限,但是用作手机端APP直播协议却异常合适,延迟低 - HLS
HLS协议:苹果推出的解决方案,将视频分成5-10秒的视频小分片,然后用m3u8索引表进行管理,由于客户端下载到的视频都是5-10秒的完整数据,故视频的流畅性很好,但也同样引入了很大的延迟(HLS的一般延迟在10-30s左右)。相比于FLV, HLS在iPhone和大部分android手机浏览器上的支持非常给力,所以常用于QQ和微信朋友圈的URL分享
适用于赛事等情况
H5 原生仅支持 mp4/webm, 不支持flv,但是flash支持flv却资源开销巨大
所以b站针对这个情况 推出了 : https://github.com/Bilibili/flv.js/
H264 编码格式
refer to :https://juejin.im/entry/5833dc86570c35006c22cfb1
优秀的编码技术能够实现 以更低的码率传递更优质的视频流。
核心技术: 一张图片经H.264编码器之后,被编码成一个或者多个片
评论