The repeat_headers parameter is currently hard-coded to false and can
not be changed.
For mpegts container and allow better compatibility with broadcast
mpegts decoders, it is mandatory to repeat the sps/pps headers
regularly.
This commit enables this parameter to be set either by the user or the
service (ex: udp or srt w/ mpegts container).
The b_annexb enables compatibility with Annex B bitstream which is
better for streaming formats than avcc.
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.
Code submissions have continually suffered from formatting
inconsistencies that constantly have to be addressed. Using
clang-format simplifies this by making code formatting more consistent,
and allows automation of the code formatting so that maintainers can
focus more on the code itself instead of code formatting.
This reverts commit 958167c4f7.
This caused certain transcoders (specifically Twitch's transcoders) to
misinterpret the data and transcode the video incorrectly.
Back in an older commit, the default YUV colorspace was changed to 601
in order to ensure correct playback in video players that ignore the
contents of the H264 header.
x264's "undef" is unfortunately not what players that don't ignore the
header expect for BT.601, resulting in incorrect colors when played
back. Setting it to "bt470bg", similar to what is specified in ffmpeg
outputs, remedies this issue.
VFR encoding mode was originally added experimentally, but in truth,
it's nothing but a detriment because it can cause wild bitrate
fluctuations. It's still a constant framerate even when VFR mode is on
anyway.
Due to the fact that people follow terrible guides that ignorantly
recommend opencl, the "opencl" custom x264 option was blocked. However,
because some people still apparently want to use it, it's being renamed
to "opencl_is_experimental_and_potentially_unstable" so that anyone who
uses this option realizes that they should probably think twice about
using the option rather than just follow some terrible guide that tells
them to use it.