Due to a noticeable frequency of crashes inside of FFmpeg when using
hardware encoding on mac, this feature is going to be disabled for now
pending more investigation at a later time.
(This commit also modifies the decklink, linux-v4l2, mac-avcapture,
obs-ffmpeg, and win-dshow modules)
Originally, async buffering for sources was supposed to be a
user-controllable flag. However, that turned out to be less than ideal
because sources (such as the win-dshow plugin) were programmed with
automatic control over their buffering (such as automatically detecting
USB 2.0 capture devices and then enabling in those cases).
The fact that it was a flag caused a design flaw to where buffering
values would be overwritten when a source is loaded from save data.
Because of that, this flag is being deprecated and replaced with a
specific function to enable unbuffered mode instead.
This happens because the enum had the incorrect name, and microsoft
automatically treats all enums as integers in C, regardless of whether
they actually exist or not. Microsoft makes terrible compilers and
whoever decided this was a good idea should be fired.
The "default" preset is not an actual default, but something Nvidia
decided to just call that way. It yields the worst quality per bitrate
out of all the presets, for no actual benefits. The actual FFmpeg
default is the hq one, which yields the best quality, especially when
twopass mode is enabled.
I can't think of a way to keep the "default" preset in a non-confusing
way, and as it gives no known benefits, might as well just remove it
entirely.
(Jim edit: Also made it so that if the settings have it set to
"default", it automatically treats it as "hq")
Closesjp9000/obs-studio#865
Due to crashes being caused by hardware acceleration in the media source
on mac, disable hardware acceleration of the media source being on by
default for the time being.
The encoder name was changed from "nvenc_h264" to "h264_nvenc", and will
throw a warning in the log file if you use the former, so try the latter
first, then the former.
This reverts commit bd70e73c25.
Turns out the commit was due to a miscommunication -- the commit it was
fixing actually worked fine, and this fix was unnecessary.
(Note: This commit also modifies obs-ffmpeg and obs-outputs)
API Changed:
obs_output_info::void (*stop)(void *data);
To:
obs_output_info::void (*stop)(void *data, uint64_t ts);
This fixes the long-time design flaw where obs_output_stop and the
output 'stop' callback would just shut down the output without
considering the timing of when obs_output_stop was used, discarding any
possible buffering and causing the output to get cut off at an
unexpected timing.
The 'stop' callback of obs_output_info now takes a timestamp with the
expectation that the output will use that timestamp to stop output data
in accordance to that timing. obs_output_stop now records the timestamp
at the time that the function is called and calls the 'stop' callback
with that timestamp. If needed, obs_output_force_stop will still stop
the output immediately without buffering.
For some reason in the FFmpeg output, this AVCodecContext variable is
being set to 1 by FFmpeg itself somewhere, and it's causing a massive
slowdown when encoding with FFmpeg directly. This should be set to 0 to
specify to use as many threads as necessary.
