We should prefer the value of the follower when fixating to the
PortConfig format.
To make this actually work we need to be able to check if the value is
within the configured ranges. Implement the check for all types by
simply comparing the memory. This should then work also for checking
arrays, such as channel positions.
Including C headers inside of `extern "C"` breaks use from C++. Hoist
the includes of standard C headers above the block so we don't try
to mangle the stdlib.
I initially tried to scope this with a targeted change but it's too
hard to do correctly that way. This way, we avoid whack-a-mole.
Firefox is working around this in their e21461b7b8b39cc31ba53c47d4f6f310c673ff2f
commit.
Bug: https://bugzilla.mozilla.org/1953080
Make a new PeerFormats param that can be set on ports to let it know
about the possible peer formats. This can be used by converters to calculate
an optimum conversion.
make the videoadpter query the follower formats, simplify them and then
set them as PeerFormats on the converter.
Implement peerformats in videoconvert. This makes EnumFormat on the port
depend on the negotiated format of the peer. It will suggest a Format
that most closely matches the current negotiated format with the available
PeerFormats. This then makes it possible to negotiate to the format that
would require the least amount of conversions.
Make a function to create a filter. This is a pod that has all valid
defaults fixated and the invalid ones left unfixated.
Use this filter is a first attempt to negotiate a link format. The
effect is that a format will be chosen first that matches all the valid
defaults as much as possible instead of negotiating to the first thing
that matches.
Suppose we have a higher priority port with the format:
foo/bar
key: { default:1024, min:1, max:2048 }
And another port with two params:
foo/bar
key: 512
rate: 2/1
foo/bar
key: 1024
rate: 30/1
By first trying key: 1024 we negotiate to the more specific second property
with the higher rate.
We usualy want to prefer the filter default value. When this value is
not within the valid range/alternatives, swap the logic and prefer the
defaults of the other pod.
This way we can have a filter with an invalid default that will then use
the preference of the other pod but still enforce some bounds.
Build the filtered result into a new separate builder and copy it into
the result builder afterwards. This ensures the memory of the old
builder does not suddenly change when it gets reallocated.
The continue functions takes a builder as the argument and makes a new
builder that starts from the old builder memory. If the old builder was
dynamic, the new one will also be dynamic. Because it's a separate
builder, the memory of the old builder will not be reallocated when
extended.
This makes it possible to freely read the memory from the old builder
while we construct the result in a new builder without having to worry
about reallocating the memory of the old builder. When the new object is
completed, it can then be copied into the old builder.
When the builder is overflowed, we might get a NULL pod. This is a valid
situation that we need to handle because it can be used to get the
required builder buffer size.
When we construct an Enum, check if we only added 1 value and remove the
duplicate default value we added. If we added more values, promote the
choice to an enum.
When using a filter, it makes more sense to use the default value
of the filter as a first attempt.
One case is in adapter when we try to find a passthrough format first. The
audioconverter suggests a default rate of the graph rate but the follower
filters this out for another unrelated default value and passthrough is not
possible (altough it would be because the default value of the filter is
in the supported follower range).
Fixes#4619
When the pod to filter is in the target builder memory and reallocation
is needed, make sure we refer to the filter in the reallocated memory
instead of the old freed memory.
Fixes#4445
Add macro SPA_CMP to do 3-way comparisons safely, and use it to avoid
signed integer overflows.
Fix also float/double comparisons (previously 0.1 == 0.8 since cast to
return type int).
Fix Id/Bool comparisons so they can return negative value.
C++20 introduced designated initializers similar to the ones found
in C99, however, in C++ designated initializers cannot be mixed
with non-designated initializers. GCC rejects mixed initializers
with an error.
Add a new overflow-safe function to check if region p2 of size s2 fits
completely in p1 of size s1 and, if it does, return the amount of bytes
in p1 that come after the end of p2. Use this to bounds check the pod
iterators while ensuring that the pointer is bounds checked before being
dereferenced.
The spa_pod*_next() functions can still create an out-of-bounds pointer,
but this will not be dereferenced. Fixing this requires either
additional complexity in these functions or forbidding POD structs,
objects, and sequences that have a length that is not a multiple of 8
bytes.
Fixes: 92ac9a355f ("spa: add spa_ptrinside")
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Add a new overflow safe function to check if region p2 of size s2 fits
completely in p1 of size s1. Use this to bounds check the pod iterators.
Fixes#3727
Make sure that NULL params don't cause -EINVAL but ignore them.
Don't add empty param objects. this makes it possible to clear all previous
params by setting an empty object.
added cleanup of unused variables and fix warning about missing initializers
to resolve build warnings in pipewire-rs
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Fixes the return type of spa_pod_builder_control() from uint32_t to int.
Since the function returns the int returned by spa_pod_builder_raw,
the return type of the function should also be an int.
This fixes several integer overflow problems in the POD parser, as well
as fixing a returns-twice warning from GCC and integer truncation
problems in SPA_FLAG_CLEAR and SPA_ROUND_DOWN_N. The integer overflows
can result in a tiny POD being treated as a huge one, causing
out-of-bounds reads.
spa_pod_parser_can_collect and spa_pod_parser_getv were inconsistent
with each other. When parsing crafted POD, this could cause a type
confusion or stack overflow.
When we are already past the size of the buffer, don't bother calling
the overflow callback anymore, the buffer is already corrupted.
Otherwise it would be possible to have the overflow callback fail the
first time around, some data will be skipped, and then the next
overflow callback would succeed, giving the impression that all is
fine.
Add a unit test for this.
