Currently, all Calista Progressive encoded streams contain tile
artifacts, when the RFX_SUBBAND_DIFFING is used, but not the
RFX_DWT_REDUCE_EXTRAPOLATE flag.
The reason is the wrong usage of the context and tile flags.
The RFX_SUBBAND_DIFFING flag should have no actual impact on the
decoder itself.
Especially, it does not affect the band sizes within a 64x64 tile.
The RFX_DWT_REDUCE_EXTRAPOLATE flag, on the other hand, MUST have an
effect on the band sizes.
However, FreeRDP currently uses the RFX_SUBBAND_DIFFING flag when
decoding a component to determine whether the Reduce-Extrapolate method
is used, resulting in tile artifacts, when that method was actually not
used.
The current behaviour did not result in tile artifacts with the MS
Windows RDS, as that server always sets both flags.
So, fix this issue by using the correct flag, when decoding a tile.
According to the RFC the websocket key in the request header should be
base-64 encoded:
The request MUST include a header field with the name |Sec-WebSocket-Key|. The value of this header field MUST be a nonce consisting of a randomly selected 16-byte value that has been base64-encoded (see Section 4 of [RFC4648]). The nonce MUST be selected randomly for each connection.
If we just send a random key this might cause problems with
gateways/proxies that try to decode the key, resulting in an error (i.e.
HAProxy returns 400 Bad Request).
Microsoft Windows imposes strict filename restrictions on its platform.
As RDP is developed by Microsoft and the RDS in MS Windows is typically
used as remote desktop server for the RDP protocol, these filename
restrictions are also enforced in WinPR, when copy-pasting files over
the clipboard.
However, in some connections no peer on MS Windows is involved and in
these situations, these filename restrictions are just an annoyance.
With a recent API addition in WinPR, it is now possible to override the
callback, where the filename is checked, whether it is valid.
So, use this new API to relieve the filename restriction, when the
connected remote desktop server is not on MS Windows.
With LibreSSL 2.7.0 (or newer versions) some more structs have made
opaque, which requires a few changes:
- BIO_meth_new() and related functions are now defined by LibreSSL, the
versions from opensslcompat.{h,c} does not need to be used anymore.
- HMAC_CTX is now opaque, HMAC_CTX_new(), EVP_MD_CTX_new, and related
functions should be used instead in winpr's hash.c.
commit ec699f6c75 moved the array
allocation into display_convert_rdp_monitor_to_monitor_def without
updating its only call site.
This leads to display_convert_rdp_monitor_to_monitor_def failing
because the array already exists.
This allows server implementations to add handling for situations,
where the client side does not support them.
Particularly useful for the audio output channels (static channel as
fallback, when dynamic channel is not supported).
* core: correctly handle console mode server-side
In server-side we were not interpreting redirected session flag to compute a
console mode flag. In the proxy that was leading client connecting with /admin to front
to not connect with /admin on the back server.
* nla: fix the printinng of the package name
_align_XXX functions aren't widely available depending on the C runtime. That causes
problems with mingw where we can easily have some runtime mixes (which lead to mysterious
segfaults most of the time). This patch introduce winpr_aligned_XXX functions that will
either use the function available, or use an emulation layer.
Set the same keepalive properties to accepted server socket as are set
to client sockets. This prevents the server from keeping sockets open
for tens of minutes in case the client disappears.
Signed-off-by: Marek Vasut <marex@denx.de>
* Added tests for freerdp_[static|dynamic]_collection_* functions
* Added settings unit test for clone functions
* Fix argument for winpr_RAND and winpr_RAND_pseudo
Using void* eliminates all assumptions of which type the buffer is.
This eliminates unnecessary warnings.
