Chinaunix

标题: 求给对方播放影音文件功能的实现方法 [打印本页]

作者: chinesedragon 时间: 2013-01-12 16:47
标题: 求给对方播放影音文件功能的实现方法
求给对方播放影音文件功能的实现方法

最近要实现一个给对方播放影音文件功能的软件，影音文件格式目前以WAV做例子，以后会扩展到MP3、WMA等多种文件类型，平台是Windows平台，使用的的方法是waveInXXX和waveOutXXX等API函数。
现在的实现方法是这样的，在本方读取一个WAV文件，将WAV数据通过UDP发送给对方，对方接收到数据后放入缓冲区，然后调用waveOutWrite函数将声音播放出来。
现在的问题是由于在接收方开辟的缓冲区数量是一定的，如果本方WAV数据发送比对方播放得快则会接收方缓冲区用完而导致丢数据，如果本文WAV数据发送比对方播放得慢则会出现声音不连续情况，如何能够让双方比较配合地完成这一功能呢？
本方发送WAV数据对方回复这种交互方式不可用，因为本文可能会同时给多个接收方发送WAV数据。

作者: cokeboL 时间: 2013-01-12 20:34
本帖最后由 cokeboL 于 2013-01-12 20:35 编辑

回复 1# chinesedragon

播放前预算传送速度和预传，比如对方点歌，一般都要缓冲10秒左右或几秒至少，这段时间，可以做的事情：

1.有花3、4秒测试点对点最大传送速度（点对多也是多任务每个点对点），然后计算出比较合理的速度s，s满足：
播放连续要求的最低速度 <= s <= 最大传送速度

2.以测得的速度预传一段过去

丢包、重传那些在客户端发命令

俺瞎说的，不知道有用没

作者: cokeboL 时间: 2013-01-12 20:42
预传的可以让对方保存临时文件再解析，预传的大小也可以根据播放需要的

速度计算出一个合理值，然后预传多少后就可以播放了

酷我那些听歌的时候好像都要缓冲呢

作者: hellioncu 时间: 2013-01-12 21:37
为何不用现成的流媒体协议？

作者: starwing83 时间: 2013-01-12 21:51
回复 4# hellioncu

rtp/rtsp也要有实现吧？推荐一个开源的？

作者: hellioncu 时间: 2013-01-12 22:01

starwing83 发表于 2013-01-12 21:51
回复 4# hellioncu

我不做这行，也没研究过，只是觉得这种不应该自己来创造轮子。
搜索开源流媒体服务器还是能找到一些的。

作者: starwing83 时间: 2013-01-12 22:10
回复 6# hellioncu

代码都很专，没什么复用性。

这个东西安卓自己的源代码里面都很缺，我和@mci2004有段时间一起研究过，他比较有发言权。

关键是，这个东西和你自己的需求联系太紧密了，无论什么实现你都得修改一点地方，或者写一点适配代码（和webkit那种很像），所以开发量还是会很大。

当然完全不反对研究流媒体协议，以及采用现有的代码（如果有的话……反正我没找到好的），这个就算对自己设计协议也是有指导作用的。

作者: mci2004 时间: 2013-01-12 22:51
回复 7# starwing83

你太看的起我了，现在的问题是光有 rtsp是不够的，rtsp协议只负责传啊。

问题是要让对端知道什么时候开始传，传什么... 想想看我们用手机打视频电话的时候（擦，直接用VOIP比较容易描述），在VOIP的时候不就是要跟对端传音频和视频吗？参考下 VOIP用到了那些协议。

LZ，现在肯定是想做个现成的简单的出来，肯定是不想被各种协议烦。那么让我想想....... 唉，越想越复杂越来越多的东西要考虑。lz，知道ffmpeg吗？算了，感觉说起来就很麻烦，LZ肯定是没兴趣听的。

作者: chinesedragon 时间: 2013-01-13 20:15
@cokeboL @hellioncu @starwing83 @mci2004
首先感谢各位的回复！
现在的流媒体协议确实是太复杂了，况且我们还有一些自己的功能，比如控制供电、控制音量等。因为我们所有人都是刚接触这个业务，所以确实不能太复杂了。
所以我觉得还是预传比较适合我们，因为我们这个并不是两个PC端的应用，而是PC对单片机，正如我在一楼描述的，由于缓冲区是一定的，预传一定数据后，再以一个合适的速度传输，现在的问题就是这个合理的速度应该怎样去确实，而不会使单片机一端的缓冲区满了或者空了。

作者: starwing83 时间: 2013-01-13 20:37
回复 9# chinesedragon

你怕不怕浪费带宽？

不怕的话，每次发送都要一个ACK，然后没有ACK的段会被安排重发（ACK之前的段就不会被重发了——都ACK了，证明前面的要么缓存了要么播完了，就无所谓了）。

客户端有一个缓冲区，缓冲的包在这里发送ACK，满了直接丢包，服务器会不停地给你发的。

同样的原理可以用在客户端，反过来即可，稍微节省带宽一点。

（其实你就直接用TCP就行了魂淡……）

作者: cokeboL 时间: 2013-01-13 20:40
回复 9# chinesedragon

缓冲区多大？播放速率？

作者: chinesedragon 时间: 2013-01-14 08:03

cokeboL 发表于 2013-01-13 20:40
回复 9# chinesedragon

缓冲区是循环缓冲区，20个8192的，数据是双声道16位的44.1K的WAV文件

作者: chinesedragon 时间: 2013-01-14 11:54
谁能给一个更好的指导啊

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)