Leverages libavcodec's hw decode support to provide VA-API based
hardware decoding. Depends on the local build of ffmpeg having hardware
VA-API support compiled in and the appropriate libva drivers and
libraries installed.
If we apply -mssse3 to files that don't need it, gcc may automagically
generate instructions that will not run on certain CPUs. This breaks the
runtime feature detection code (IsProcessorFeaturePresent).
Fixes: https://github.com/FreeRDP/FreeRDP/issues/4308
My method was to find the LIBAVUTIL_VERSION_* at the commit where the
updated AV_ prefixed constants became available, add one "micro" version
to it, then if it's not at least that version, provide the unprefixed
constant. It just so happens that the same commit introduced all
the AV_* constants.
The AV_ prefixed constants have been available since
ffmpeg@def97856de6021965db86c25a732d78689bd6bb0 (2015-07-07), or version
2.8.
The non-prefixed constants are set to be removed in the next ffmpeg
release, and were removed in
ffmpeg@302554835e39b79b977ed60c9afe81b44590dfef (2016-12-05).
Since ec027bf dynamic resolution is broken when used with egfx. Before that commit
we were tracking a server sent resize by setting a DesktopResize callback. This callback
is called when the desktop is resized by the server. Anyway the problem was that when this
callback is called, the activation sequence is not always completed, which were leading to
some freeze with 2012r2 servers (sending packets before the sequence is finished).
So with the faulty commit, we are tracking server resizes by subscribing to the Actived
event, that is called at the end of a reactivation sequence, so we're sure to not send packets
when not fully activated.
Anyway the issue that shows on (#4330) is that when you use egfx, no reactivation sequence happens,
the server only sends a ResetGraphics message with the new size, and so we miss the resized event.
This fix introduces a new GraphicsReset event, makes the display channel subscribe to that event,
and react accordingly.
The coordinates from RDP ROP commands do not (always) have
0,0 as the origin of the drawing operation.
Adjust the coordinates to our local coordinate system.
