[MS-RDPEA]关于时间的信息不足 [英] [MS-RDPEA] Insufficient Information about Timing

问题描述

此问题一直存在于FreeRDP中，并且从未以令人满意的方式解决过。如果通过实验我已经能够在局域网上获得体面的体验，我无法在局域网和广域网条件下完美地工作（或者像bstsc一样好的b $ b）同样的MS-RDPEA实现。即使具有非常高的延迟，mstsc的声音也几乎是即时的。使用FreeRDP，我们通常会在服务器因为不能足够快地发送音频样本而使RDP客户端匮乏的情况下结束，如果我们添加客户端缓冲延迟以开始缓冲几百个音频样本，我们通常会花费
播放前的毫秒数。

2011年有一个帖子澄清了"消费"的事实。在MS-RDPEA中意味着播放wave pdu中包含的音频样本：

http://social.msdn.microsoft.com/Forums/en-US/ a05987a8-232b-4aec-a361-5060b96ed851 / msrdpea-is-there-any-to-ask-next-wave-pdu？forum = os_windowsprotocols

我已经非常努力地试图最终找到底线，但MS-RDPEA
仍然是个谜。以下是我在局域网上使用mstsc进行音频播放的手动分析：

https://docs.google.com/spreadsheet/pub?key=0Au9cKlQduz0IdEdBUlk0S2pxZzNVTzViejE4S3IwUWc&output=html

在电子表格中，我有网络的时间戳数据包，波数据中包含的时间戳和波确认pdus，大量时间差，平均值等。我是100％正数我根据格式
数和数据包捕获正确计算了音频采样持续时间。但是，似乎mstsc在捕获过程中应该跳过几次，而不是。我观察到的一件事没有在任何地方记录，音频样本的持续时间与b b接收波数据pdu和发送回波确认pdu之间的时间差异明显很强。平均而言，它们非常非常关闭（185ms，183ms）。

从我所知的所有这些中，这里应该是正确的：

1）波形数据和波形确认pdus中使用的时间戳以毫秒为单位。客户端和服务器之间没有时间值的同步，客户端只是使用传入的时间戳值，并在发送回波形确认pdu时向其添加时间差（以毫秒为单位）
。

2）用于波形确认pdu中返回的时间戳值的时间差应该对应于接收波形pdu与消耗（播放）相应音频数据的时间之间的时间差。如果我理解正确的话，波浪确认pdu
也应该在那个确切的时间发送。时间戳值和波确认发送pdu的时间都是服务器用来确定何时发送下一波pdu的有意义信息。

3）AFAIK，时差利用客户端接收波pdu而不是波数据pdu的时间。我不确定这是否真的如此，因为两个pdus之间通常有几毫秒的差异。手动分析显示
表示与波形数据pdu开始的时间差更强的关系，但规范提到了wave pdu。

4）音频样本是发送两个pdus而不是一个是奇怪的，根据规范，没有任何有意义的东西似乎与它相关联。我怀疑wave数据pdu有更多的东西，然后只是在wave
pdu之前传递的一些信息，并且会欣赏更多细节。

5）实验上，它已确定简单地通过在未来模拟时间添加音频持续时间+ 65ms来发送波确认pdu，其中相应的音频样本将完成播放在LAN上相对较好地工作，
但不是在所有情况下。出于某种原因，神奇的数字65在各种分析中不断反复出现。我完全不知道为什么，但是在65左右有一些对RDP服务器有意义的东西。也许mstsc使用大约65ms的缓冲时间
？

6）我别无选择只能通过反编译来了解mstsc正在做什么。我发现有点令人惊讶：代码要求定时器分辨率为10ms，当接收到波数据pdu和
wave pdu时，显然需要使用GetTickCount（）的时间戳。它还在音频样本播放完毕后调用GetTickCount（）并发送wave confirm pdu。它还具有非常先进的功能，例如计算抖动缓冲区大小，"远程呈现时间"，还具有进行音频视频
同步的代码。每当接收到新的波pdu时，还有一个定时器被重置。如果计时器在1秒后到期，则这似乎被解释为"关闭"。由mstsc。尽管MS-RDP规格都有
文档计时器的部分，但MS-RDPEA中的部分是空的。如果有一个规范需要大量的定时器和时序记录，那就是MS-RDPEA。还有从MS-RDPEA代码中获取的以纳秒为单位的非常高分辨率时间戳的功能。

我们是否可以获得有关MS-RDPEA的更多详细信息，尤其是完成明显缺乏有关MS-RDPEA的信息定时？服务器对于非常微妙的时间变化似乎非常敏感。例如，服务器如何确定客户端
无法足够快地使用数据，因此决定将音频格式更改为较低质量的内容？我没有在规范中看到记录这种行为的任何内容。

我可以发送与我已完成的手动分析相对应的数据包捕获。

祝你好运，

- Marc-Andre

解决方案

< blockquote>

嗨Marc-Andre，

感谢您的提问。 协议团队的工程师将尽快与您联系。 继续发送您认为对Dochelp别名有帮助的任何痕迹。

Hi,

This issue has always been present in FreeRDP and has never been solved in a satisfactory way. If experimentally I've been able to get a decent experience on the LAN, I've never been able to get the same MS-RDPEA implementation to work flawlessly (or as good as mstsc) in both LAN and WAN conditions. Even with very high latency, sound is always almost instant with mstsc. With FreeRDP, we more often than not end up in cases where the server starves the RDP client by not sending audio samples fast enough, even if we add a client-side buffer latency to start buffering audio samples for a few hundred milliseconds before playing it.

There was a thread in 2011 which clarified the fact that "consumed" in MS-RDPEA meant playing the audio sample contained in a wave pdu:

http://social.msdn.microsoft.com/Forums/en-US/a05987a8-232b-4aec-a361-5060b96ed851/msrdpea-is-there-anyway-to-ask-next-wave-pdu?forum=os_windowsprotocols

I have been working very hard to try to finally get to the bottom of this, but MS-RDPEA still remains a mystery. Here is a manual analysis of audio playback with mstsc on the LAN I did:

https://docs.google.com/spreadsheet/pub?key=0Au9cKlQduz0IdEdBUlk0S2pxZzNVTzViejE4S3IwUWc&output=html

In the spreadsheet, I have the timestamps for the network packets, the timestamps contained in the wave data and wave confirm pdus, lots of time differences, averages, etc. I am 100% positive I computed the audio sample duration correctly based on the format numbers and the packet capture. However, it would seem that mstsc should have skipped a couple of times during that capture while it didn't. One thing I observed that isn't documented anywhere is the apparent strong link between the duration of audio samples and the time difference between receiving the wave data pdu and sending back the wave confirm pdu: on average, they are very very close (185ms, 183ms).

From what I have understood out of all of this, here's what is supposed to be correct:

1) Timestamps used in the wave data and the wave confirm pdus are in milliseconds. There is no synchronization of time values between the client and the server, the client simply uses the incoming timestamp value and adds a time difference in milliseconds to it when sending back the wave confirm pdu.

2) The time difference used for the timestamp value returned in the wave confirm pdu should correspond to the time difference between receiving the wave pdu and the time at which the corresponding audio data has been consumed (played). The wave confirm pdu should also be sent at that exact time if I understood correctly. Both the timestamp values and the time at which the wave confirm pdu is sent are meaningful information used by the server to determine when to send the next wave pdu.

3) AFAIK, the time difference makes use of the time at which the wave pdu, not the wave data pdu, was received by the client. I am unsure if this is actually true, as there is often a few milliseconds of difference between the two pdus. Manual analysis appears to indicate a stronger relationship with the time difference starting with the wave data pdu, but the spec mentions the wave pdu.

4) The fact that audio samples are sent in two pdus instead of one is odd and per the spec nothing meaningful appears to be associated with it. I suspect the wave data pdu has more to it then just being some information being passed on right before the wave pdu, and would appreciate further details.

5) Experimentally, it has been determined that simply sending a wave confirm pdu by adding the audio duration + 65ms at the simulated time in the future where the corresponding audio sample would have finished playing works relatively well on the LAN, but not in all cases. For some reason, the magic number 65 keeps coming over and over again in all sorts of analysis. I have absolutely no idea why, but around 65 there is something which appears meaningful to the RDP server. Maybe mstsc uses a buffering time of approximately 65ms?

6) I had no choice but to try and understand what mstsc was doing by decompiling it. What I found is a bit surprising: the code requests a timer resolution of 10ms, takes timestamps with GetTickCount() apparently when both receiving the wave data pdu and wave pdu. It also calls GetTickCount() when an audio sample has finished playing and sends the wave confirm pdu. It also does quite advanced stuff like computing a jitter buffer size, a "remote presentation time", and also has code to do audio video synchronization. There is also a timer which is being reset every time a new wave pdu is received. If the timer expires after 1 second, this appears to be interpreted as a "close" by mstsc. Despite the fact that MS-RDP specs all have sections to document timers, the one in MS-RDPEA is empty. If there's a spec that needs extensive documentation of timers and timing, it's MS-RDPEA. There is also functions for taking very high resolution timestamps in nanoseconds called from MS-RDPEA code.

Could we get a lot more details regarding MS-RDPEA, especially completing the obvious lack of information regarding timing? The server appears extremely sensible to the very subtle changes in time. For instance, how does the server determine that the client is unable to consume data fast enough and therefore decides to change audio format to something of lower quality? I don't see anything in the spec documenting such behavior.

I can send the packet capture that corresponds to the manual analysis I've done.

Best regards,

- Marc-Andre

解决方案

Hi Marc-Andre,

Thank you for your question.  An engineer from the Protocols Team will contact you soon.  Go ahead and send any traces you think are helpful to the Dochelp alias.

这篇关于[MS-RDPEA]关于时间的信息不足的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！