流媒体:
由于原来小搞过一点点DirectSound的经验,外加一点点小小的网络实践.自己想出一个套路.从文件格式,DS,压缩加密,协议命令,以及各种服务器技术似乎都要涉及.(简单为主,不挣钱的活谁干,除非自己喜欢..)
首先,如果不借助其他sdk或者声音引擎的话,基本上很难自己开发.DirectSound可以满足"自定义"的声音,可以自己写入缓冲区然后lock播放.可以在此之前添加各种虑镜(好像有人叫DFS还是什么来着,都是类似的,我叫虑镜习惯了..)
其次,如果你不打算使用wav的话(废话,体积那么大)需要自己涉及一套适合网络传输的协议,不要给我说zip那类,我们要得是即时的,或者说是有损的,我们的buffer应该尽量的小.相反的,网络缓冲要尽量的大,这样才能保证"不卡"(至少点播的时候有用,比如realone的绿条,可以用总是缓冲)
第三,有了自己的压缩格式,最终为了播放还要还原成riff进行ds缓冲区的填充.当然不压缩也可以,毕竟仅仅是为了探讨他的实现,压缩部分点到即止就可以了,同样的,加密也是在这里做手脚,比如我们全部mask一个hash(如果直接播放的话也能听见...不过这种虑镜加的....)
第四,客户端创建足够的网络缓冲,根据点播以及广播的不同,略有一点点不同,广播的延迟不能太大(也就是说,我们的广播不是直播,速度还是要慢几秒的)
第五,服务器.多人的比较麻烦.对了,大家还记得IE跟IIS吗.他们用的是http协议,用Media Player Classic或者其他播放器也是可以点播的,而且不是下载整个文件的,不信你可以试试.协议的最终目的还是更好的传输数据.同时说明如果你不想使用自己的协议,可以参照其他协议,然后你自己做一个客户端读取数据也行.但是,貌似自己做一个简单的协议比使用http的要简单很多(个人看法)直接新建socket然后发送简单的get seek find..就够用了.端口可以临时new,实际上对于服务器的性能而言,几百人也就是极限了,实在不行一开始就直接全部用数组创建也行,还能少不少麻烦.(-_-b 貌似扯远了)
第六,协同起来.服务器就是传输数据的,如果说做的更多,无非就是负载均衡,多线程之类复杂的东西了,那个就....要慢慢研究了,不是难不难的问题,而是过程复杂.整体无非就是以下步骤:
1服务器开始监听
2客户端启动
3用户输入
4客户端向服务器发出请求
5建立连接开始传输,同时根据客户的需求选择相应的压缩(音质不同)
6.1 服务器发送数据 6.2客户端填充网络缓冲区
7客户端开始播放,同时保持连接继续传输数据
8停止,断开连接(完毕,异常)
9客户端播放缓冲区剩余的内容(或者停止)
整体似乎就是这么简单,我打算用VB.NET(2k3)+ DX9SDK(05summer)做.中间用的就是wav的网络播放,虽然看起来是p2p的,但是毕竟还是CS啊.最多同时支持两个用户,因为不想牵扯多socket多线程太多.
如果要想设计的更加合理一点,那么各种插件都要预留接口,比如那个压缩,完全可以独立出来,然后根据客户的请求选择相应的压缩/加密dll.这个就是架构设计了.我们用的是1服务端,2服务器,目的是要讨论实现,所以那种大型架构不用考虑...(哪有那么多时间...再说几百人也就是极限了)