Adds an "Automatic" method to the capture method property of window
capture. This allows the ability for window capture to automatically
determine the best capture method to use. Primarily, it prefers BitBlt
in most cases, but will use WGC when it detects the window is a browser,
microsoft office, or a UWP program.
This was implemented because the new capture method has a number of
undesired effects associated with it -- the issue of the capture border
that we can do nothing about, the fact that we can't control the capture
of the cursor, and the fact that Microsoft designed it to switch the
cursor away from hardware cursor mode when the capture is active (there
was absolutely no reason to do this because even OBS can capture the
hardware cursor with no issue). Until we get a new version of this API
that doesn't absolutely blow, we're stuck preferring BitBlt instead.
But hey, at least people will be able to capture browser windows now.
Users will now have the option of legacy window capture via BitBlt, or
Windows Graphics Capture, which is new to Windows 10.
There are two annoyances with the new capture method though. One is that
there is a bright, yellow border added to the original window (but not
the OBS view of it). The other is that the mouse cursor is always
captured, and we won't be able to capture without cursor until a later
version of Windows 10 is released.
It should also be noted that DPI scaling is now applied, which may
result in blurrier images caused by Windows rescaling.
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.
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).
