h265压缩比为1:200，h264压缩比为1:100，压缩一帧h265理论上比压缩一帧h264多10ms的时间。
以下数据均来自实测
在Intel® Core™ i7-6700 CPU @ 3.40GHz 4核8线程中：
用h265编码1080i50，uyvy422的裸数据，码率为6M，编码器速度配置ultrafast，线程配置8线程编码 top后id为2.5
值得注意的是crtl+c也是衡量cpu是否过载的方法之一。
记录编码一帧h265的视频帧用时，不同时间段随机多次采样为：
88ms,135ms,73ms,58ms,102ms
1080i50帧率为25帧每秒，每帧间隔是40ms，因此编码严重超时，满足不了帧率。cpu空闲了也用完了，性能已经到瓶颈了。更不可能编码帧率更高的视频了。
同样的环境配置，编码方式改为h264，测试如下：
11ms 28ms 29ms 32ms 30ms 40ms 34ms 19ms 35ms 26ms
id:50
可以看到跳动还是比较大的，偶尔也会超过40ms，比如记录到一个50ms的，但总体在30ms左右，不影响使用。
再改变一下，输入视频帧格式改为1080p60。
视频ctrl+c有延时
12ms 22ms 15ms 30ms 24ms 25ms 23ms 9ms 33ms 27ms
id:40
因此1080p60帧率为60，所以每帧间隔16.6ms，从测试来看，编码器编码一帧耗时太久，丢帧还是比较严重的。因此并不满足工业级生产开发。
再改变一下，输入视频格式改为1080i60，测试得：
ctrl+c有延时
41ms 33ms 36ms 20ms 40ms 18ms 25ms 32ms 46ms 38ms 22ms 19ms 43ms
id：50
1080i60帧率为30帧，每帧间隔33.33ms，因此从测试来看，依然丢帧严重。
再改变一下，输入视频格式改为1080i50，测试得：
ctrl+c无延时
正常不丢帧
id 55
再改变一下，输入视频格式改为1080i50，四路视频输入，同时编码，编码一个小时，分不同时间段采样，测试得：
id:25
25帧 25帧 25帧 25帧 25帧 25帧 25帧 25帧 25帧 25帧 25帧 25帧
可以看出这个配置编码四路1080i50不会丢帧，音频也无问题。
在Intel® Core™ i5-6300U CPU @2.40GHz 4核4线程中：
配置低于上面的i7。
用h264编码1080p60，uyvy422的裸数据，码率为6M，编码器速度配置ultrafast，线程配置4线程编码。
不同时段，三次采样分别丢
13帧，9帧，13帧
id:21
视频改为1080i50，无丢帧。
在Intel® Core™ i5-4460 CPU @ 3.20GHz 4核4线程中(台式机)：
用h264编码1080i50，uyvy422的裸数据，码率为6M，编码器速度配置ultrafast，线程配置4线程编码。测试无丢帧。
换成Intel® Core™ i5-4200U CPU @ 1.60GHz2核2线程，其他不变，测试一路h264编码id为40，编码一路h264视频粗略约为30ms，另一个电脑ffplay播放后音视频都没问题。因为代码编码使用的是多线程编码。
如果使用命令：
ffmpeg -re -stream_loop -1 -i westLife.mp4 -ar 44100 -acodec libfdk_aac -s 1920x1080 -pix_fmt yuv420p -preset ultrafast -vcodec h264 -f mpegts srt://192.168.100.78:8080?streamid=uplive.sls.com/live/test1
编码推流，发现id为2，播放推流的音频卡顿严重。
（srs是在上面i5-4200U运行的。但如果再运行一路./TestPattern，则id为16，另一个电脑ffplay后音频卡顿。四个线程负载id都在80左右，有时单个id97）。
此配置当只进行一路h264解码时，音频偶有卡顿，id为85。
