直播带货短视频商城系统研发过程中音视频的技术细节之处以及消息收到发送的整个流程

今日的短视频直播带货行业异常繁荣，各类带货主播犹如雨后春笋般涌出将网红行业捣了个稀巴烂，将微商甩到一边，注定要唱主角。在以抖音、火山、快手、淘宝直播等app为代表的短视频直播软件中，我们可以找到哪些学习的点呢？今天让我们来剖析整个详细过程，另外如果想要搭建一个好用安全的短视频直播软件，别忘记联系所罗门app哦！

短视频直播开发系统中详细的视音频细节技术

1.采集的码率

因为各种用户的硬件、设备不同；要做到码率与网速、硬件适应的同时

传输高帧率、品质的画面 。、

2.播放

播放功能要做到随时能够暂停中段，同时存储之前直播的时间作为录像显示也是一门学问。分有不同的播放协议如 http播放器，flash播放器

3.转码详细过程

由于要适配的机型和网路有异，转不同的码率的难度、方法不同。

具体有架设私有服务器、或者在公有服务器云上操作。例如腾讯云、百度云、七牛等。还有分发给各CDN结点等。

短视频直播开发系统消息的流程

1.投递之前消息先被检查

2.消息形成队列，高的谷被削平，低的谷被填满

3.多任务处理机制下多消息同时发送

4.木桶效应，最短决定短板

5.消息的发送方处理成空白

 

 

 

三、消息队列的优缺点对比

 

优点：解耦、异步、削峰

系统可用性降低：系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好，如果ABCD四个系统好好的，没啥问题，突然加个MQ进来，万一MQ宕机，整套系统崩溃，就不好处理了。

 

系统复杂性提高：在突然加入MQ以后，如何能够保证消息没有被重复的利用消费？怎么处理消息在遗失后情况、怎样确保消息传输的前后性？BUG堆叠而来，令人头疼。

 

一致性问题：A系统处理完了直接返回成功了，大家都以为请求被接收，successful；但是问题来了，如果BCD三个系统的地方，BD两个系统写库成功了，结果C系统写库失败了，数据就会产生差异，就不一致了