会议电视项目积累笔记1(项目整体感受). -----写在离职3天记,2008-7-6。

本文分享了作者在MCU项目中遇到的音频处理难题及解决方案,特别是针对AAC宽带语音引入后产生的音视频不同步问题进行了深入探讨。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

         在****的这段时间里,我一直在做MCU项目的音频媒体处理部分的维护和开发工作;对MCU整个系统并不是很纯属,只能达到了解的程度而已,而只对音频处理软件部分达到熟练的程度。         在工作一天一天深入,对系统软件了解一步步透彻;许多客观的设计问题被暴露出来,或许更应该叫做需求变动吧。比如,设计之初可能没有考虑在以后会加入AAC宽带语音,而后面需求提出要增加才临时加进去的,从表面上看增加一种音频类型没有什么大不了,我也可以正确并正常的处理AAC类型音频,但更深层次的问题在系统测试后暴露出来了,由于AAC音频类型在处理上的延迟造成音视频唇音不同步现象,影响整体系统应用;后来在几个版本稳定提交之后又回过头来解决唇音同步问题,但由于设计上的某些限制,一直到我离开都没有达到系统的延迟要求;这个事情其实我挺遗憾的,我在之前半年都有离开的想法,但一直想将自己接手这部分软件稳定下来,解决所有问题后离开,唇印同步问题当时就是我自己定的目标,但现实并不乐观,确实在应用软件层面已经费尽力气也缺的了很大的改观,但离系统要求还有很大的差距。不过走之前对系统的改进方向提出了一些建议,个人觉得还是很有用的。         MCU产品需求变动太快,并且认为随即处理情况较多。有时我们在做一个新功能前时间等已经给出,但到预定时间很多时候都不能按时完成,这种情况下只有延期或放入下一版本合入,但实际这样没有太大意义并且容易影响开发人员习惯,应该按照客观的实际评估工作量,尽量合理一些,而不是夸张的要求。         在MCU项目,各个模块人员配合不够高效,主要是由于将MCU各个模块固定分配给某个人,这样造成每个人只熟悉本模块而对其他不了解,不利于定位和解决系统故障。应该建立一种开放式的开发环境,既按照独立负责模块的垂直方式和联合调试功能的平行方式,这样每个人既负责好了自己的模块又可以在功能的层次对其他模块了解的更透彻。         从MCU这个项目我至少得出一个结论: 很多时候并不是主观的能力决定产品的成败,而更多的在于那些非技术的部分。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值