* 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 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.
