Every addStream call would increment this counter. After merging the
mbedTLS fixes, we no longer have extraneous RTMP_Init calls which were
masking the prescence of this bug. This caused every stream after the
first stream to have the wrong channel index, and eventually OBS would
crash due to an out of bounds write if the counter reached
RTMP_MAX_STREAMS.
Before this change, after a game capture source would send a signal to
init or restart a graphics hook, it would respond to any and all hook
ready signals.
With multiple game capture sources in the same scene, a source could
receive the signal intended for another source, and show the wrong
texture.
This change adds the window handle to the name for shared data with the
hook, resulting in hooks for other sources being ignored.
Reland of 30d29618, except actually tested this time.
The VideoToolbox encoder gives I-frames and P-frames a priority of 1,
but the RTMP output code expects I-frames to have priority 3 and
P-frames to have priority 2.
30d29618 changed the priority of all frames that aren't I-frames, but
that included B-frames as well as P-frames. B-frames are given a
priority of 0 by VideoToolbox and changing that priority causes
artifacts for reasons I don't understand. So ignore the B-frames by
ignoring slice packets with priority 0.
When changing the target for display or window capture, force a
refresh of the source by setting the timer to fire immediately. This
removes 1-3 seconds of "lag" before the new display or window is
visible and makes the UI feel more responsive.
Closes https://github.com/obsproject/obs-studio/issues/2322
The report in https://github.com/obsproject/obs-studio/issues/2350
identified the issue as being caused by mbedtls not following symbolic
links, but it turns out the issue was the mbedtls_x509_crt_parse_path
return value which was already fixed in 4d89123c. So these changes are
no longer necessary.
This code is very old and seems to be non-functional in its current
state. The TLS support is also complicated to maintain across multiple
deprecated mbedtls functions.
Though this should now be very rare, it's more helpful than "Failed to
connect to server". Other TLS error codes are now also stored for future
use instead of copying them on a case by case basis.
Per mbedtls documentation, "If you share a context between threads, you
need to call these functions only from the main thread, at the beginning
and end of the context's lifetime.". OBS violated this since librtmp
uses a global context and it was allocated and freed in different
threads such as the auto config test.
This commit attaches the mbedtls context to an RTMP structure so there
is no more global state. It also fixes a rare double-free crash that
could occur if RTMP_TLS_Free was called twice (this happened in rare
situations such as the auto config running followed by a mode change
from Advanced to Simple).
We have a new back-end to the SermonAudio webcasting system which required a new URL and now allows for increased bitrates.
Added the "alt_names" to avoid breaking backwards compatibility and ensure that users receive the new ingest URLs.
mbedtls_x509_crt_parse_path returns a positive number if it partially
succeeds and a negative number on complete failure. This changes the
positive result to no longer error and prevent TLS connections (OBS
verifies all endpoints so having no CA chain prevents TLS).
mbedtls_md5_starts(), mbedtls_md5_update() and mbedtls_md5_finish()
have been marked deprecated since mbedtls version 2.7 and may go
away in the future.
These function have been superseded by versions with a return
value. They are suffixed with "_ret". We do not actually check
return values.
Also the header "mbedtls/net.h" has been superseded by
"mbedtls/net_sockets.h".
Not sure what effect black_and_white.png is going for. Add grayscale.png
to try to make it clear that the other image shouldn't be used for
desaturation.
When cropping the left or top of a window capture, OBS would misalign
the drawn cursor, placing it as if the entire window were being
captured. Instead, offset the captured cursor by the same number of
pixels, thus placing the cursor back where it belongs.
The biHeight field can be negative, leading to crashes on some cards
like VisionRGB-E1S. Adding flip support is fairly straightforward.
There also appears to be a hack to automatically flip for RGB formats,
but I wish to remove it because it seems to fight with this change. We
already have a separate vertical flip checkbox to deal with non
compliant behavior.
By giving the option to disable the looping in the scroll filter, it
makes it more suitable for tasks like credits sequences, where you don't
want the texture to repeat and for the motion to only be performed once.
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.
Add the option to enable custom quantization matrix for game streaming
on ICL for better subject quality. Feature is only supported with AVC
high profile, so added function to detect when QSV profile is modified
and hide or show CQM UI option accordingly. Also, increase SPS/PPS
buffer sizes since matrix is stored in SPS/PPS.
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.
This reverts commit 46c5780a77.
This needs to be reverted for now because users who did not set a size
on it (left it at default and just stretched it) will now suddenly have
the source's size change out of nowhere. There needs to be backward
compatibility implementation for this.
Using WasHidden() for the purposes of visibility no longer can be relied
upon due to some sort of bug with OSR in Chromium. This issue does not
happen when using 3440. The browser works fine without WasHidden()
calls, so we must remove its usage or be forced to use 3440. For those
who need the visibility handling, an alternative will have to be used
once it's available.
Additionally, this reverts the failed workaround to use OBS FPS in place
of SignalBeginFrame() because that code is no longer needed due to the
WasHidden() removal.
Before, we were calling DestroyWindow on the browser panel HWND from the
CEF UI thread, which meant that the main program thread had to process
window messages in order for that message to successfully through as
DestroyWindow blocks on the WM_DESTROY/WM_NCDESTROY window messages.
Unfortunately, this also had the side-effect of processing all queued Qt
events, which, when called in the destructor of a window like this, can
result in undefined behavior; specifically crashes, which were occurring
due to this. Especially when browser panels were in docks and docked to
the main window.
So, instead of calling DestroyWindow in another thread and then
processing events in the main thread, call DestroyWindow directly in the
main thread to get WM_DESTROY/WM_NCDESTROY and only those processed on
the spot. This appears to fix the crashes due to the undefined
behavior when closing browser panels.
This fixes crashes that could occur while processing Qt events during a
source's destruction.
Originally the processEvents code was added to make sure that any window
messages being sent to the browsers were being processed by Qt.
However, that was only necessary for browser panels as they are actually
associated with windows/views. Browser sources are OCR, thus they do
not need this.
Fixes same issue as 5c04876de1, but reverts that and changes it so that
external_begin_frame_enabled is not used instead, which seems to fix
that issue.
CEF outputs multiple audio streams at once, and OBS was only able to
handle one at a time. This fixes it by using audio lines for each CEF
audio stream, and mixes them together itself.
The dynamic bitrate operates based upon estimating the current bitrate
output, and then adjusting the bitrate on the fly as necessary when
congestion is detected as a replacement for dropping frames.
This may still need adjustment, as it is difficult to accurately emulate
real-world frame drop scenarios. This does not currently drop frames at
all, and because of that, very high congestion may cause additional
stream delay to viewers (because data will be buffered), but from
limited testing, most congestion will not cause that and it can safely
recover pretty quickly without adding significant delay.
When doing the bitrate limit test, it can be useful to have the ability
to change the current maximum bitrate limit. This adds the ability to
press keys on windows (numpad 0-6) to change between bitrates. Numpad 0
being no limit, 1 being 1000, 2 being 2000, etc.
Richard Stanway
Jim
Stanislav Izotov
VodBox
Clayton Groeneveld
Theodore Dubois
tlivegaming
Wahaj Dar
jake-shomer
Colin Edwards
Matt Gajownik
jpark37
Jiaxun Yang
Matthew
astudios123
Kurt Kartaltepe
Florian Zwoch
derrod
Kacper Geisheimer
Gary Kramlich
Daniel Hill
Alexander Kozhevin
JohannMG
Yves Dionne
Kraz3D
Aaron Boxer
Peter Geis
Chris Angelico
Manuel Kroeber
wanhongqing
Olle Kelderman
tujinshu
Roman Sivriver
Ryan Foster
Dmitry Vovk
Joel Bethke
Richard Stanway
luz.paz
wolf247
brittneysclark
Ford Smith
Exeldro
Gol-D-Ace
craftwar
Hosein
pkv