The AMF docs specify that the maximum value for TARGET_BITRATE and
PEAK_BITRATE is 100,000,000 bit/s. Trying to set values above this
maximum value results in AMF choosing from its defaults instead of
capping at the maximum value. Let's cap at 100,000 Kbps in the UI to
prevent users from running in to this.
Fixes GitHub Issue obsproject/obs-studio#7423.
Move multiplication to when its passed to the encoder, so that bitrate
is kept in kbps. Changed for both for H264 and HEVC. Other encoders
(x264 and NVENC) already display bitrate in kbps in the log,
so it makes sense to mimic this with AMF. It's difficult to tell the
exact bitrate with bps.
This goes back to a slightly older variant of the
SubmitInput/QueryOutput handling that doesn't use AMF's timeout
property. Older devices do not like it when you change the query timeout
on the fly and will lock up. So instead, wait one millisecond when the
AMF input is full, which appears to fix the issue according to testers.
Also adds a loop timeout in case it goes in an infinite loop (which it
shouldn't anymore, but still)
Big thanks to Flaeri for testing the old code, and Yukari for patiently
testing a whole bunch of builds.
All this does is it uses the same exact code AMD uses with their own
example FFmpeg muxer code. Although instead of adding to the PTS, it
subtracts from the DTS.
Replace TRANSCONDING with TRANSCODING, because it is likely that the
typo compatibility will be removed in a future AMF header update. This
should also minimize confusion and improve search.
In the event that simply loading the AMF DLL causes initialization code
to run that might crash, don't load the DLL before the AMF test process
has succeeded. Instead, we load the DLL as data to see if it exists,
then run the AMF test, then load the DLL for real.
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>