When an x264 option doesn't include a "=", it is silently ignored. This
is frustrating for users. Log when part of the options string is
ignored.
Aside from logging, this commit should not change behavior.
The "custom settings" log message is misleading. It simply echoes the
user-given string, but does not reflect the options given to libx264 or
handled by obs-x264 itself. Change the log message to omit skipped
options.
We do a bad job of handling errors in user-supplied x264 options. I want
to improve our error handling. To make my job easier, move the code for
parsing the x264 options string into its own function. Also, add some
tests for the functionality.
Aside from a minor tweak to a log message for the opencl option, this
commit should not change behavior.
Simplify UI options by combining LookAhead Depth and Async Depth into
latency mode option. Ultra-low, low, and normal will set these two
encode parameters accordingly.
Don't allow unsupported Vulkan formats to fall back to B8G8R8A8.
Probably better to fail completely than do an illegal copy.
Also remove bad conversion for VK_FORMAT_A2R10G10B10_UNORM_PACK32.
Red and blue channels were reversed, and there's no DXGI equivalent.
Addresses #2796. We can do more later if justified.
Fix an issue in the way AVFrames were handled in the FFmpeg
encoder plugin, which could lead to tearing in the encoded
video due to data races in the AVFrame and AVBuffer.
This is fixed by calling av_frame_make_writable which ensures
the frame and its associated buffer are writable. If its not,
it will copy the AVFrame, create a new AVBuffer for it and
decrease the refcount of the old AVFrame and AVBuffer.
This way OBS always ends up with a usable buffer to write into
which is not still used by the encoder while avoiding a copy
when unnecessary.
This implements OSS audio input capturing support for OSS-capable OSes.
FreeBSD and DragonFly (not yet tested on) supports are added as a
starting point.
The error message in the process_packet function was prefixed with
"receive_audio" because it was previously from code in the encode_audio
function which was called from the receive_audio function. This is just
a string change to avoid being misled to believe that the error is
always audio related.
If we fallback to ffmpeg NVENC, the error from new NVENC might still be
present in the encoder structure. Given that this provides a lot more
actionable information to the user, let's use it if possible.
While discussing the Flatpak RFC [1], it was spotted that the
LUT filter couldn't open the file selection dialog. It was
explained, then, that the proper formats were either composed
of "User Label (file extensions)", or "file extensions", and
the LUT filter was setting "(file extensions)" without the
actual user label.
While this works on a standard Qt file selection dialog, it
cannot be properly formatted as a set of D-Bus filters, thus
breaking the sandbox integration.
Add a simple user label to the LUT file filter.
[1] https://github.com/obsproject/rfcs/pull/21#issuecomment-619106757