云数据库 TencentDB
互联网中间件
域名与网站
开发者工具
云智AI应用服务
云智AI平台服务
云智大数据基础服务
云智大数据可视化服务
云智大数据应用服务
行业解决方案
大数据与AI解决方案
物联网解决方案
安全与运维解决方案
微信解决方案
微信小程序
服务与培训
视频卡顿怎么办
视频卡顿怎么办
1. 为什么会卡顿卡顿的原因无外乎三种情况：
原因 1：帧率太低如果主播端手机性能较差，或者有很占 CPU 的后台程序在运行，可能导致视频的帧率太低。正常情况下每秒 15FPS 以上的视频流才能保证观看的流畅度，如果 FPS 低于 10 帧，可以判定为帧率太低，这会导致全部观众的观看体验都很卡顿。
原因 2：上传阻塞主播的手机在推流时会源源不断地产生音视频数据，但如果手机的上传网速太小，那么产生的音视频数据都会被堆积在主播的手机里传不出去，上传阻塞会导致全部观众的观看体验都很卡顿。国内运营商 提供的宽带上网套餐中，下载网速虽然已经达到了 10Mbps， 20Mbps 甚至是 100Mbps，但上传网速却还一直限制的比较小，很多小城市的上行网速最快是 512Kbps（也就是每秒最多上传 64KB 的数据）。Wi-Fi 上网 遵循 IEEE 802.11 规定的载波多路侦听和冲突避免标准，简言之就是一个 Wi-Fi 热点同时只能跟一个手机通讯，其它手机在跟热点通讯前都要先探测或询问自己是否能够通讯，所以一个 Wi-Fi 热点使用的人越多就越慢。同时 Wi-Fi 信号受建筑墙体的屏蔽干扰很厉害，而一般的中国普通家庭很少在装修时考虑好 Wi-Fi 路由器和各个房间的信号衰减问题，可能主播本人也不清楚自己做直播的房间离家里的路由器究竟穿了几堵墙。
原因 3：下行不佳就是观众的下载带宽跟不上或者网络很波动，比如直播流的码率是 1Mbps 的，也就是每秒钟有 1M 比特的数据流要下载下来，但如果观众端的带宽不够，就会导致观众端体验非常卡顿。 下行不佳只会影响当前网络环境下的观众。
2. 发现问题的“眼睛”推流 SDK 提供了一种状态反馈机制，每隔 1-2 秒就会将内部各种状态参数反馈出来，我们可以通过注册TXLivePushListener 监听器来获取这些状态。
NET_STATUS_CPU_USAGE
当前进程的 CPU 使用率和本机总体的 CPU 使用率
NET_STATUS_VIDEO_FPS
当前视频帧率，也就是视频编码器每条生产了多少帧画面
NET_STATUS_NET_SPEED
当前的发送速度（单位：kbps）
NET_STATUS_VIDEO_BITRATE
当前视频编码器输出的比特率，也就是编码器每秒生产了多少视频数据，单位： kbps
NET_STATUS_AUDIO_BITRATE
当前音频编码器输出的比特率，也就是编码器每秒生产了多少音频数据，单位： kbps
NET_STATUS_CACHE_SIZE
音视频数据堆积情况，这个数字超过个位数，即说明当前上行带宽不足以消费掉已经生产的音视频数据
NET_STATUS_CODEC_DROP_CNT
全局丢包次数，为了避免延迟持续恶性堆积，SDK 在数据积压超过警戒线以后会主动丢包，丢包次数越多，说明网络问题越严重。
NET_STATUS_SERVER_IP
连接的推流服务器的 IP，一般应该是离客户端跳数比较少的就近服务器
3. 帧率太低3.1 帧率太低的评判通过 TXLivePushListener 的 VIDEO_FPS 的状态数据，我们可以获得当前推流的视频帧率。正常来说每秒 15FPS 以上的视频流才能保证观看的流畅度，如果 FPS 在 10 帧以下，观众就会明显的感到画面卡顿。
3.2 针对性优化方案
3.2.1 观察 CPU_USAGE 的大小通过 TXLivePushListener 的 CPU_USAGE 的状态数据，我们可以获得当前推流 SDK 的 CPU 占用情况 和 当前系统的 CPU 占用情况。如果当前系统的整体 CPU 使用率超过 80%，那么视频的采集和编码都会受到影响，无法正常发挥作用；如果 CPU 使用率达到 100%，那么主播端本身就已经很卡，观众端要有流畅的观看体验显然是不可能的。
3.2.2 确认谁在消耗 CPU一款直播 App 中使用 CPU 的不可能只有 RTMP SDK，弹幕、飘星、文本消息互动等都有可能会消耗一定的 CPU，这些都是不可避免的。如果单纯要测试推流 SDK 的 CPU 占用情况，可以使用我们的
来观察和评估。
3.2.3 不盲目追高分辨率过高的视频分辨率并不一定能带来清晰的画质：首先，较高的分辨率要配合较高的码率才能发挥效果，低码率高分辨的清晰度很多时候比不上高码率低分辨率。其次，像 1280 x 720 这样的分辨率在平均 5 寸左右的手机屏幕上并不能看出优势，要像跟 960 x 540 的分辨率拉开差距，只有在 PC 上全屏观看才能有明显的感官差异。但较高的分辨率会显著提升 SDK 的 CPU 使用率，因此常规情况下推荐使用 TXLivePush 的
设置 高清 档即可，盲目追高分辨率有可能达不到预期的目标。
3.3.4 适当使用硬件加速现在的智能手机都支持硬件编码来降低视频编码对 CPU 的依赖，如果您发现您的 App 的 CPU 使用率过高，可以开启硬件编码来降低 CPU 使用率。TXLivePush 的 setVideoQuality 的高清档默认使用的是软件编码（硬件编码在部分 Android 手机上的编码效果不佳，马赛克感很强是个硬伤），如果要使用硬件编码，可以使用 TXLivePushConfig 的
选项开启。
4. 上传阻塞据统计，视频云客户群 80% 以上的直播间卡顿问题，均是由于主播端上传阻塞所致。
4.1 上传阻塞的评判
4.1.1：BITRATE 与 NET_SPEED 的关系BITRATE( = VIDEO_BITRATE + AUDIO_BITRATE ) 指的是编码器每秒产生了多少音视频数据要推出去，NET_SPEED 指的是每秒钟实际推出了多少数据，所以如果 BITRATE == NET_SPEED 的情况是常态，则推流质量会非常良好；而如果 BITRATE &= NET_SPEED 这种情况的持续时间比较长，推流质量就很难有什么保障。
4.1.2：CACHE_SIZE 和 DROP_CNT 的数值BITRATE &= NET_SPEED 的情况一旦出现，编码器产生的音视频数据就会在主播的手机上积压起来，积压的严重程度以 CACHE_SIZE 这个状态值展示出来，如果 CACHE_SIZE 超过警戒线，SDK 会主动丢弃一些音视频数据，从而触发 DROP_CNT 的增长。下图所示就是一个典型的上行阻塞，途中 CACHE_SIZE 始终在红色警戒线以上，说明上行网络不足以满足数据的传输需求，也就是上行阻塞严重：
注意：您可以在&【质量监控】里看到类似上图的图表。
4.2 针对性优化方案
4.2.1 主动提示主播对于注重清晰度的场景下，通过合适的 UI 交互提示主播 “当前网络质量很糟糕，建议您拉近离路由器的距离，避免 Wi-Fi 穿墙” 是最好的选择。RTMP SDK 的推流功能文档中有涉及 事件处理 的介绍，您可以利用它来做到这一点，推荐的做法是：如果 App 在短时间内连续收到
的多个 PUSH_WARNING_NET_BUSY 事件，则提示主播网络关注一下当前网络质量，因为对于上行阻塞这种情况而言，主播本人是没办法通过视频的表现感知到的，只能通过观众的提醒或者 App 的提醒来了解。
4.2.2 合理的编码设置如下是我们推荐的编码设置（适合美女秀场，更多信息请参考 ），可以通过 TXLivePush 里的 setVideoQuality 接口进行相应档位的设置：
400kbps - 800kbps
如果您比较关注带宽成本，推荐选择该档位，画质会偏模糊，但带宽费用较高清档要低 60%。
高清（推荐）
如果您比较关注画质，推荐选择该档位，能确保绝大多数主流手机都能推出很清晰的画面。
慎用：如果您的场景多是小屏观看不推荐使用，如果是大屏幕观看且主播网络质量很好可以考虑。
4.2.3 启用流控辅助有些客户会说：“我们的 App 任何用户都有可能使用，让我去决定他们的网速不现实。”如果主播的上传网速的不确定性确实很大，推荐开启网络自适应，参考文档见
。不过我们依然建议优先参考 4.2.1 主动提示主播 中的方案，毕竟既要高清流畅，又不能保证上传网速，本身就是 即要马儿跑得快，又要马儿不吃草 的事情。
videoBitrateMin
videoBitrateMax
1000（推荐根据具体分辨率而定）
enableAutoBitrate
码率自适应
autoAdjustStrategy
码率调整策略
AUTO_ADJUST_BITRATE_STRATEGY_2
5. 播放端的优化
5.1 卡顿 & 延迟如上图，下行网络的波动或者下行带宽不沟通，都会导致在播放过程中出现一段段的饥饿期——App 这段时间内拿不到可以播放的音视频数据。如果想要让观看端的视频卡顿尽量少，就要尽可能地让 App 缓存足够多的视频数据，以保证它能平安度过这些“饥饿期”，但是 App 缓存太多的音视频数据会引入一个新的问题 —— 高延迟，这对互动性要求高的场景是很坏的消息，同时如果不做延迟修正和控制，卡顿引起的延迟会有累积效应，就是播放时间越久，延迟越高，延迟修正做得好不好是衡量一款播放器是否足够优秀的关键指标。所以延迟和流畅是一架天平的两端，如果过分强调低延迟，就会导致轻微的网络波动即产生明显的播放端卡顿。反之，如果过分强调流畅，就意味着引入大量的延迟（典型的案例就是 HLS(m3u8)通过引入 10-30 秒的延迟来实现流畅的播放体验）。
5.2 针对性优化方案为了能够让您无需了解过多流控处理知识就能优化出较好的播放体验，腾讯云 RTMP SDK 经过多个版本的改进，优化出一套自动调节技术，并在其基础上推出了三种比较优秀的 ：
自动模式：如果您不太确定您的主要场景是什么，可以直接选择这个模式。
把 TXLivePlayConfig 中的 setAutoAdjustCache 开关打开，即为自动模式。在该模式下播放器会根据当前网络情况，对延迟进行自动调节（默认情况下播放器会在 1s - 5s 这个区间内自动调节延迟大小，您可以通过 setMinCacheTime 和 setMaxCacheTime 对默认值进行修改），以保证在足够流畅的情况下尽量降低观众跟主播端的延迟，确保良好的互动体验。
极速模式：主要适用于秀场直播等互动性高，因而对延迟要求比较苛刻的场景。
极速模式设置方法是
setMinCacheTime = setMaxCacheTime = 1s
，自动模式跟极速模式的差异只是MaxCacheTime 有所不同 （极速模式的 MaxCacheTime 一般比较低，而自动模式的MaxCacheTime 则相对较高 ），这种灵活性主要得益于 SDK 内部的自动调控技术，可以在不引入卡顿的情况下自动修正延时大小，而MaxCacheTime 反应的就是调节速度：MaxCacheTime的值越大，调控速度会越发保守，卡顿概率就会越低。
流畅模式：主要适用于游戏直播 等大码率高清直播场景。
当把播放器中的 setAutoAdjustCache 开关关闭，即为流畅模式，在该模式下播放器采取的处理策略跟 Adobe Flash 内核的缓存出策略如出一辙：当视频出现卡顿后，会进入 loading 状态直到缓冲区蓄满，之后进入 playing 状态，直到下一次遭遇无法抵御的网络波动。默认情况下缓冲大小为 5s，您可以通过 setCacheTime 进行更改。在延迟要求不高的场景下，这种看似简单的模式会更加可靠，因为该模式本质上就是通过牺牲一点延迟来降低卡顿率。
文档是否有帮助解决问题？
您已提交过反馈，无需再次提交
反馈收到，动动手指，帮我们明确下问题点
文档内容不全面，重点不清晰，找不到资料
文字描述过于冗余、复杂
描述的步骤有问题，按照操作无法生效
文档内容更新不及时
提交成功！非常感谢您的反馈，我们会继续努力做到更好！
如果有其他疑问，你也可以通过提问形式与我们联系探讨
移动直播 相关文档
视频卡顿怎么办
视频卡顿怎么办
1. 为什么会卡顿卡顿的原因无外乎三种情况：
原因 1：帧率太低如果主播端手机性能较差，或者有很占 CPU 的后台程序在运行，可能导致视频的帧率太低。正常情况下每秒 15FPS 以上的视频流才能保证观看的流畅度，如果 FPS 低于 10 帧，可以判定为帧率太低，这会导致全部观众的观看体验都很卡顿。
原因 2：上传阻塞主播的手机在推流时会源源不断地产生音视频数据，但如果手机的上传网速太小，那么产生的音视频数据都会被堆积在主播的手机里传不出去，上传阻塞会导致全部观众的观看体验都很卡顿。国内运营商 提供的宽带上网套餐中，下载网速虽然已经达到了 10Mbps， 20Mbps 甚至是 100Mbps，但上传网速却还一直限制的比较小，很多小城市的上行网速最快是 512Kbps（也就是每秒最多上传 64KB 的数据）。Wi-Fi 上网 遵循 IEEE 802.11 规定的载波多路侦听和冲突避免标准，简言之就是一个 Wi-Fi 热点同时只能跟一个手机通讯，其它手机在跟热点通讯前都要先探测或询问自己是否能够通讯，所以一个 Wi-Fi 热点使用的人越多就越慢。同时 Wi-Fi 信号受建筑墙体的屏蔽干扰很厉害，而一般的中国普通家庭很少在装修时考虑好 Wi-Fi 路由器和各个房间的信号衰减问题，可能主播本人也不清楚自己做直播的房间离家里的路由器究竟穿了几堵墙。
原因 3：下行不佳就是观众的下载带宽跟不上或者网络很波动，比如直播流的码率是 1Mbps 的，也就是每秒钟有 1M 比特的数据流要下载下来，但如果观众端的带宽不够，就会导致观众端体验非常卡顿。 下行不佳只会影响当前网络环境下的观众。
2. 发现问题的“眼睛”推流 SDK 提供了一种状态反馈机制，每隔 1-2 秒就会将内部各种状态参数反馈出来，我们可以通过注册TXLivePushListener 监听器来获取这些状态。
NET_STATUS_CPU_USAGE
当前进程的 CPU 使用率和本机总体的 CPU 使用率
NET_STATUS_VIDEO_FPS
当前视频帧率，也就是视频编码器每条生产了多少帧画面
NET_STATUS_NET_SPEED
当前的发送速度（单位：kbps）
NET_STATUS_VIDEO_BITRATE
当前视频编码器输出的比特率，也就是编码器每秒生产了多少视频数据，单位： kbps
NET_STATUS_AUDIO_BITRATE
当前音频编码器输出的比特率，也就是编码器每秒生产了多少音频数据，单位： kbps
NET_STATUS_CACHE_SIZE
音视频数据堆积情况，这个数字超过个位数，即说明当前上行带宽不足以消费掉已经生产的音视频数据
NET_STATUS_CODEC_DROP_CNT
全局丢包次数，为了避免延迟持续恶性堆积，SDK 在数据积压超过警戒线以后会主动丢包，丢包次数越多，说明网络问题越严重。
NET_STATUS_SERVER_IP
连接的推流服务器的 IP，一般应该是离客户端跳数比较少的就近服务器
3. 帧率太低3.1 帧率太低的评判通过 TXLivePushListener 的 VIDEO_FPS 的状态数据，我们可以获得当前推流的视频帧率。正常来说每秒 15FPS 以上的视频流才能保证观看的流畅度，如果 FPS 在 10 帧以下，观众就会明显的感到画面卡顿。
3.2 针对性优化方案
3.2.1 观察 CPU_USAGE 的大小通过 TXLivePushListener 的 CPU_USAGE 的状态数据，我们可以获得当前推流 SDK 的 CPU 占用情况 和 当前系统的 CPU 占用情况。如果当前系统的整体 CPU 使用率超过 80%，那么视频的采集和编码都会受到影响，无法正常发挥作用；如果 CPU 使用率达到 100%，那么主播端本身就已经很卡，观众端要有流畅的观看体验显然是不可能的。
3.2.2 确认谁在消耗 CPU一款直播 App 中使用 CPU 的不可能只有 RTMP SDK，弹幕、飘星、文本消息互动等都有可能会消耗一定的 CPU，这些都是不可避免的。如果单纯要测试推流 SDK 的 CPU 占用情况，可以使用我们的
来观察和评估。
3.2.3 不盲目追高分辨率过高的视频分辨率并不一定能带来清晰的画质：首先，较高的分辨率要配合较高的码率才能发挥效果，低码率高分辨的清晰度很多时候比不上高码率低分辨率。其次，像 1280 x 720 这样的分辨率在平均 5 寸左右的手机屏幕上并不能看出优势，要像跟 960 x 540 的分辨率拉开差距，只有在 PC 上全屏观看才能有明显的感官差异。但较高的分辨率会显著提升 SDK 的 CPU 使用率，因此常规情况下推荐使用 TXLivePush 的
设置 高清 档即可，盲目追高分辨率有可能达不到预期的目标。
3.3.4 适当使用硬件加速现在的智能手机都支持硬件编码来降低视频编码对 CPU 的依赖，如果您发现您的 App 的 CPU 使用率过高，可以开启硬件编码来降低 CPU 使用率。TXLivePush 的 setVideoQuality 的高清档默认使用的是软件编码（硬件编码在部分 Android 手机上的编码效果不佳，马赛克感很强是个硬伤），如果要使用硬件编码，可以使用 TXLivePushConfig 的
选项开启。
4. 上传阻塞据统计，视频云客户群 80% 以上的直播间卡顿问题，均是由于主播端上传阻塞所致。
4.1 上传阻塞的评判
4.1.1：BITRATE 与 NET_SPEED 的关系BITRATE( = VIDEO_BITRATE + AUDIO_BITRATE ) 指的是编码器每秒产生了多少音视频数据要推出去，NET_SPEED 指的是每秒钟实际推出了多少数据，所以如果 BITRATE == NET_SPEED 的情况是常态，则推流质量会非常良好；而如果 BITRATE &= NET_SPEED 这种情况的持续时间比较长，推流质量就很难有什么保障。
4.1.2：CACHE_SIZE 和 DROP_CNT 的数值BITRATE &= NET_SPEED 的情况一旦出现，编码器产生的音视频数据就会在主播的手机上积压起来，积压的严重程度以 CACHE_SIZE 这个状态值展示出来，如果 CACHE_SIZE 超过警戒线，SDK 会主动丢弃一些音视频数据，从而触发 DROP_CNT 的增长。下图所示就是一个典型的上行阻塞，途中 CACHE_SIZE 始终在红色警戒线以上，说明上行网络不足以满足数据的传输需求，也就是上行阻塞严重：
注意：您可以在&【质量监控】里看到类似上图的图表。
4.2 针对性优化方案
4.2.1 主动提示主播对于注重清晰度的场景下，通过合适的 UI 交互提示主播 “当前网络质量很糟糕，建议您拉近离路由器的距离，避免 Wi-Fi 穿墙” 是最好的选择。RTMP SDK 的推流功能文档中有涉及 事件处理 的介绍，您可以利用它来做到这一点，推荐的做法是：如果 App 在短时间内连续收到
的多个 PUSH_WARNING_NET_BUSY 事件，则提示主播网络关注一下当前网络质量，因为对于上行阻塞这种情况而言，主播本人是没办法通过视频的表现感知到的，只能通过观众的提醒或者 App 的提醒来了解。
4.2.2 合理的编码设置如下是我们推荐的编码设置（适合美女秀场，更多信息请参考 ），可以通过 TXLivePush 里的 setVideoQuality 接口进行相应档位的设置：
400kbps - 800kbps
如果您比较关注带宽成本，推荐选择该档位，画质会偏模糊，但带宽费用较高清档要低 60%。
高清（推荐）
如果您比较关注画质，推荐选择该档位，能确保绝大多数主流手机都能推出很清晰的画面。
慎用：如果您的场景多是小屏观看不推荐使用，如果是大屏幕观看且主播网络质量很好可以考虑。
4.2.3 启用流控辅助有些客户会说：“我们的 App 任何用户都有可能使用，让我去决定他们的网速不现实。”如果主播的上传网速的不确定性确实很大，推荐开启网络自适应，参考文档见
。不过我们依然建议优先参考 4.2.1 主动提示主播 中的方案，毕竟既要高清流畅，又不能保证上传网速，本身就是 即要马儿跑得快，又要马儿不吃草 的事情。
videoBitrateMin
videoBitrateMax
1000（推荐根据具体分辨率而定）
enableAutoBitrate
码率自适应
autoAdjustStrategy
码率调整策略
AUTO_ADJUST_BITRATE_STRATEGY_2
5. 播放端的优化
5.1 卡顿 & 延迟如上图，下行网络的波动或者下行带宽不沟通，都会导致在播放过程中出现一段段的饥饿期——App 这段时间内拿不到可以播放的音视频数据。如果想要让观看端的视频卡顿尽量少，就要尽可能地让 App 缓存足够多的视频数据，以保证它能平安度过这些“饥饿期”，但是 App 缓存太多的音视频数据会引入一个新的问题 —— 高延迟，这对互动性要求高的场景是很坏的消息，同时如果不做延迟修正和控制，卡顿引起的延迟会有累积效应，就是播放时间越久，延迟越高，延迟修正做得好不好是衡量一款播放器是否足够优秀的关键指标。所以延迟和流畅是一架天平的两端，如果过分强调低延迟，就会导致轻微的网络波动即产生明显的播放端卡顿。反之，如果过分强调流畅，就意味着引入大量的延迟（典型的案例就是 HLS(m3u8)通过引入 10-30 秒的延迟来实现流畅的播放体验）。
5.2 针对性优化方案为了能够让您无需了解过多流控处理知识就能优化出较好的播放体验，腾讯云 RTMP SDK 经过多个版本的改进，优化出一套自动调节技术，并在其基础上推出了三种比较优秀的 ：
自动模式：如果您不太确定您的主要场景是什么，可以直接选择这个模式。
把 TXLivePlayConfig 中的 setAutoAdjustCache 开关打开，即为自动模式。在该模式下播放器会根据当前网络情况，对延迟进行自动调节（默认情况下播放器会在 1s - 5s 这个区间内自动调节延迟大小，您可以通过 setMinCacheTime 和 setMaxCacheTime 对默认值进行修改），以保证在足够流畅的情况下尽量降低观众跟主播端的延迟，确保良好的互动体验。
极速模式：主要适用于秀场直播等互动性高，因而对延迟要求比较苛刻的场景。
极速模式设置方法是
setMinCacheTime = setMaxCacheTime = 1s
，自动模式跟极速模式的差异只是MaxCacheTime 有所不同 （极速模式的 MaxCacheTime 一般比较低，而自动模式的MaxCacheTime 则相对较高 ），这种灵活性主要得益于 SDK 内部的自动调控技术，可以在不引入卡顿的情况下自动修正延时大小，而MaxCacheTime 反应的就是调节速度：MaxCacheTime的值越大，调控速度会越发保守，卡顿概率就会越低。
流畅模式：主要适用于游戏直播 等大码率高清直播场景。
当把播放器中的 setAutoAdjustCache 开关关闭，即为流畅模式，在该模式下播放器采取的处理策略跟 Adobe Flash 内核的缓存出策略如出一辙：当视频出现卡顿后，会进入 loading 状态直到缓冲区蓄满，之后进入 playing 状态，直到下一次遭遇无法抵御的网络波动。默认情况下缓冲大小为 5s，您可以通过 setCacheTime 进行更改。在延迟要求不高的场景下，这种看似简单的模式会更加可靠，因为该模式本质上就是通过牺牲一点延迟来降低卡顿率。
文档是否有帮助解决问题？
您已提交过反馈，无需再次提交
反馈收到，动动手指，帮我们明确下问题点
文档内容不全面，重点不清晰，找不到资料
文字描述过于冗余、复杂
描述的步骤有问题，按照操作无法生效
文档内容更新不及时
提交成功！非常感谢您的反馈，我们会继续努力做到更好！
如果有其他疑问，你也可以通过提问形式与我们联系探讨
移动直播 相关文档
关注公众号，移动管理云服务
长按识别或截图保存关注公众号，移动管理云服务腾讯云移动直播、互动直播哪个更好用？在哪里购买更便宜？ - 知乎有问题，上知乎。知乎作为中文互联网最大的知识分享平台，以「知识连接一切」为愿景，致力于构建一个人人都可以便捷接入的知识分享网络，让人们便捷地与世界分享知识、经验和见解，发现更大的世界。2被浏览54分享邀请回答赞同 添加评论分享收藏感谢收起云数据库 TencentDB
互联网中间件
域名与网站
开发者工具
云智AI应用服务
云智AI平台服务
云智大数据基础服务
云智大数据可视化服务
云智大数据应用服务
行业解决方案
大数据与AI解决方案
物联网解决方案
安全与运维解决方案
微信解决方案
微信小程序
服务与培训
如何实现好的画质
如何实现好的画质
场景一：美女直播Step1: 更新最新版SDK每一版 SDK 我们都或多或少的对美颜效果进行一定的提升，比如：
1.9.1 我们更新了新的美颜引擎，在前景侧重、算法优化、曝光改善等方面做了不少改进，同时性能也有很大的提升。
1.9.2 我们优化了降噪效果，使夜间的噪点大幅减少，人物的清晰度也有提升
2.0.0 我们又为 iOS 增加了一些新的滤镜，来解决肤色过黄的问题
Step2: 设置画质级别我们要知道直播端看到的画面跟观众端看到的画面是不一样的：
主播 vs 观众：主播看到的画面是经过采集后的视频直接渲染到了手机屏幕上，所以清晰度最高，该画面还要经过 视频编码 =& 网络传输 =& 视频解码，才能到达观众的手机屏幕，由于视频编码会导致画质的损失，所以观众看到的画面在清晰度上要逊于主播端。
不合理的参数设置会导致画质损失严重，比较典型的一个错误配置就是 “高分辨率配低码率”，这样的配置会导致画面模糊，并且画面马赛克严重。怎么办？
setVideoQuality我在 1.9.1 版本的 TXLivePusher 中新加入的 setVideoQuality 函数，并给出了几个级别的设置，您选择 高清 模式即可达到最佳的美女直播效果。详情请关注
Step3: Android 增加手动曝光同样美颜算法，在不同的 Android 手机上差异可能很大，究其原因，主要是曝光的差异产生了视觉感受的大不同。
在 iOS 平台我们采用了系统的自动曝光，但是 Android 机型差异太大，很多千元机的自动曝光效果实在一般，所以我们还是推荐在您的 UI 界面上提供一个自动曝光的操作滑竿，让主播可以自己调节曝光值大小，以符合他/她的预期。
Android 版 RTMP SDK 中的 TXLivePush::setExposureCompensation 接口提供了调节曝光的能力，参数 value 为 -1 到 1 的浮点数： 0 表示不调整， -1 是将曝光降到最低， 1 表示是将曝光加强到最高。
Step4: 增加色彩滤镜滤镜也是很关键的一环，不同的色彩滤镜能够营造不同的氛围，主播配合衣服的颜色或者房间灯光选择合适的滤镜，会让整个画面的氛围有更好的效果。
1.9.1 版本的 RTMP SDK 开始支持颜色滤镜， TXLivePusher 中新加入的 setFilter 可以设置滤镜效果，我们设计师团队提供了八种素材，默认打包在了 Demo 中，您可以随意使用，不用担心版权问题。
Step5: Android马赛克严重有些客户会发现 Android 版 RTMP SDK 推流出来的画面马赛克特别严重，尤其是在画面有运动时，这是 Android 硬件编码的常规表现，解决方案有两个：
我比较关注耗电！如果您比较关注APP耗电情况，那么可以考虑直接调大推流的码率，或者使用 setVideoQuality 的 高清 档位（如果设定的码率比较低，Android 的硬编码模块会通过大幅降低画质来确保码率稳定）
我比较关注带宽！如果您比较关注带宽成本，那么直接调高码率可能并不适合您的需求，这时您可以通过关闭硬件加速解决问题（关闭方法见
Step6: 关闭网络自适应TXLivePushConfig 中的 AutoAdjustBitrate 选项是网络自适应开关，开启后，当主播网络变差时，会通过降低画质来保证流畅性，但这一点 并不适合 美女秀场模式。
网络自适应是适合游戏直播场景的技术，因为游戏直播场景中观众对流畅性的追求高于画质，如果在战斗时间主播网络有波动，画质可以渣一点，但绝对不能卡，所以降低画质来保证流畅性（帧率）就是必选项了。
但美女秀场场景中，清晰度更加重要，不少客户反馈有些直播间画质很好，有些直播间画质很差，导致这个现象的一个高概率原因就是开启了网络自适应。
我们推荐关闭网络自适应，对于出现网络波动的情况，改用
的方式进行优化，这种方式更加釜底抽薪。
场景二：游戏直播Option1: 简单应对在直播开始的界面上提供三种清晰度选项：标清、高清和超清，让主播自己选择，游戏主播一般相对比较偏专业，会自己摸索出适合自己当前在玩的游戏的效果，三种档位对应的配置如下：
分辨率（Resolution）
FPS（FPS）
码率（Bitrate）
VIDEO_RESOLUTION_TYPE_360_640
VIDEO_RESOLUTION_TYPE_540_960
VIDEO_RESOLUTION_TYPE_720_1280
注意： 游戏直播场景，FPS 最低是 20 ，不能更低了，否则观众端的表现是卡顿感严重。
Option2: 专业应对根据不同的游戏设置不同的分辨率和码率，这就比较耗功夫和时间了，比如：
皇室战争 - 这类画面变化幅度不大的游戏，推荐选择 960 * 540 的分辨率，800kbps-1000kbps 的码率就可以输出不错的效果。
捕鱼达人 - 这类画面变化幅度较大的游戏，推荐选择 960 * 540 的分辨率，码率相对要高一点，比如1200kbps - 1500kbps。
神庙逃跑 - 这类画面变化幅度超大的游戏，推荐选择 640 * 360 的分辨率，码率也要很大，比如 2000kbps，否则妥妥的满屏马赛克。
音视频小科普Point1：720P一定更清楚吗？如果限定一个码率，比如 800kbps，那么分辨率越高就会让编码器越难做 。
可以想象，编码器必须拆东墙补西墙，通过减少色彩信息或者引入马赛克这种“鱼目混珠”的手段来承载足够多的像素点。所以，同样的是2G的一个电影文件，1080p画质的版本可能不如720p画质的版本看起来更清晰。
同时，如果你的观众都是在小手机屏幕上观看视频，那么 960 * 540 1000kbps
1280 * 720 1800kbps 的差距其实也不明显，比如下面两张图片就是基于 airplay 技术的 iOS 录屏直播，您看得出左边和右边的清晰度差距吗？
用 32 寸的 LCD 显示器全屏看，还是有差距的。
Point2：帧率不要超过24！如果限定一个码率，比如800kbps，那么帧率越高，编码器就必须加大对单帧画面的压缩比，也就是通过降低画质来承载足够多的帧数。如果视频源来自摄像头，24FPS已经是肉眼极限，所以一般20帧的FPS就已经可以达到很好的用户体验了。
有些玩过3D游戏的朋友可能会说：“游戏的帧率越高越流畅吗？比如 60FPS， 120FPS?”
这里要注意一定不要混淆场景：游戏追求高帧率是渲染帧率，其目的是为了尽可能让3D模型渲染出来的运动效果更加接近真实运动轨迹，所以帧率越高越好。
但采集帧率不需要这么高，比如手机摄像头，它采集的目标是真实世界的物体，真实世界的物体本来就是连续运动的，而不是用一阵阵画面刷新来模拟的，所以 20FPS 的采集就足以。
对于游戏直播，帧率达到 24FPS 当然最好，但也要考虑到系统编码开销，手机的温度和CPU占用等等，毕竟主播还要用同样的一台手机玩游戏呢。
文档是否有帮助解决问题？
您已提交过反馈，无需再次提交
反馈收到，动动手指，帮我们明确下问题点
文档内容不全面，重点不清晰，找不到资料
文字描述过于冗余、复杂
描述的步骤有问题，按照操作无法生效
文档内容更新不及时
提交成功！非常感谢您的反馈，我们会继续努力做到更好！
如果有其他疑问，你也可以通过提问形式与我们联系探讨
移动直播 相关文档
如何实现好的画质
如何实现好的画质
场景一：美女直播Step1: 更新最新版SDK每一版 SDK 我们都或多或少的对美颜效果进行一定的提升，比如：
1.9.1 我们更新了新的美颜引擎，在前景侧重、算法优化、曝光改善等方面做了不少改进，同时性能也有很大的提升。
1.9.2 我们优化了降噪效果，使夜间的噪点大幅减少，人物的清晰度也有提升
2.0.0 我们又为 iOS 增加了一些新的滤镜，来解决肤色过黄的问题
Step2: 设置画质级别我们要知道直播端看到的画面跟观众端看到的画面是不一样的：
主播 vs 观众：主播看到的画面是经过采集后的视频直接渲染到了手机屏幕上，所以清晰度最高，该画面还要经过 视频编码 =& 网络传输 =& 视频解码，才能到达观众的手机屏幕，由于视频编码会导致画质的损失，所以观众看到的画面在清晰度上要逊于主播端。
不合理的参数设置会导致画质损失严重，比较典型的一个错误配置就是 “高分辨率配低码率”，这样的配置会导致画面模糊，并且画面马赛克严重。怎么办？
setVideoQuality我在 1.9.1 版本的 TXLivePusher 中新加入的 setVideoQuality 函数，并给出了几个级别的设置，您选择 高清 模式即可达到最佳的美女直播效果。详情请关注
Step3: Android 增加手动曝光同样美颜算法，在不同的 Android 手机上差异可能很大，究其原因，主要是曝光的差异产生了视觉感受的大不同。
在 iOS 平台我们采用了系统的自动曝光，但是 Android 机型差异太大，很多千元机的自动曝光效果实在一般，所以我们还是推荐在您的 UI 界面上提供一个自动曝光的操作滑竿，让主播可以自己调节曝光值大小，以符合他/她的预期。
Android 版 RTMP SDK 中的 TXLivePush::setExposureCompensation 接口提供了调节曝光的能力，参数 value 为 -1 到 1 的浮点数： 0 表示不调整， -1 是将曝光降到最低， 1 表示是将曝光加强到最高。
Step4: 增加色彩滤镜滤镜也是很关键的一环，不同的色彩滤镜能够营造不同的氛围，主播配合衣服的颜色或者房间灯光选择合适的滤镜，会让整个画面的氛围有更好的效果。
1.9.1 版本的 RTMP SDK 开始支持颜色滤镜， TXLivePusher 中新加入的 setFilter 可以设置滤镜效果，我们设计师团队提供了八种素材，默认打包在了 Demo 中，您可以随意使用，不用担心版权问题。
Step5: Android马赛克严重有些客户会发现 Android 版 RTMP SDK 推流出来的画面马赛克特别严重，尤其是在画面有运动时，这是 Android 硬件编码的常规表现，解决方案有两个：
我比较关注耗电！如果您比较关注APP耗电情况，那么可以考虑直接调大推流的码率，或者使用 setVideoQuality 的 高清 档位（如果设定的码率比较低，Android 的硬编码模块会通过大幅降低画质来确保码率稳定）
我比较关注带宽！如果您比较关注带宽成本，那么直接调高码率可能并不适合您的需求，这时您可以通过关闭硬件加速解决问题（关闭方法见
Step6: 关闭网络自适应TXLivePushConfig 中的 AutoAdjustBitrate 选项是网络自适应开关，开启后，当主播网络变差时，会通过降低画质来保证流畅性，但这一点 并不适合 美女秀场模式。
网络自适应是适合游戏直播场景的技术，因为游戏直播场景中观众对流畅性的追求高于画质，如果在战斗时间主播网络有波动，画质可以渣一点，但绝对不能卡，所以降低画质来保证流畅性（帧率）就是必选项了。
但美女秀场场景中，清晰度更加重要，不少客户反馈有些直播间画质很好，有些直播间画质很差，导致这个现象的一个高概率原因就是开启了网络自适应。
我们推荐关闭网络自适应，对于出现网络波动的情况，改用
的方式进行优化，这种方式更加釜底抽薪。
场景二：游戏直播Option1: 简单应对在直播开始的界面上提供三种清晰度选项：标清、高清和超清，让主播自己选择，游戏主播一般相对比较偏专业，会自己摸索出适合自己当前在玩的游戏的效果，三种档位对应的配置如下：
分辨率（Resolution）
FPS（FPS）
码率（Bitrate）
VIDEO_RESOLUTION_TYPE_360_640
VIDEO_RESOLUTION_TYPE_540_960
VIDEO_RESOLUTION_TYPE_720_1280
注意： 游戏直播场景，FPS 最低是 20 ，不能更低了，否则观众端的表现是卡顿感严重。
Option2: 专业应对根据不同的游戏设置不同的分辨率和码率，这就比较耗功夫和时间了，比如：
皇室战争 - 这类画面变化幅度不大的游戏，推荐选择 960 * 540 的分辨率，800kbps-1000kbps 的码率就可以输出不错的效果。
捕鱼达人 - 这类画面变化幅度较大的游戏，推荐选择 960 * 540 的分辨率，码率相对要高一点，比如1200kbps - 1500kbps。
神庙逃跑 - 这类画面变化幅度超大的游戏，推荐选择 640 * 360 的分辨率，码率也要很大，比如 2000kbps，否则妥妥的满屏马赛克。
音视频小科普Point1：720P一定更清楚吗？如果限定一个码率，比如 800kbps，那么分辨率越高就会让编码器越难做 。
可以想象，编码器必须拆东墙补西墙，通过减少色彩信息或者引入马赛克这种“鱼目混珠”的手段来承载足够多的像素点。所以，同样的是2G的一个电影文件，1080p画质的版本可能不如720p画质的版本看起来更清晰。
同时，如果你的观众都是在小手机屏幕上观看视频，那么 960 * 540 1000kbps
1280 * 720 1800kbps 的差距其实也不明显，比如下面两张图片就是基于 airplay 技术的 iOS 录屏直播，您看得出左边和右边的清晰度差距吗？
用 32 寸的 LCD 显示器全屏看，还是有差距的。
Point2：帧率不要超过24！如果限定一个码率，比如800kbps，那么帧率越高，编码器就必须加大对单帧画面的压缩比，也就是通过降低画质来承载足够多的帧数。如果视频源来自摄像头，24FPS已经是肉眼极限，所以一般20帧的FPS就已经可以达到很好的用户体验了。
有些玩过3D游戏的朋友可能会说：“游戏的帧率越高越流畅吗？比如 60FPS， 120FPS?”
这里要注意一定不要混淆场景：游戏追求高帧率是渲染帧率，其目的是为了尽可能让3D模型渲染出来的运动效果更加接近真实运动轨迹，所以帧率越高越好。
但采集帧率不需要这么高，比如手机摄像头，它采集的目标是真实世界的物体，真实世界的物体本来就是连续运动的，而不是用一阵阵画面刷新来模拟的，所以 20FPS 的采集就足以。
对于游戏直播，帧率达到 24FPS 当然最好，但也要考虑到系统编码开销，手机的温度和CPU占用等等，毕竟主播还要用同样的一台手机玩游戏呢。
文档是否有帮助解决问题？
您已提交过反馈，无需再次提交
反馈收到，动动手指，帮我们明确下问题点
文档内容不全面，重点不清晰，找不到资料
文字描述过于冗余、复杂
描述的步骤有问题，按照操作无法生效
文档内容更新不及时
提交成功！非常感谢您的反馈，我们会继续努力做到更好！
如果有其他疑问，你也可以通过提问形式与我们联系探讨
移动直播 相关文档
关注公众号，移动管理云服务
长按识别或截图保存关注公众号，移动管理云服务