Unfortunately these encoders tend to crash or freeze after after
multiple bitrate changes. Users with dynamic bitrate enabled
experience a random encoder freeze which manifests as OBS dropping to
0kb/sec and disconnecting and it's not at all obvious that dynamic
bitrate is the cause. Disable it for now until we can figure out if
there is any workaround or bug on our end.
Only use lossless encode if the capability is supported.
Set qpPrimeYZeroTransformBypassFlag to 1 for lossless.
Do not set profileGUID for lossless.
For both NVENC implementations, retry with a heavier reset because both
are unable to recover from failure lightly.
For new NVENC, warn if PVT is requested, but unsupported by the GPU.
Also retry without PVT on failure to try to catch bad cominbations.
For old NVENC, if PVT is enabled when FFmpeg failure occurs, retry
without PVT.
This was changed to default on but is not exposed for ffmpeg nvenc.
Where cards without temporal AQ support will fail to initialize and we
cannot do checks beforehand. This exposes the parameter to allow users
to disable this feature when using the ffmpeg implementation.
If DEBUG_FFMPEG_MUX is enabled, when starting a recording without
configuring global_stream_key, obs-ffmpeg-mux will hang. Apply same
check to global_stream_key as in init_params() to prevent this.
Previously the save callback would be called when the replay buffer
hotkey was pressed and not when the saving of the replay was finished.
When the 'get_last_replay' procedure was called after the saved callback
function, it would return the incorrect path, as the path would still
be the previous path.
When a media source is set to use a URL, always fully shut down the
media when stopped. This ensures that the media will do a full
reconnect after having been stopped.
4f873376 as part of PR #3460 changed ffmpeg_mux_packet to
fail = !ffmpeg_mux_packet. ffe4c855 only reverted that one line
instead of the entire previous commit. When the change was
reintroduced in 6071098a as part of PR #3740, it became
fail = ffmpeg_mux_packet without the negation.
This commit reverts db1e6aa and fixes the logic check.
ffmpeg-mux does not notice if ffmpeg returns an error from
av_interleaved_write_frame() which means that OBS never knows if there
is a problem in ffmpeg.
This is the biggest issue for cases like srt:// or tcp:// streams that
can regularly fail. Without this change OBS never knows that something
went wrong.
Only network streams are checked to prevent impacting potential
transient errors in recordings.
This reverts commit 4f87337646f4db0d50a4ebb257faf0640a729805.
Reverting the line in 4f87337646f4d causing issues until it can be
properly investigated.
For some reason, currently unknown, FFmpeg logging has to be set to
something in order for HLS to not fail on Windows, even if it's just an
empty function.
(Author comment: I don't feel comfortable not knowing why, my theory is
that FFmpeg has an issue with this internally with HLS on Windows
related to logging or how it's trying to log, I have absolutely no idea
what's going on and if someone can enlighten me or debug FFmpeg itself
it'd be real nice to know why.)
Adds a cmake variable (DEBUG_FFMPEG_MUX) which enables FFmpeg debug
output in the ffmpeg-mux subprocess, and if on Windows, shows the
console window of the ffmpeg-mux subprocess so the current output can be
seen.
Add and register an obs_output_info struct called
ffmpeg_hls_muxer. It uses ffmpeg's HLS muxer to stream output.
Add threading and buffer to reduce skipped frames.
Also add frame drop logic when there are too many packets in the
buffer for congestion control.
(Jim) Allows the ability to use stream keys with ffmpeg-mux -- this will
enable the ability to use it with certain services (such as YouTube)
which allow different protocols (such as HLS)
(Jim) Allows the ability to specify mux settings directly on the
output's structure itself rather than just via settings. This is useful
for network-based muxer outputs (such as HLS).
