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
87 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
1 Reply
Lei_Z_Intel1
Employee
87 Views

感谢对该问题的反馈。对于移动终端带宽自适应特性,v3.3确实有不足的地方。我们在六月即将发布的v3.4版本从客户端SDK和MCU端都做了比较大的改进,内部测试数据表明,Android和iOS App都可以随着网络状况的变化快速改变比特率。欢迎在v3.4发布后再次测试该场景,有问题及时和我们反馈。

Reply