帧率

试想一下，当你和朋友进行视频时，这时突然画面卡住不动了，而且声音变得断断续续，是不是会感到特别的尴尬？为了避免这些情况，那么在直播app开发过程中，针对于延迟，在技术上能对哪些方面进行优化呢？下面拓幻科技就来简单介绍下。 一、编码优化 首先，确保Codec开启了最低延迟的设置。Codec一般都会有低延迟优化的开关，对于H.264来说其效果尤其明显。另外，编码器一般都会有码控造成的延迟，把它当成编码器和解码器比特流之间的缓存，在不影响视频质量的情况下，将其设置得尽可能小也可以降低延迟。还有，最好不要使用视频MJPEG的视频压缩格式，至少使用不带B帧的MPEG4视频压缩格式，最好使用H.264baseline profile这样一个简单的优化。这样一个简单的优化可以降低延迟，因为它能够以更低的码率编码全帧率视频。 二、传输协议优化 在服务端节点和节点之间尽量使用RTMP而非HLS协议进行传输，这样可以降低整体的传输延迟。如果终端用户使用RTMP来播放，尽量在靠近推流端的收流节点进行转码，这样传输的视频流要比原始视频流更小。此外，如果有必要，可以使用定制的 UDP 协议来替换 TCP 协议，省去弱网环节下的丢包重传可以降低延迟。 三、传输网络优化 在服务器节点中缓存当前GOP，配合播放端优化视频首开时间。还可以让服务端实时记录每个视频流流向每个环节时的秒级帧率和码率

现在开源的webgl引擎中，three.js是功能最丰富的，而且社区活跃，使用简单，但是它的性能确实不太理想。本系列就和大家一一探究three.js的性能到底如何，原因是什么，以及有什么改进方案。 首先我们模拟一个理论上性能最好的使用场景，scene下创建10000个sphere，每个sphere大概1000个顶点（测试显卡为mac Radeon Pro 555X 4 GB，相当于GTX1050左右） 代码如下： var geometry = new THREE.SphereBufferGeometry( 5, 32, 32 ); var material = new THREE.MeshBasicMaterial({transparent:false, color:new THREE.Color(1,0,0)}); for ( var i = 0; i < 8000; i ++ ) { var mesh = new THREE.Mesh( geometry, material ); mesh.position.x = Math.random() * 1600 - 800; mesh.position.y = 0; mesh.position.z = Math.random() * 1600 - 800; mesh.updateMatrix(); mesh

脚本的生命周期 代码 using System . Collections ; using System . Collections . Generic ; using UnityEngine ; public class NewBehaviourScript : MonoBehaviour { // 只会执行一次 无论脚本是否激活，都会被执行。前提是脚本所在对象必须是激活状态 private void Awake ( ) { Debug . Log ( "Awake" ) ; } // 脚本激活或者脚本所依附的对象被激活时执行 private void OnEnable ( ) { Debug . Log ( "OnEnable" ) ; } // 只会执行一次 且只能 在脚本处于激活状态或者脚本第一次被激活时执行 // Start is called before the first frame update void Start ( ) { Debug . Log ( "Start" ) ; } // 固定帧率刷新 不受游戏帧率影响，默认帧间隔为0.02s，可以在projectseting-Time-fixed timestep中设置 private void FixedUpdate ( ) { Debug . Log ( "FixedUpdate" ) ; } //

浏览github有意看到这个库： https://github.com/didi/DoraemonKit 涵盖以下功能，可以说非常方便： 一、常用工具 【App 信息查看】 快速查看手机信息，App 信息，权限信息的渠道，避免去手机设置查找或者查看项目源代码的麻烦； 【沙盒浏览】 App 内部文件浏览的功能，支持删除和预览, 并且能通过 AirDrop 或者其他分享方式上传到 PC 中，进行更加细致的操作； 【MockGPS】 App 能定位到全国各地，支持地图地位和手动输入经纬度； 【H5任意门】 开发测试同学可以快速输入 H5 页面地址，查看该页面效果； 【Crash查看】 方便本地打印出出现 Crash 的堆栈； 【子线程UI】 快速定位哪一些 UI 操作在非主线程中进行渲染，避免不必要的问题；（iOS独有） 【清除本地数据】 一键删除沙盒中所有数据； 【NSLog】 把所有 NSLog 信息打印到UI界面，避免没有开发证书无法调试的尴尬； 【Lumberjack】 每一条 CocoaLumberjack 的日志信息，都在在 App 的界面中显示出来，再也不需要导出日志这么麻烦;（iOS独有） 【DBView】 通过网页方便快捷的操作应用内数据库，让数据库的调试变得非常优雅; 【模拟弱网】 限制网速，模拟弱网环境下App的运行情况。（android独有） 二、性能检测 【帧率

像素 PIXEL 图片的基本单位 像素非常小 图片是成千上万的像素组成 显示/屏幕分辨率 （DPI 屏幕分辨率） 图像分辨率 （PPI） 1920*1080是像素点长度1920个像素点 X1080个像素点 分辨率： 帧：1秒60帧 【转】分辨率、帧率和码率三者之间的关系 原贴地址：https://blog.csdn.net/lipengshiwo/article/details/53169235 帧率：FPS（每秒钟要多少帧画面）； 以及Gop（表示多少秒一个I帧） 码率：编码器每秒编出的数据大小，单位是kbps，比如800kbps代表编码器每秒产生800kb（或100KB）的数据。 分辨率：单位英寸中所包含的像素点数； VGA：Video Graphics Array（视频图像分辨率） 三者的对应直播质量的影响因素： 帧率：影响画面流畅度，与画面流畅度成正比：帧率越大，画面越流畅；帧率越小，画面越有跳动感。如果码率为变量，则帧率也会影响体积，帧率越高，每秒钟经过的画面越多，需要的码率也越高，体积也越大。帧率就是在1秒钟时间里传输的图片的帧数，也可以理解为图形处理器每秒钟能够刷新几次。 分辨率：影响图像大小，与图像大小成正比：分辨率越高，图像越大；分辨率越低，图像越小。 清晰度 在码率一定的情况下，分辨率与清晰度成反比关系：分辨率越高，图像越不清晰，分辨率越低，图像越清晰。

soloπ 可测试专项包括 app界面自动化 性能 cpu、内存、响应耗时、帧率、游戏帧率、电池电量、网络流量 同时执行多个设备的兼容性测试 1.初次使用 a. https://github.com/alipay/SoloPi/releases 下载apk包 安装 b. 需要开启安卓设备的设置 -> 开发者选项 ->USB调试功能 c. 准备adb环境 手机连接电脑 d. Soloπ依赖设备远程adb来执行设备操作与待测应用信息获取，所以需要在每次设备重启后连接电脑并执行adb tcpip 5555来开启设备远程adb调试端口。 e. 启动 所有权限申请 都给权限 2.录制回放 录制 a.点击启动按钮后，Soloπ会弹出操作悬浮窗，并自动跳转到被测应用的首页 b. 在悬浮窗中点击开始按钮，进入录制状态 c. 录制过程中，Soloπ会对用户的操作进行拦截，高亮当前点击的控件，并弹出操作选择框，如果显示的红框与期望操作的控件不符，可以考虑切换到H5增强模式进行查找。 回放 a.在Soloπ录制回放页面中，点击下方的查看全部按钮，可以查看到本地所有的用例 b. 在全部用例列表中，点击列表中任意一条case，Soloπ会打开被测应用，并进入准备回放状态。 c. 用例回放过程中，Soloπ会高亮待操作控件 d. 回放结束后，Soloπ会展示回放的相关内容 用例列表 a.

随着美团点评业务越来越多，研发团队越来越庞大，对测试手机的需求显著增长。这对公司来说是一笔不小的开支，但现有测试手机资源分配不均，利用率也非常有限，导致各个团队开发、测试过程中都很难做到多机型覆盖。怎么样合理、高效利用这些测试手机资源，是摆在我们面前的一道难题。 为了解决这些问题，业内也出现了一些手机管理和在线调试使用的工具或平台，比较常见的有: * OpenSTF * 百度MTC的远程真机调试 * Testin的云真机 * 腾讯WeTest的云真机 * 阿里MQC的远程真机租用 其中OpenSTF是开源项目，其他的平台大多也都是基于OpenSTF原理实现的。因此，我们对OpenSTF项目进行了深入研究。 我们首先按照OpenSTF官方的方案进行了搭建，并进行了小规模的应用，但渐渐的我们发现了它的一些问题： * 模块过多而且耦合紧密，解耦难度较大，每次修改需要更新所有模块，难以快速迭代开发。 部分技术选型落后。由于OpenSTF出现的时间比较早，部分技术已经落后于目前的主流。例如OpenSTF前端选用AngularJS 1.0进行开发，在生态链方面已经落后于其他流行的框架；数据库方面选用非关系型数据库RethinkDB，在数据计算和性能方面弱于MySQL等关系型数据库，同时RethinkDB资料较少，不便于开发与维护。 OpenSTF屏幕图像传输采用图片单张传输的方式进行

目前总结出webrtc用于提升QOS的方法有： 1、NACK 2、FEC 3、PACER 4、降帧率 5、降码率 也许还有其他，待后续知识更新后，补充。 一、NACK原理介绍 接收端根据收到报文的丢包情况，把丢包的SEQ记录在RTCP报文里面，发给发送端，请求重发。 若在JB时长内，收到重发数据，就补上了。 二、FEC原理介绍 FEC是发送端在发送的时候，将之前的旧包也打包到新包里面，若接收端有丢包，就用新包里面冗余的旧包恢复数据。 说到这里大家可能认为这就是RFC2198冗余嘛。但是在webrtc里面，这不是简单的RFC2198冗余。 RFC2198冗余带宽占有量是倍增，简单冗余，对网络差的情况是恶化。FEC是有一套算法，仅冗余部分关键帧。 三、PACER原理介绍 PACER，是网络报文平滑策略。根据RTCP反馈的环路延时和丢包，对当前网络有个预判。然后把要发送的报文拆分成小包，按照一定的节奏慢慢发。 四、降帧率原理介绍 降帧率也是根据RTCP反馈的环路延时和丢包，对当前网络有个预判。当判断出当前网络质量比较差，通过不断的降低帧率，减少带宽的占用量。 五、降码率原理介绍 同理，降码率同样是根据RTCP反馈的环路延时和丢包，对当前网络有个预判。当判断出当前网络质量比较差，通过不断的降低码率，减少带宽的占用量。 这五种方法实现的细节，待续。。。。。 文章来源: webrtc

一、视频分辨率码率初始配置 1、分辨率默认值 webrtc\pc\videocapturertracksource.cc 选取的原则是，在kVideoFormats里面找参数与kDefaultFormat默认值最接近的一组参数，作为本端的编码能力。 2、码率默认值 webrtc\media\engine\webrtcvideoengine.cc 3、默认QP、帧率最大值配置 webrtc\media\engine\webrtcvideoengine.cc static const int kDefaultQpMax = 56; const int kDefaultVideoMaxFramerate = 60; 二、生效新的帧率码率流程 在webrtc里面函数实现如下： ->VideoStreamEncoder::EncodeVideoFrame ->VideoSender::AddVideoFrame----在这个函数中读取全局变量encoder_params_，判断是否需要调整视频参数。 ->VideoSender::SetEncoderParameters ->VCMGenericEncoder::SetEncoderParameters ->H264EncoderImpl::SetRateAllocation---传递新的帧率码率到编码器。 文章来源:

视频压缩基本概念 首先回答why这个问题。 假设一个2小时未压缩的高清视频，1920×1080p的电影，我们来计算一下他的存储容量。先介绍一下 帧率 (frame rate或者是 FPS)概念，也就是每秒传输图片的帧数，也可以理解为图形处理器每秒能够刷新几次。由于人眼的特性-视觉暂留，帧率要在20以上才会感觉流畅。之前的电影帧率一般是24。 拓展：为什么游戏帧数要60才流畅，而电影只需要24 2小时×60分钟×60秒×25 帧率×1920×1080 像素 ×3/2 每像素字节数 = 5599GB 一部高清电影占了这么大空间，不能忍。 所以，为了存储和传输方便，压缩视频，必不可少。 接下来回答怎么进行视频压缩。 介绍最基本的概念： 信息压缩是通过去除资料中的冗余信息而达成。就视频而言，冗余信息可以分成四类： 时间上的冗余信息（temporal redundancy） 在视频中，相邻的帧（frame）与帧之间通常有很强的关连性，这样的关连性即为时间上的冗余信息。这即是上一次学习中的帧间压缩。连续的图像往往非常相近，由于一些小运动造成了细小差别。这种减小冗余的方法可以存储和上一帧或者下一帧不同的地方。这样就可以减少存储了。这个过程就称作运动补偿。位移是利用运动向量得出的。 空间上的冗余信息（spatial redundancy） 在同一张帧之中，相邻的像素之间通常有很强的关连性