我想写一些类似Skype的东西,也就是说,我在一台计算机上有一个固定的音频流,然后以一种适合潜在互联网连接的格式重新压缩它,在另一端接收它并播放它。
让我们也假设互联网连接是相当现代和快速,即DSL或类似,没有缓慢的连接电话等。所涉及的计算机也将相当现代化(2 2GHz或更高的英特尔双核CPU)。
我知道如何处理机器上的音频。我不知道的是如何以有效的方式传送音频。
挑战是:
如果我想使用现成的软件进行压缩和传输,我的选择是什么?我不打算写我自己的音频压缩引擎,真的。OTOH,我计划在垂直市场上销售这个解决方案,这意味着我可以支付每本几美元的许可费,但不能支付1000美元。
我想最简单的解决方案是打开TCP流,来回发送几个数据包以确定它们的运行时间(甚至使用UDP ),然后使用结果作为我的最大延迟值的指南,然后简单地用原始形式的音频数据(未压缩的16位立体声),以及TCP连接上的定时代码。接收器读取数据,并与预定的延迟播放它。这可能只适用于我所期望的那种快速连接。
我只是想知道是否有更好的解决方案来达到这个目标,具有更好的性能(更低的延迟)和更少的数据(压缩)。
顺便说一句,我首先尝试在OS上实现这一点,但如果它被证明是成功的话,我可能也想在Windows上实现它。
发布于 2008-12-23 22:46:49
为了在因特网上传输音频,您可能应该考虑使用RTP。它用于SIP,H.323,和许多其他人使用这个流音频内容。您甚至可能希望只使用。它已经有很多你想要的东西了。如果您有一个好的编解码器和足够的带宽,啜饮可以有相当好的质量。
发布于 2008-12-23 21:42:03
VLC支持各种类型的音频和视频转码。可能是你想检查的东西。
发布于 2011-07-18 09:12:20
我知道线程是善良的--然而,我想要与您分享的一个古老的洞察力是:您不能为此使用TCP,因为您需要延迟--您说了1秒是可以接受的,因此我假设超过1秒是不可接受的。
您使用TCP的延迟不是由PING来确定的。TCP的问题在于,当您连接时,您接受使用某些延迟,任何连接问题都会缩小TCP窗口,所有接收到的数据都将被删除,底层协议将不得不处理它。此时,您将失去您的1秒优势的实时和流将被丢弃。
TCP适用于大延迟可接受的情况(例如10秒或更长时间),这将使您在重新建立连接之前始终有足够的数据可供吃和播放。
如果我站在你的立场上,我会尝试以下几点:
顺便说一句,mp3的帧长40毫秒。有了一些“魔法”,你就可以掩盖掉的画面。
https://stackoverflow.com/questions/390127
复制相似问题