* Properly initialize the stream buffer
* Add Stream_StaticConstInit accepting a const buffer
* Modify API to return a pointer to the stream initialized
* Do length/capacity checks in every read/write/seek function
if WINPR_ASSERT is defined.
* Ensure s->pointer is valid, e.g. within s->buffer + s->capacity
(Stream_Rewind, Stream_Seek, ...)
* Add return values to Stream_Set* functions so inalid arguments
can be reported to the caller
* Deprecated problematic stream manipulation functions
(Stream_SetBuffer, Stream_SetPointer, Stream_SetCapacity)
* Ensure length/capacity functions never return a value larger
than the actual length/capacity
* Fixed research for native PCM format
* Fixed compatibility detection for resampling
* dsp: Makes channel mix and encoding process use separated buffers
* Give FramesPerPacket to freerdp_dsp_context_reset function
* dsp: Fix DVI_ADPCM codec by respecting the required packet size
* Forbid mono channel in macos
* Fix audin command line channel option
* Disable ADPCM codec as it does not work
* Refactor valid native codec research
* Native codec research: Try different channels number
* Fix dsp channel mix
* Fix dsp resample
While decoding RemoteFX encoded frames is multithreaded, decoding
RemoteFX Progressive frames is not, although both codecs work
relatively similarly.
This is especially noticeable with frames, that have a resolution
larger than 1920x1080 pixels.
decompress_tile_first() and decompress_tile_upgrade() can both run in
different threads at the same time for different tiles without necessary
adjustments.
So, do exactly that using the ThreadPool that already exists in the
RFX_CONTEXT to decrease the decoding time and therefore increase the
performance.
On a 3K display (2880x1620 pixels) this makes out of a choppy
experience a fluid experience.
When checking whether tiles and updatedTileIndices are both non-NULL,
one of them might be NULL, while the other struct member might not
be NULL and progressive_surface_context_new() leaks then the non-NULL
struct member.
Fix this by freeing both struct members, when aborting in
progressive_surface_context_new().
free() will take no action on pointers that are NULL, so no additional
check is needed.
The `rfx_context_free` function uses the `rfx_message_free` function
with an address of the statically allocated `RFX_MESSAGE` struct. This
causes that the following is reported from covscan:
```
address_free: "rfx_message_free" frees address of "context->currentMessage".
```
I am convinced that this is just false-positive as the address is freed
only when `freeArray` is `0`, which is not in case of `RFX_CONTEXT`.
Let's add a code annotation to silence the false-positive next time.
