If the API to query the maximum throughput isn't available, it was
intended to fall back to balanced. This code caused it to vall back to
speed instead because if the API isn't available, max_throughput will be
0. This fixes it to make it only fall back to balanced instead.
Adds support for texture-based AMD encoding, with both H264, HEVC, and
HDR support. Falls back to FFmpeg when texture-based encoding cannot be
used for whatever reason.
(Jim note: This is based upon obsproject/obs-studio#4538 by AMD/Luxoft
with fewer files, FFmpeg fallback for software encoding, and HDR
support. I also went to lengths to ensure that FFmpeg command line
parameters also works with it)
Co-authored-by: Jim <obs.jim@gmail.com>
This fixes a bug where the new circular buffer code is hit by protocols
such as rist or srt although the buffer was meant for files.
Signed-off-by: pkv <pkv@obsproject.com>
A race condition can occur in obs-outputs where the send_thread is in
the process of (re)connecting but the encoder was shut down in the
meantime. This causes the expected header data to be garbage, resulting
in a crash.
This adds a circular buffer to ffmpeg-mux when writing to a file.
Output from ffmpeg is buffered so that slow disk I/O does not block
ffmpeg writes, as this causes the pipe to become full and OBS stops
sending frames with a misleading "Encoding overloaded!" warning. The
buffer may grow to 256 MB depending on the rate of data coming in and
out, if the buffer is full OBS will start waiting in ffmpeg writes.
A separate I/O thread is responsible for processing the contents of
the buffer and writing them to the output file. It tries to process 1 MB
at a time to minimize small I/O.
Complicating things considerably, some formats in ffmpeg require seeking
on the output, so we can't just treat everything as a stream of bytes.
To handle this, we record offsets of each write and try to buffer as
many contiguous writes as possible. This unfortunately makes the code
quite complicated, but hopefully well commented.
Previously SPEAKER_4POINT0 was assigned to AV_CH_LAYOUT_QUAD, but later
was changed to AV_CH_LAYOUT_4POINT0 [1]. The change was forgotten in
obs-ffmpeg-mux. This is remedied here.
[1] 67e48ecc2c
Signed-off-by: pkv <pkv@obsproject.com>
The channel_layout API was overhauled by FFmpeg [1-4]. The previous
bitmask channel_layout is replaced by a struct ch_layout which combines
the number of channels, a bitmask and other infos. This struct must now
be supplied to AVframes since avutil >= 57.24.100 and to
AVCodecContext since avcodec 59.24.100 per (1].
This commit provides the required info to ffmpeg-mux,
obs-ffmpeg-output & to obs-ffmpeg-audio-encoders.
[1] Bump minor versions after the channel layout changes
cdba98bb80
[2] lavc: switch to the new channel layout API
548aeb9383
[3] avutil/channel_layout: Add a new channel layout API
086a804806
[4] avframe: switch to the new channel layout API db6efa18
db6efa1815
Signed-off-by: pkv <pkv@obsproject.com>
Want to avoid receiver gamut remapping from Rec. 2100 to P3.
Fix min luminance appearing as NaN by switching from 0/0 to 0/1.
Also set max luminance for HLG because why not.
stdout on Windows from a subprocess requires that something read the
stdout buffer, and currently we don't do that. Due to newly introduced
printf/fprintf calls, the stdout buffer eventually fills up because
nothing is emptying it, thus the muxer locks up on an fprintf/printf
call and causes OBS itself to hang.
