插件式架构设计演义 - 序

从单一功能到复杂需求,本文回顾了流媒体系统的发展历程。最初仅支持PS封装及MPEG2/MPEGA编解码,后逐步扩展至多种封装格式、编解码标准及输入源类型。面对日益增长的需求,传统架构难以应对,引入插件式架构成为解决问题的关键。

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

 

花开花落,花落花开,少年子弟江湖老,转眼步入流媒体领域已有些年头了。

初入该领域的时候,由于需求比较单一, 流媒体的封装只要求PS的,编解码格式为MPEG2/MPEGA,

输入源为RTSP/RTP或者UDP Multicast, 核心的Parser(Framing)/Demuxer/Decoder代码又由芯片厂商以2进制的形式提供,基本工作也就是在上层实现一个媒体播放的控制状态机实现以及数据缓冲区的管理,所以那时流媒体架构什么的觉得是浮云,没什么概念,基本上只要把功能实现就行了,还有就是修修BUG,改善下性能,至于扩展性,通用性,灵活性,低耦合这些东东根本就考虑甚少,甚至就不考虑,呵呵。

 

慢慢地,不知不觉中,情节很老套,产品需求不断增加,且看:

封装:除了PS,还要支持TS了。
音视频编解码格式:从最初的MPEG2/MPEGA, 增加了MPEG4, H264/MPEG4-AVC, WMV,MP3, AAC, AC3, DTS...
流输入源:不单单是RTSP和Multicast了,还要HTTP, 本地文件,RTP扩展, 模拟Tuner,

           数字Tuner, Interleaved, Flash, DLNA...
由于刚开始没有考虑到扩展性,软件的耦合度又高,要付出代价了,每增加一个功能需求都要费老大的劲,而且各功能之间相互干扰,代码越改越乱,几乎成了一团浆糊。更要命的是,由于系统越来越庞大,增加或者修改东西的难度越来越大,越来越不容易维护...

 

难道是山穷水尽了吗? 古云, 穷则变,变则通。实际上, 方法不是木有, 但要看你是否有信心,有条件引入一个全新的媒体架构 - 插件式架构。
插件式架构是神马,哈哈,卖个关子先, 欲知后事如何,且听下回分解。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值