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.
Due to the recent change of using FFmpeg to decode MJPEG, MJPEG was
getting included in the delayed device check. This fixes that so that
it doesn't. MJPEG can decode in real time.
IsEncoded is meant to be used to indicated delayed devices, such as
older Elgato devices, or Hauppauge device. Devices that use H264 and
have a 800+ millisecond latency. This changes the function name to
better indicate that.
