It has replaced flags recently but it doesn't seem to have much
importance but it makes the modules implementing that more complex so
added a hint that only BLOCKING/NONBLOCK/DISCARD are important values.
Beware not to add --whitelist=/tmp[something] because that would hide
the actual mounted image (/tmp/.mount_ultragridsomething). As /tmp is
remounted RO, just make the "whitelisted" dirs RW.
+ add to whitelist $DIR (path to executable) if it is not /tmp (eg.
extracted AppImage somewhere)
The vulkan.pc pkgconfig file is for the vulkan loader library and
doesn't guarantee the presence of the vulkan headers. Indeed, some
distributions (e.g. Arch) package those in separate packages
(vulkan-icd-loader and vulkan-headers).
It would be perhaps more correct to check for vulkan.hpp, but that
header is so big that it would slow the configuration by ~10 seconds.
Hidden port, cuda-device and rate limiter in basic view. Those are not
more important than many of already hidden.
- cuda device - slightly changed description 's/CUDA device/GPU' - it
actually selects a card also for NVENC, in the end
Together with tiles setting, it should enable Motion Constrained Tile
Sets (MCTS) that should allow independed tile decoding. But it doesn't
seem to be currently the case with FFmpeg HEVC decodeer.
If checking AV1 properties, check if the codecs is really libsvtav1. It
can be also libsvt_vp9, where the option setting would fail (athough
innocent, it may be confusing).
Only enable for libvpx*.
Codecs must be individually evaluated - for libx265, it increases
latency because it uses frame threading parallelism internally.
For libsvt_hevc and libx264, the performance boost is not noticeable.
For reporting audio volume on the sending side. The report format is similar
to reports from the recieving side, except instead of "ARECV", "ASEND"
is used, and the number of channels reported is the same as in the audio
frame.
This reverts commit ec702d5c25.
Actually, this setting significantly increases the latency, not reduces.
The evaluation for the original change was incorrect because there was
16 gray levels and after that it wraps-around. Because this setting
added something around this latency, it looked to reduce the latency,
which was not true.
See GH-241 and GH-268.
If user specifies some x265-params, it would override previously set
ours. So try to merge it with those (set our custom values only if they
do not interfere with user-specified ones).
The previous value 16 was too much fast (one iteration lasted only 16
frames) which was even unsuitable for latency evaluation for higher
latency compressions.
With the value 1, the latency can be directy read from difference of
luma on subsequent lines.
So use it (the `cmake --install` is perhaps better than make install
since it doesn't trigger rebuilds so often). Also to be consistent with
the other SVT compressions.
It was incorrectly used to specify _output_ link configuration and
therefore was deprecated for a while. There doesn't seem to be anything
analogous for capture - it is autodetected perhaps without a
possibility to user-specify.
