This fixes ovewritting hidden "profile" setting in ffmpeg vaapi which is
a number and not a string. It also shouldnt be overwritten as it is
required on some AMD hardware for the encoder to work.
**Commit message modified and clarified by Jim**
When hooking a program that has both DirectX and OpenGL contexts in use,
it is possible to cause a crash on shutdown due to capture_active()
returning true when an OpenGL context is deleted. Normally, when
capturing an OpenGL program, this would not happen because the 'active'
variable would not be set due to OpenGL capture not being initialized,
but if DirectX is captured while an OpenGL context is available, and
OpenGL could not load these required functions, then GL can crash due to
trying to use unavailable functions.
This case is extremely rare and doesn't happen under normal
circumstances; only if a program is using both DirectX and OpenGL within
the same program simultaneously, and *only* if OpenGL could not load the
required functions. This likely almost never happens under normal
programs, games, and hardware. This was apparently produced by hooking
a GL Qt program that used QWebEngine, which used multiple contexts at
once.
The built-in format selector failed in certain cases like UtVideo now
using a differently packeg RGB format. FFmpeg has a format selection
functionality built-in that does pick the correct format however
(avcodec_find_best_pix_fmt_of_list), so we can simply use that instead.
Deprecated support for drivers that ship an AMF Runtime older than
version 1.4.14, and older than 19.9.2. This also means Windows 8 is no
longer supported since AMD has stopped providing driver updates.
Added the new "High Motion Quality Boost" option that is exclusive to
the new 5700 cards and seems to do nothing on older cards.
Fixed the calculation of the automatic VBV buffer above 50%.
The Video API option will now only list one API, Direct3D 11 on Windows
10, and Direct3D 9 on Windows 7.
The reasoning behind removing this flag is because the whole point of
having it in was so we could replace chromium's audio output. But there
are too many obstacles in our path from doing that for now, so it's
better to not have this flag because it just causes a lot of browser
sources to initialize audio monitoring unnecessarily. We can change
this in the future, but for now, it's best to let the user choose to
turn on audio monitoring for the source if they choose to turn on audio
rerouting to OBS.
Note that this only changes default behavior for newly created sources;
it will not change settings of existing sources the user had before this
change.
Apparently, using the old chromium network implementation changes the
way cookies are handled, causing cookies to reset. So instead of doing
that, continue to use the new network implementation on Windows, and
only use the old network implementation on macOS for the time being.
Make duplicator_capture_tick the sole creater, and reference adder of
IDXGIOutputDuplication objects. This prevents a situation where
duplicator_capture::showing cause be false while
duplicator_capture::duplicator was not null at startup on background
scenes, preventing IDXGIOutputDuplication from being recreated when
DXGI_ERROR_ACCESS_LOST.
This uses the older network implementation rather than the new
NetworkService chromium has implemented until a later version of CEF is
used. The newer NetworkService implementation has caused some lag with
playback when hardware acceleration is not available for whatever
reason. This doesn't fix media playback issues with software rendering
on windows, but it does on macOS. All playback issues with software
rendering appear to be fixed in later version of CEF, however those
versions do not currently have hardware accelerated OSR or audio capture
support, so we must deal with 3770 until we can upgrade CEF again (which
hopefully won't be too long).
Certain ffmpeg parameters such as "bufsize" or "maxrate" have to be
applied to the context rather than to "priv_data". In order to make sure
options are still passed to the encoder setting set AV_OPT_SEARCH_CHILDREN.
Unbuffered mode is causing the frames of media sources to potentially
have some slight jitter in playback, so instead of using unbuffered mode
with media sources, just leave buffering on. There may be a frame or so
of latency, but it shouldn't be noticeable to most users.
The file duration is a bit of an estimate. This adds 500ms to the
estimated stinger media file duration to help ensure stinger videos
play back in full without getting cut off prematurely.
Lookahead requires examining frame data over a large number of frames,
so when pkv added the change to fully reset the encoder when the bitrate
changes, nvenc will invalidate all buffers and basically starts over
from a completely clean slate.
It's possible to make lookahead work when changing the bitrate, but due
to how lookahead seems to works internally in nvenc, it will cause
continually increasing latency every time the bitrate is updated, which
is unideal.
Additionally, when lookahead is enabled, deadlocks can occur when
changing the bitrate in a thread other than the graphics thread.
Currently we allow it to be reset outside of the graphics thread. From
limited investigating, it would appear this deadlock occurs because
nvenc is locking and releasing old textures.
So instead of dealing with all these potential issues, disable the
ability to adjust bitrate when the user has lookahead enabled on nvenc.
It's not really worth implementing dynamic bitrate support when
lookahead is enabled if the latency is just going to continually
increase for every bitrate adjustment anyway.
If a user has a tremendous amount of media files, this can cause
instability. Instead, make hardware decoding something the user has to
explicitly enable.
Although hardware decoding was technically enabled by default even
before we fixed it, fixing it was essentially a change to defaults for
users because it was just not even available before version 24.
This fixes a freeze that can occur if you try to destroy browser while
another browser is being created. The CEF UI thread has to wait on a
window message to the main application UI thread, meanwhile the destroy
call in the main application UI thread is waiting on the CEF UI thread,
thus causes a deadlock.
Now that we have the SetParent(hwnd, nullptr) code that detaches the CEF
window from the Qt window, we no longer have to worry about
synchronously shutting down the browser, so instead of waiting for that
operation to finish, just allow it to occur asynchronously.
Uses the new obs_source_set_audio_active function to signal to the UI
whether audio is active or inactive depending upon whether the user is
currently allowing OBS to control the audio or whether the user is
allowing CEF to control the audio. Ensures that the browser does not
show up in the mixer if CEF is playing back the audio itself.
It was determined that rerouting audio through OBS currently isn't the
best idea even with monitoring enabled, primarily due to the fact that
audio monitoring has never had this wide of testing before, and that
many users complained that they were not getting audio for (as of yet)
unknown reasons from audio monitoring. It would appear that we need to
address the issues with audio monitoring first before attempting to use
audio monitoring with any sources by default. For now, audio will
reroute through CEF by default, and then the user must explicitly use
the option "Control audio via OBS", (renamed from "reroute audio", and
now disabled by default), to enable browser audio control through OBS.
There are other issues that need to be resolved as well, and once all
the various issues are addressed, the setting default can be allowed to
change back.
This prevents VideoFormat::Any from unintentionally selecting H264 when
MJPEG is the only other format available.
This fixes a bug where certain devices (Logitech C920 with latest
drivers) will only have H264 and MJPEG available, and using
VideoFormat::Any will then select H264 over MJPEG because it's the first
format value and has the same priority as MJPEG. So now, MJPEG will be
prioritized over H264 instead.
Full color range seems to be active when decoding video with FFMmpeg
even when partial is explicitly selected. This should keep the range
synchronized.
Request contexts don't appear to work with relative paths, only absolute
paths. This fixes the bug where when using portable mode,
cookies/session wouldn't save because obs_module_config_path() was
returning a relative path rather than an absolute path.
Browser panels were having their initial visibility state always being
set to false. This fixes that by only setting visibility state on
browser objects which explicitly call the visibility message (i.e. only
browser sources).
In newer CEF builds the http://absolute/ scheme handler factory seems to
never complete when accessing large media files due to an apparent bug
in the Chromium media player (XHR requests complete fine). At the same
time, file:// URLs are working just fine.
file:// URLs will be used where available (CEF 3440+) falling back to
BrowserSchemeHandlerFactory on older CEF versions.
