Intel® Collaboration Suite for WebRTC
Community support and discussions on the Intel® Collaboration Suite for WebRTC (Intel® CS for WebRTC).
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
For the latest information on Intel’s response to the Log4j/Log4Shell vulnerability, please see Intel-SA-00646
1136 Discussions

#bug android sdk v3.3.1: vp8 coded video published with android sdk has really POOOOR quality, while js client is ok

mah_f_
Beginner
117 Views

测试环境如下:

一台阿里云单逻辑cpu的云主机,带宽足够,部署了ubuntu 14.04下的mcu服务器端。配置了基本例子所需的ssl证书、域名、ip等内容。测试基本例子的发布订阅功能正常。

一台macbook pro笔记本电脑做订阅端,通过chrome(Version 58.0.3029.96 (64-bit))访问https://[domain.com]/?mix=false&publish=false 订阅可能的发布流。同时开了chrome://webrtc-internals观测相关的分辨率、码率信息。

另一台安卓手机(华为PE-TL10,另一台手持式专用安卓设备也可以复现此问题)当发布端发布前置摄像头视频,分两种情况测试:

1.采用最新chrome android客户端,通过访问https://[domain.com]/?mix=false 发布前置摄像头,js脚本中发布的时候,限制编码器为vp8,分辨率为648*480,帧率不限,码率不限;

2.采用v3.3.1的官方android客户端,修改了这几处代码:i).取消了对h264编码的混合流的订阅;ii) 设置了前置摄像头发布,限制编码器为vp8,分辨率为648*480,帧率不限,码率不限。通过在配置页面设置https://[domain.com]/ 网址发布;

两种情况发布的流有显著的差异,前一种web端js客户端发布视频的时候,发布整体码率在20kBps~150kBps之间波动,通常稳定在70kBps,降低了一阵就会恢复,分辨率稳定在648*480,帧率在17fps左右,画质较清晰,无明显马赛克或色块效应;

第二种用android sdk的客户端发布,发布整体码率一开始在50kBps上下波动,经过5s~10s之后,发布整体码率逐渐下降到10~15kBps,通常稳定在10kBps,长时间无法恢复,分辨率从640*480降到320*240甚至更低,画质较模糊,帧率在17fps左右,有明显马赛克或色块效应,可以用惨不忍睹不忍直视来形容;但是关闭app,重新发布,发布整体码率又能回到50kBps,然后过了一会儿,再次降低到10kBps左右。

通过测试环境对比分析可知,问题很大概率出在安卓sdk发布流时对网络带宽及延迟抖动的自适应算法上面,比如带宽估计过低,或者丢包应对异常,导致发布流的码率和分辨率在发布之后急剧下降,影响了整体的画质。

诚然,webrtc带宽自适应编解码引擎的代码量很大,平时更新也很多,但是安卓chrome内核和安卓sdk的vp8发布效果差这么多,实现代码差异如此之大,也太让人匪夷所思了。

0 Kudos
0 Replies
Reply