Add the missing type info for:
* SPA_FORMAT_VIDEO_colorRange
* SPA_FORMAT_VIDEO_colorMatrix
* SPA_FORMAT_VIDEO_transferFunction
* SPA_FORMAT_VIDEO_colorPrimaries
We currently often create pods in a uint8_t buffer, which is not aligned
to 8 and might cause deref and other problems.
We should either align the buffer we write into or maybe make the
builder add some padding before the buffer to align it. We have to be
careful with that when we assume the buffer start is the beginning of
the pod..
Fixes#4794
Previously, custom object properties were printed as "unknown",
and the offset (wrt. `SPA_PROP_START_CUSTOM`) was not displayed.
A custom property is distinct from an "unknown" one. Being able
to quickly differentiate the two is useful. Furthermore, knowing
the custom property id (i.e. the actual numeric id minus
`SPA_PROP_START_CUSTOM`) is also very helpful.
To address the above, print a custom property (i.e. anything with
an id at least `SPA_PROP_START_CUSTOM`) as follows:
Spa:Pod:Object:Param:Props:Custom:123
where the last component is the custom property id.
Make a new function to also returnt he child size and type.
Make a new function that accepts the array item size. Check that the
array item size and destination item size match before memcpy the array
contents. This avoids overflowing the target array with a malformed
array pod.
For the embedded children, they will always be aligned. We can also
avoid the max size checks for children because this is already checked
for the parent and with the remaining size check.
For arrays and choice we simply don't get any elements in the array when
the sizes are too large.
We don't really want to do this here otherwise structs that include a
pod will be padded so that an array of those structs will be aligned.
This makes a test case fail where we have a struct with a choice_body
followed by 3 uint32_t enum values. The size with and without the
aligned attribute is different.
Make a SPA_POD_ALIGN = 8 and make sure all pods are aligned to it. Use
the new constant to pad and check alignment. Make some new macros to
check for the pod type, alignment and minimal size.
Properties of type Id should have a type of the enum with the possible
values associated with them.
The other types that don't have a fixed enumeration but are usually
mapped to some constant/description with PropInfo should be Int.
Fixes!2399
The hooks were previously used to unlock the loop but now that the
lock is handled inside the loop itself and we don't unlock before the
blocking read anymore, we should also not call the hooks.
The blocking invoke function is not meant to be called with any of the
loop context locks acquired in order to avoid a deadlock. Make this (and
other blocking risks) clear in the documentation.
See #4472
A signed value doesn't really make sense in this context, so let's keep
it unsigned so the semantics are clear. This does break the interface,
but should be okay since it's not in a release yet.
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
We can add a PTHREAD_PRIO_INHERIT lock to the loop to protect the
callbacks and then use this to update shared data in an RT-safe way.
This can avoid some invoke calls that require a context switch but
also due to the nature of epoll cause locking in the kernel with non-RT
guarantees.
Because we use PRIO_INHERIT, the code executed in the lock must not use
any RT-unsafe functions.
