音视频技术小分享

共 1896字,需浏览 4分钟

 ·

2022-02-09 17:35

直播技术剖析

直播流程

直播流程: 录制->编码->网络传输->解码->播放 (中间还会有转码的过程,转成不同分辨率的流)


Ucloud 直播技术分享连载:blog.ucloud.cn/archives

  1. 网络接入部分,实现对用户位置的判断。(通过用户访问的dns进行判断用户所在的网络地址)
  2. 视频传输协议的选择
  3. 缓存策略
  • I帧(important)表示关键帧。你可以理解为这一帧画面的完整保留;解码时只需要本帧数据就可以完成。(因为包含完整画面) GOP表示 多少秒一个I帧
  • P帧表示这一帧跟之前的一个关键帧(或P帧)的差别。解码时需要用之前缓存的画面叠加上本帧定义的差别,生成最终画面。(也就是差别帧,P帧没有完整画面数据,只有与前一帧的画面差别的数据)
  • B帧是双向差别帧。**B帧记录的是本帧与前后帧的差别(具体比较复杂,有4种情况)。换言之,要解码B帧,不仅要取得之前的缓存画面,还要解码之后的画面,通过前后画面的与本帧数据的叠加取得最终的画面。


视频流知识


视频质量概念

音视频计划博客juejin.im/entry/59422a0

  1. 码率
编码器每秒编出的数据大小,一般单位是kbps,比如800kbps代表编码器每秒产生800kb(或100KB)的数据。
基本的算法是:【码率】(kbps)=【文件大小】x8 x 1024/【时间】(秒)

CBR(Constant BitRate)

固定码率。

VBR(Variable BitRate)

动态码率,目前obs开播基本为动态码率


  1. 帧率
FPS(每秒钟要多少帧画面); 以及Gop(表示多少秒一个I帧) ,人体帧率24 FPS已经看不出区别
帧率×分辨率=压缩前的每秒数据量(这里可以算出一个字节大小)

压缩比=压缩前的每秒数据量/码率

  • 码率影响体积,与体积成正比:码率越大,体积越大;码率越小,体积越小。
  • 帧率影响画面流畅度,与画面流畅度成正比:帧率越大,画面越流畅;帧率越小,画面越有跳动感。如果码率为变量,则帧率也会影响体积,帧率越高,每秒钟经过的画面越多,需要的码率也越高,体积也越大。
  • 分辨率影响图像大小,与图像大小成正比:分辨率越高,图像越大;分辨率越低,图像越小。

简单的比喻: 码率是自来水管的谁呀,分辨率720p/1080p就是水管网的直径,分辨率可能就是自来水龙头的粗细。最重要的是水源地的水源是否充足,即视频的源头信息是否满足

FPS: 每秒钟要多少帧画面

视频码率规格建议:




视频流协议

常见的视频流协议有 RTMP、HTTP-FLV、HLS

考虑三种协议的时延以及适用场景

详细解析:jianshu.com/p/4c89b2c83

  • 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站针对这个情况 推出了 : github.com/Bilibili/flv


H264 编码格式

refer to :juejin.im/entry/5833dc8

优秀的编码技术能够实现 以更低的码率传递更优质的视频流。

核心技术: 一张图片经H.264编码器之后,被编码成一个或者多个片

浏览 5
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报