[MS-RDPEGFX]:
3.2.5.13 Processing an RDPGFX_FRAME_ACKNOWLEDGE_PDU message
If the queueDepth field is less than 0xFFFFFFFF, the server MUST expect that
RDPGFX_FRAME_ACKNOWLEDGE_PDU messages will continue to be sent by the client.
Furthermore, if the queueDepth field is in the range 0x00000001 to 0xFFFFFFFE the server SHOULD
use this value to determine how far the client is lagging in terms of graphics decoding and then
attempt to throttle the graphics frame rate accordingly.
If the queueDepth field is set to SUSPEND_FRAME_ACKNOWLEDGEMENT (0xFFFFFFFF), the server
MUST clear the Unacknowledged Frames (section 3.2.1.2) ADM element and MUST NOT expect any
further RDPGFX_FRAME_ACKNOWLEDGE_PDU messages from the client. In this mode, the server
MUST NOT wait or block on unacknowledged frames (as the
RDPGFX_FRAME_ACKNOWLEDGE_PDU message is not sent by the client) and MUST assume that
the client is able to decode graphics data at a rate faster than it is receiving frames.
On the other hand, RDPGFX_QOE_FRAME_ACKNOWLEDGE_PDU SHOULD only be used for informational and debugging
purposes and should not be taken into account.
1. Export fps related API so that subsystem implementation no longer need to know about details in encoder structure.
2. Discard frameList dictionary.
The 'value' in this dictionary is never used and not properly free'ed when client is disconnected.
The dictionary was used to calculate 'inflight' frame count. Once an ACK is received from client, an item in the dictionary is removed.
We then calculate 'inflight' frame by the count of the items in the dictionary.
However, some rdp clients (win7 mstsc) skips frame ACK if it is inactive, ACK of some frame would actually never arrive.
We actually don't need the dictionary. We only need to record the latest acknowledged frame id, and the difference between last sent frame id is the inflight frame count.
3. Minor fix in default fps calculation. encoder->frameAck is wrongly used as integer while it's actually bool flag.
