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.
Whether buffer size is visible is determined by the value of the "Use
buffer size" property (the "use_bufsize" setting).
(Commit edited and formatted by Jim: separated this code from the
previous commit, and gave it a proper commit message)
Closesjp9000/obs-studio#567
This is why macros should be used for settings strings.
(Commit edited and formatted by Jim: separated this code from the
following commit, and gave it a proper commit message)
Closesjp9000/obs-studio#567
Instead of having a "cbr" setting that turns CBR on and off, adds a
"rate_control" parameter that sets the rate control method, which can be
one of the following: CBR, ABR, VBR, CRF.
If the "cbr" setting is used, it will throw a deprecation warning to the
log.
API changed from:
obs_source_info::get_name(void)
obs_output_info::get_name(void)
obs_encoder_info::get_name(void)
obs_service_info::get_name(void)
API changed to:
obs_source_info::get_name(void *type_data)
obs_output_info::get_name(void *type_data)
obs_encoder_info::get_name(void *type_data)
obs_service_info::get_name(void *type_data)
This allows the type data to be used when getting the name of the
object (useful for plugin wrappers primarily).
NOTE: Though a parameter was added, this is backward-compatible with
older plugins due to calling convention. The new parameter will simply
be ignored by older plugins, and the stack (if used) will be cleaned up
by the caller.
This just changes the x264 encoder settings; it doesn't actually change
the framerate of OBS. OBS will always output at a constant framerate
regardless of whether this option is on or off; this just changes how
the encoder encodes the data.
API Changed (in struct obs_encoder_info):
----------------------------------------
bool (*get_audio_info)(void *data, struct audio_convert_info *info);
bool (*get_video_info)(void *data, struct video_scale_info *info);
To:
----------------------------------------
void (*get_audio_info)(void *data, struct audio_convert_info *info);
void (*get_video_info)(void *data, struct video_scale_info *info);
The encoder video/audio information callbacks no longer need to manually
query the libobs video/audio information, that information is now passed
via the parameter, which the callbacks can modify.
The refactor that reduces boilerplate in the encoder video/audio
information callbacks also removes the need for their return values, so
change the return types to void.
Add CBR, CRF to properties so that it can be changed by the user. If
CBR is on, CRF will be disabled. Also added a 'Use Custom Buffer Size'
option to make it so that the buffer size will automatically be set to
the bitrate if its value is false. This is primarily a convenience
feature for users.
I originally had it set the color space and color range in the video
info callback, but I forgot that it's a function that's called after the
encoder is initialized. You can change the color space and color range,
but you have to reconfigure the encoder, and there's no real reason to
do that.
This causes x264 to use the currently set color space and color range
of the video media. This helps prevent issues with decoding where the
colors wouldn't look right due to the fact that these settings were
never specified to x264, and prevents darkness and brightness from
looking washed out due to a potentially incorrect color range.