* direct passthrough of MJPEG announced
* allow frame drops for MJPEG
* drop samples if encoding fails
* add verbose/debug logging of delayed and dropped frames
- This issue was introduced in FreeRDP/FreeRDP@32e64c1e98
- If a sample request is received from the server before the camera
provides one, an assertion is triggered because an invalid sample is
attempted to be sent as a response, as the default initialization of
`stream->pendingSample` sets its `length` to its `capacity`.
Before this patch we had a behavior where there was a credit of 8 samples that
could be sent to the server with no corresponding sample request. So in the right
conditions, we were having situations where the server was receiving samples that
it has not requested, and so it was dropping them. The visible effect was small
artifacts in the camera stream when i-frames where dropped, and more serious ones
when the dropped content was containing key frames.
This issue has also been reported when xfreerdp connects on g-r-d as #11990.
This patch reworks the frame grabbing workflow: when the frame grabbing thread calls
the sample callback we check if a sample is already pending, waiting to be sent to the
server. If that's the case and the camera's input format supports frame dropping we just
refresh the pending frame with the new one. If the input format can't drop frames (like
with h264 and mjpg) we wait until the current pending frame is sent.
So now frames can be sent either when we receive a sample request from the server,
or when the sample callback is invoked.
This patch adds the handling of basic NTLM commands. Because there's some mysterious
4 zero bytes after pickle header in Kerberos packets, not present in NTLM commands, the
patch also had to rework a bit the packet parsing / forging.
The patch also addresses a server-side bug when parsing supplemental creds, if the client
was sending an empty list, we were considering this as an error.
And finally we also implement the parsing of MSV1_0_REMOTE_SUPPLEMENTAL_CREDENTIAL.
This breaks the public API, anyway this was basically unused (as not parsed before) and
the previous API was wrong as what we receive is MSV1_0_REMOTE_SUPPLEMENTAL_CREDENTIAL
not MSV1_0_SUPPLEMENTAL_CREDENTIAL, so I guess the API breakage is ok.
This commit fixes following performance issues in the drive channel:
- `GetFileAttributes` functions where using `FindFirstFile` to query
attributes. The same can be achieved with `stat` and reusing the
existing stat <-> file info conversion code.
- `drive_file_query_information` was calling `CreateFile` on directories
which will always fail with the given parameters.
This patch adds Activate and Deactivate callbacks to the HAL, matching the messages
exchanged on the channel. This is to prepare the support of a windows HAL using the
microsoft media fundation framework.
the length field did change a lot during the eveolution of the protocol.
Be lenient on values that might occur as long as they satisfy the
basic requirements.
If a channel is deactivated, delete the client and server options (e.g.
reset them to default) to avoid having something like
CHANNEL_NAME=OFF AND CHANNEL_NAME_CLIENT=ON
