随便说点音视频相关的小姿势

来随便讲讲 av 吧.

av 就是 audio&video

这里用直播做栗子吧

走一波

采样都知道吧?(不知道自己去百度查啊)

声音信号,图像信号都是模拟信号,就是连续信号

但是我们手机啥的现在都是数字信号,也就是离散信号

所以要采样

比如一个周期的正弦波

正弦波最少采样2个点就能完整的恢复这个波形

先讲点 非常浅显的有意思的

知道人能听到的声音范围 大概是多少吧

人能听到的声音频率大概是20 ~ 20khz

知道为啥 一般mp3 采样率都是44k吗?

一个周期采样2个点就能完全恢复这个信号

20*2  = 40

算上冗余

44k 就能基本绝大部分的还原声音了

直播中用的语音编码很多种

就是 考虑到有的人听力敏锐

能听到20khz 以上的

一般都是AAC

aac 这个编码格式  根mp3 相比  压缩率高 还原度高

在这再讲一个有意思的

我要告诉你们 打电话 听对面放歌  你是听不很清楚的

电话 语音的采样率是8k 跟44k 相差甚远

为的就是降低数据流量

理论上来讲 

8k 采样率能比44k 降低5倍的流量

8k 的采样率 最多只能 采集模拟信号 4k 左右的

人说话 大概的范围就是20到 44k, 20hz 已经是听力下限了

就是咱们听音乐 重低音啥的

低音就是频率低高音就是 频率高

超声波 为啥我们听不到?

因为已经超过20khz的范围了

以早起电话交换语音格式 用的g729

8k 16位采样率的情况下

1秒才1k左右的数据

1分钟才60k

1小时才 3.6M

(什么叫十六位采样率? 

就是 一个采样 我量化成2个字节 也就是2*8 = 16位

2字节 是2的16次方(65536)

也就是 1个信号  我能量化成65536个不同的程度

越精细,声音越逼真

但是到一定程度,再精细 人耳就听不出来了

采样率用于表示信号幅度

)

再说一句,你打电话跟你听音乐完全两个概念

再说现在的直播系统

为啥不用电话的那种语音格式?

因为有音乐啊 。。。

音乐可是超出8k 采样率范围的

所以 如果用8k 采样率,音乐就会惨不忍听

所以wszcug 大佬前年高webrtc 那会

很多人问wszcug大佬 能不能做直播

wszcug大佬说不能

问的人说为啥

wszcug大佬说 webrtc 到哪个时候为止 还没有高于16k 采样率的编码格式

(webrtc是实时视频通话)

记住 直播系统是伪实时

webrtc 这种真实时  可以做到 延迟500ms 以内

直播用aac 原因很简单

首先采样能满足

其次跟mp3 比,压缩率搞

再次 不收版权费

ok 前提讲了个差不多   进入正题

采集同样一段 声音

96k 比44k 高一倍的大小

但是呢

因为人的主观因素

听觉方面并不能提升一倍

甚至只能提升一点点

所以 高一倍的容量没必要

96k 听音乐比44k 要亮一些  

对相同一段音乐来讲是这样

所以最终方案就是采用了aac

那么再讲讲视频

视频的道理其实跟音频一样

同样是模拟信号采样成数字信号

苹果现在可以用sdk 直接采集

采样的元数据非常大

采样的元数据非常的大

采样的元数据非常非常的大

肯定要做压缩对吧?

在压缩之前 咱先来个美颜

这就到了GPUImage

他对这些采样数据 做gpu运算

具体什么算法很多种

双边铝箔 单边绿波啥啥啥的

这处理完全用的gpu

不占用cpu

处理之后的数据 gpu 给转化成rbga32

这个数据也很大

现来说说这个名字 rgba32

r 就是red 分量  g 就是green 分量 b blue  a alpha

一个分量占1个字节 也就是256

还记得这个代码不

[UIColor colorWithRed:219.f/255.f green:220.f/255.f blue:221.f/255.f alpha:1];

就是这个玩意儿

32 就是4*8 = 32 32位量化深度

以前非智能机的时候

几千万色 记得没?

就是说色彩量化深度

有2位色  就是黑白

8位色 16位色 

现在真彩色 32位色

影响的是你屏幕的还原度

比如黑白电视机 和彩色电视机

黑白电视机就是1位量化深度

就是0 1

0 就是黑 1 就是白

彩色电视机 32位量化

可以显示理论上 2的32次方中颜色

这就是几千万色的由来

2的32次方  大概就是6000多万

以前诺基亚有一款手机 

真色彩 6400 还是6500万色

就说的颜色深度

ok 转化成rgba 之后

也要看压缩算法

凡事有损压缩 肯定要 有所损失

成rbga 之后 下面就该压缩了对吧

现在有两种压缩 一种硬件压缩 一种软件压缩

硬件压缩都知道 苹果自带了

软压缩 就是 ffmpeg(不熟悉的百度一下)

硬压缩好处是 速度快 因为gpu 专门干这个

软压缩就是把gpu 干的活让cpu 来干

现在主流的压缩格式 是h264 或者 vp8

相比较而言

h264 适合动态压缩  vp8 适合静态

但是 图像哪能不动对吧 所以h264 要好一些

现在可以说 主流是硬压缩  (我说ios 上)

至于vp8 是啥 这是谷歌的视频压缩算法

最新的 h265 更牛逼

当然 运算量更大 专利费也更贵

所以现在使用h264肯定主流

h264 压缩算法 我看过

现在的h264 是不需要专利费的

h265 现在还不太适合用在移动端

运算量达不到

总之吧  现在都是h264,反正我没见过用vp8

包括苹果压缩都是264

至于你们说的 什么rm 啊  什么 mk 啊

这些  就是文件后缀

或者什么mp4啊

有人说这是格式

严格来讲不对

这是封装 不是格式

格式都是h264

这些里面装的都是h264

只是封装格式不同

h264 裸流 要经过封装之后才能给播放器识别

封装格式针对的是视频

裸流 就是没有封装格式的二进制流

(m3u8 这是切片

切片用的hls 协议

跟我们现在说的直播rtmp 协议不一样

hls 延迟很高

rtmp 理想状态是3秒不到

如果cdn 给力  1秒也不是不可能

his 不行

)

举个栗子

你现在在北京

然后服务器也在北京

你上传的图像 很快能到服务器上

但是广东的用户 拉流很慢

怎么办?那就在广东布一台服务器

让北京服务器直接跟广东服务器专线通信

专线的速度你懂的

这就相当于广东用户直接拉流北京的东西

然后 不管软编码 还是硬编码  最后出来的都是h264裸流

而且是经过美颜的对吧

这 时候 就要做封装了

(为啥要做封装?

封装的意义

就在于要把声音和图像同步

)

这个封装就是把声音和图像同步

现在简单的同步就是 记录时间戳

用时间戳同步

有时候你们看电影

会有音画不同步的问题

那就是没封装好

同步就是根据时间戳来

(

我以前用手机看电影,一开始是同步的,看着看着就不同步了

那是累积偏差 

越来越大 越来越大

然后没有修正

就这样

)

(软编码跟硬编码什么区别啊?

硬 是gpu来做从结果来看没区别

软编码是cpu 来做

gpu 能干的cpu 都能干

反过来不行

)

封装之后就是flv 

flv 就相当于mp4

或者mk

就是个封装格式

之所以采用flv 原因很简单

兼容浏览器

浏览器的flash 可以无缝兼容flv

另外由于这个封装相对简单

所以就采用了flv

然后封装之后就要开始推流了

推流使用的是rtmp协议 这个是机遇tcp可靠传输协议

为啥用tcp呢?

为啥不用upd?

因为upd 不可靠传输!

容易丢包

丢包之后可能花屏

所以你们看直播

很少看到有花瓶的

你们去用微信视频呢

很容易花屏

因为微信用的upd 协议

而直播用的tcp

直播基本上都是tcp

现在有最新的据说upd 重传(upd本身不支持重传)

但是我只是听说 没见过

客户端推流可能会有阻塞

因为网络差

我采集端一致在采集

推流是主播到服务器

服务器到客户是拉流

另外推流还有缓冲期

缓冲区的作用就是作为一个平滑过渡

举个栗子

比如某一瞬间

网络很不好

流推不出去

咋办? 不能扔了不要把?

扔了不要 观众那边就看不到了

那就先放进缓冲区

等网络好了我再推出去

但是如果 网络不好的时间很长 ,缓冲区都满了

咋办?

观众那边就会看到阿花刚刚正在脱衣服,就快到关键时刻了

下一个画面看到的是阿花衣服已经穿好了

多他妈扫兴

缓冲区时间不能过大也不能过小

过大,观众那边迟迟看不到画面

过小  起不到缓冲的作用

缓冲区一般又个1~2秒的数据容量就差不多

音频编解码上又个Jitterbuffer

起的作用其实跟视频的缓冲区其实是一样的

那就是拉流的过程了

流到了服务器之后

客户端现在一般现成的 比如ijkplayer 拉流

这个过程相对 推流简单很多 就不废话了

就是一个反向过程

不需要客户端做啥处理 直接丢包给播放器播放就行了

这是整个直播系统大概的流程

理论上来讲 美颜是去不掉的

这是直播系统。当然 还有 实时音视频系统 

比如webrtc。。。。这个。。。。暂时不讲

采样 美颜 编码 封装 推流 拉流 解封装 解码 播放

那是必然的

在服务器端做美颜也是可以的

不过需要服务器先解码,解码成采样数据之后 美颜,美颜完成之后再编码 这样

美颜只能对采样数据进行

对编码之后的数据不行

总之这就是 直播系统了

说来过程其实并不复杂

还有一种 就是 微信的实施语音视频聊天

这种,并不属于直播

因为是ugp.

cpu 比你想象的快的多

现在直播项目都不是什么特别难的技术了

技术难点在于服务端的并发

难的比如还是音视频这块

实时的语音视频

p2p

服务端做不好 客户端没卵用

实时音视频

我刚说了  直播延迟 3秒

webrtc 可以做到300ms 之内(常人极限反应50ms)

类似 qq视频  微信视频

qq早期买的Global IP Solutions技术

webrtc 使用rtc 协议 实际上就是udp 协议的封装

rtp协议

rtp rtcp协议 

不讲这个 

这个太复杂

wszcug 大佬都弄了三年

这里面非常多好的 音频压缩算法

就不说了(我也不会)

最后送大家一句 wszcug 大佬的话

其实 技术永无止境

你可能感兴趣的:(随便说点音视频相关的小姿势)