摘要:音频解码在中对中的数据进行解码解码后的帧存放到中音频播放中,通过调用回调接口,对中的音频帧数据进行解码成数据写入数据到数组,并由播放。对进行修改,将数据额外输出到本地,并与正常的数据进行对比。
欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~
一、问题背景与分析本文由QQ音乐技术团队发表于云+社区专栏
不久前,团队发现其Android平台App在播放MV视频《凤凰花开的路口》时,会带有如电流声一般的杂音,这影响了用户体验。 研发同学在初步定位时,发现有如下特征:
然而,各平台都是统一用HLS格式播放,即源头都是一样的。对于该问题,我们的定位思路如下:
分析播放流程如上图(图中内容从左往右),概括其关键步骤如下:
read_thread
;audioq
;sampq
。avformat_open_input
;avformat_find_stream_info
;av_find_best_stream
;stream_component_open
;av_read_frame(ic, pkt)
;audioq
中;audio_thread
中对audioq
中的数据进行decoder_decode_frame
解码;AVFrame
存放到sampq
中;aout_thread_n
中,通过调用回调接口sdl_audio_callback
,对sampq
中的音频帧数据进行解码成PCM数据;AudioTrack
播放。在梳理出播放流程后,标记出找到有可能出错的环节,方便进行“分层定位”(图中黄色标记)
AudioTrack
的设置是否有问题;接下来,根据难易程度,对上述环节逐个验证。
1、播放下载文件是否正常把Android平台播放的ts文件与各平台的进行比对,发现两者一样,该环节正常。
2、AudioTrack设置是否正常通过日志检查AudioTrack
以下配置参数:
以上参数设置的值与音频流的相符合,该环节正常。
3、音频解码逻辑是否有问题验证解码逻辑是否有问题,可以通过对PCM数据进行分析来确认。 对aout_thread_n
进行修改,将PCM数据额外输出到本地,并与正常的PCM数据进行对比。
正常PCM数据频谱图:
异常PCM数据频谱图:
正常PCM数据波形图:
异常PCM数据波形图:
对比分析可得出:
若解码逻辑正常,再结合之前已经验证文件下载正常。可以推测是数据读取环节出现异常。
4、数据读取是否有问题通过对数据读取的各步骤增加日志后,发现在av_find_best_stream
音频流选择时出现异常: ffmpeg -i
发现,该视频ts分片有2个音频流
通过强制分别读取两条音频流数据播放,发现:
基于此,也就验证了在第3步中的假设是正确的。
由上分析,可以得出结论:Android平台选择了第二条数据有问题的流进行播放。
四、问题根源:音频流选择 1、选择方式分析代码,大致如下所列,av_find_best_stream
函数选择音频流,该函数会根据2个主要参数进行选择:
avformat_find_stream_info
)时,额外解码出来的帧数(选择多的)int av_find_best_stream(AVFormatContext *ic, enum AVMediaType type,
int wanted_stream_nb, int related_stream,
AVCodec **decoder_ret, int flags)
{
for (i = 0; i < nb_streams; i++) {
count = st->codec_info_nb_frames; //音频流探测中解码的帧数
bitrate = avctx->bit_rate;//音频流的比特率
multiframe = FFMIN(5, count);
//先比较解码帧数,再比较音频流比特率,谁大谁选
if ((best_multiframe > multiframe) ||
(best_multiframe == multiframe && best_bitrate > bitrate) ||
(best_multiframe == multiframe && best_bitrate == bitrate && best_count >= count))
continue;
best_count = count;
best_bitrate = bitrate;
best_multiframe = multiframe;
ret = real_stream_index;//最后选择的流index
best_decoder = decoder;
}
return ret;
}
在该视频中,我们可以看到:
codec_info_nb_frames | bit_rate | |
---|---|---|
audio_stream 1 | 38 | 122625 |
audio_stream 2 | 39 | 126375 |
第二条流的解码帧数和比特率要比第一条高,因此选择了第二条流播放
2、对比同类方案分析了以上选择规则后,我们对各平台、框架进行了选择规则的对比:
备注:
ffmpeg -i INPUT_FILE -map 0:0 -map 0:2 -map 0:1 -c copy -y OUTPUT_FILE
ffmpeg -i INPUT_FILE_1 -i INPUT_FILE_2 -map 0:0 -map 0:1 -map 0:2 -map 1:0 -c copy OUTPUT_FILE
从以上数据看到,iOS和PC平台会默认选择第一条流,而在Android平台的FFmpeg和ExoPlayer会根据音频流属性来选择数值更好的一条。
但以上2个选择方案都无法识别“内容异常”的音频流。
五、问题解决方案因此,处理该问题,需要从音源上进行修复和规避,我们的建议是从源头杜绝,从终端规避:
相关阅读
wamp2.0配置Zend Optimizer
藏匿在邮件里的“坏小子”
打造一个个人阅读追踪系统
【每日课程推荐】机器学习实战!快速入门在线广告业务及CTR相应知识
此文已由作者授权腾讯云+社区发布,更多原文请点击
搜索关注公众号「云加社区」,第一时间获取技术干货,关注后回复1024 送你一份技术课程大礼包!
海量技术实践经验,尽在云加社区!
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/2703.html
摘要:而影响实时合唱音质的因素主要包括音频采样率码率延时。采样率是每秒从连续信号中提取并组成离散信号的采样个数。采样率越高,音频听起来越接近真实声音。 之前我们解析过很多社交直播App中不同场景的开发,比如在线K歌、小程序直播、多人视频聊天、AR等。 我们最近在知乎看到了一个问题「为什么k歌软件始终没有开发出实时合唱功能?」,我们只在知乎做了简要解读。在这里我们详细来解析其中难点,以及实现的...
摘要:效果以及原文播放地址请求方式参数歌曲,播放列表可以右键查看默认值码率默认最大码率即最高音质返回说明之后实际播放地址中,歌曲前的等为音质歌曲搜索秦时明月请求方式参数参数说明是否必须说明默认值请求秘钥,群号搜索关键词无搜索类型默认为搜索音乐搜 效果以及原文: https://unnue.com/article/46 播放地址 https://api.bzqll.com/music/ten...
摘要:效果以及原文播放地址请求方式参数歌曲,播放列表可以右键查看默认值码率默认最大码率即最高音质返回说明之后实际播放地址中,歌曲前的等为音质歌曲搜索秦时明月请求方式参数参数说明是否必须说明默认值请求秘钥,群号搜索关键词无搜索类型默认为搜索音乐搜 效果以及原文: https://unnue.com/article/46 播放地址 https://api.bzqll.com/music/ten...
摘要:效果以及原文播放地址请求方式参数歌曲,播放列表可以右键查看默认值码率默认最大码率即最高音质返回说明之后实际播放地址中,歌曲前的等为音质歌曲搜索秦时明月请求方式参数参数说明是否必须说明默认值请求秘钥,群号搜索关键词无搜索类型默认为搜索音乐搜 效果以及原文: https://unnue.com/article/46 播放地址 https://api.bzqll.com/music/ten...
摘要:这里要颁发两个年度最佳应用一个是海外的,一个是酷狗音乐,它们暴露了两个很严重的平台漏洞。酷狗音乐遇到的问题。 辞旧迎新。 2018的工作总结一直拖着拖到现在忍不下去了终于扣了半天扣出一个总结。 2018年已经过去,回看,有努力,有成果,也有遗憾,有无奈。 由于不考虑kpi,所以主要总结遗憾和无奈。 最大的遗憾 是立了一个为听障/视障人士开发更满足他们需求的功能交互的flag,结果无疾而...
阅读 742·2021-09-22 15:26
阅读 2073·2021-09-14 17:57
阅读 2331·2021-09-09 11:52
阅读 1581·2021-09-02 09:52
阅读 2069·2021-08-12 13:28
阅读 1048·2019-08-30 15:53
阅读 355·2019-08-29 13:47
阅读 3246·2019-08-29 11:00