我正在尝试创建一个实时广播音频和视频的 RTSP 客户端。我在链接http://www.gdcl.co.uk/downloads.htm修改了 iOS 代码，并能够正确地将视频广播到服务器。但是现在我在播放音频部分时遇到了问题。在链接示例中，代码的编写方式是将视频数据写入文件，然后从文件中读取数据并将 NALU 的视频数据包上传到 RTSP 服务器。
对于音频部分，我不确定如何进行。现在我尝试的是从麦克风获取音频缓冲区，然后通过添加 RTP 标头和 ALU 直接将其广播到服务器。但是这种方法无法正常工作，因为音频开始滞后并且随着时间的推移滞后增加。有人可以告诉我是否有更好的方法来实现这一点并使用唇形同步音频/视频。
您是否丢失了客户端上的任何数据包？如果是这样，你需要留下“空间”。如果您收到数据包 1、2、3、4、6、7，您需要为丢失的数据包 (5) 留出空间。
另一种可能性是所谓的时钟漂移问题。您的客户端和服务器上的时钟（水晶）彼此并不完全同步。
这可能是由环境、温度变化等引起的。
假设在一个完美的世界中，您的服务器正在以 48000 赫兹生成 20 毫秒的音频样本。您的客户正在使用 48000 赫兹的采样率播放它们。实际上，您的客户端和服务器并不完全是 48000hz。您的服务器可能是 48000.001，而您的客户端可能是 47999.9998。因此，您的服务器可能比您的客户端交付速度更快，反之亦然。您要么消耗数据包太快，导致缓冲区运行不足，要么落后太远，导致客户端缓冲区溢出。在您的情况下，听起来客户端播放速度太慢并且缓慢落后于服务器。您可能每分钟仅滞后几毫秒，但问题将继续存在，并且看起来像是 1970 年代口型同步的功夫电影。
在其他设备中，通常有一条公共时钟线来保持同步。例如，摄像机时钟、midi 时钟。多轨录音机时钟。
当您通过 IP 传送数据时，客户端和服务器之间没有共享时钟。因此，您的问题涉及在不同设备之间同步时钟而没有。我已经使用这种通用方法成功解决了这个问题：
因此，您的客户要求您调整播放的采样率。所以是的，你玩得更快或更慢。请注意，播放速率的变化会非常微妙。您可以将采样率设置为 48000.0001 赫兹而不是 48000 赫兹。人类无法察觉音高的差异，因为它只会导致音高的一小部分差异。我解释了一种非常简化的方法。在开发这样的控制系统时，还必须考虑许多其他细微差别和边缘情况。你不只是设置它并忘记它。您需要一个控制系统来管理播放。
证明这一点的一个有趣的测试是使用两个具有完全相同文件的设备。长时间录音（比如 3 小时）是最好的。同时启动它们。播放 3 小时后，您会注意到一个领先另一个。
这篇文章解释说，流式传输音频和视频并非易事。