This reverts commit ce4c99be4e.
This was causing infinitely looping log errors in systems with no
CUDA-capable hardware when hardware decoding was enabled on video
capture devices with custom config enabled.
Fixes a crash when the following steps occur:
- Encoder group created and then started with encoders, only the group
owning encoder refs
- Encoder group destroy called: group has `destroy_on_stop` set
without actual destroy
- Outputs holding encoders from stopping are stopped
- `remove_connection()` function destroys encoder group, releasing
encoders and causing the currently processed encoder to be destroyed
early
- parent scopes try to access destroyed encoder pointer and crash
This change moves some logic around to improve the release/destruct
order of `obs_encoder_stop()` to fix the race above.
Note: Cases of encoder errors will not destruct the group if it has
`destroy_on_stop` set, as the encoder is also not destroyed if it also
is set to destroy on stop. This part of the code should be revisited
at a later date and fixed up to prevent memory leaks.
As with Linux we need to link Qt::DBus on FreeBSD now that there's a
HighContrastEnabled implementation that makes use of it.
Fixes: 41ba8bdfdd ("UI: Add HighContrastEnabled implementation fo...")
On some systems (eg. mine), VAAPI fails on vaInitialize. Valgrind was
able to spot that the device was not being closed, and it appears to
have been correct. This fixes a memory leak.
By not specifying a checkout ref, actions/checkout does a second
checkout when this action is invoked by the Publish workflow (release
event). When this happens, it checks out the commit object from the tag,
and git can no longer locate the annotated tag that contains the release
notes. This then causes the release notes to be just the commit message
and not the annotated tag message.
The sparkle-appcast action in general and this actioo when invoked via
the Dispatch workflow do not have this issue, and they both specify the
tag as the ref.
The code was checking stream_key, but stream_key could be the
user-supplied value (in_stream_key) or the server-supplied value
(endpoint.authentication). The server-supplied value may lack the query
parameters set in the user-supplied value. To ensure that user-specified
query parameters (such as bandwidthtest) are passed along, parse the
user-supplied key instead of the server-supplied key.
Modifies the encoder group API added previously to better follow the
existing libobs API naming paradigms. This also produces much more
readable code, and allows a few small benefits like only needing to
hold a reference to the encoder group, instead of every encoder.
All other bitrate setting fields in the UI have a single-step value of
50. Without setting this, the single-step value is 1, which makes using
the scroll wheel a bit tedious.
While this could arguably be higher, let's make this consistent first
and then consider changing the values across the application later.
Checking the format of the AVCodecContext will result in using the
format of the hardware-side frames, not the software-side frames. This
uses the software frame parameters itself to initialize the swscale
context.
There were some reports that the default value of 8000 was confusing
because it implies that the automaticaly selected and used value is 8000
Kbps. Set it to 0 which should hopefully make it more obvious that OBS
is not sending 0 Kbps.
Currently, the chat input elements (lineEdit, sendButton, and
chatLayout) are initialized when the QCefWidget gets set. This is
problematic behavior that only happened to work because we're a bit
lucky: The chat is only enabled after a widget is set, and it's only set
once. Without those conditions, the chat dock would crash when enabling
the chat before a widget is set, and the elements would get recreated if
the widget is set a second time, resulting in the original elements not
getting freed and leaking.
Moving the element creation to the constructor fixes both of these
problems, as now they're created immediately and only once.
Detected by PVS-Studio.
LineEditAutoResize didn't have its maxLength initialized in the
constructor, leaving it to be a random value until set via setMaxLength.
The one place where LineEditAutoResize was used immediately set this
after calling the constructor, but if we use this anywhere else in the
future it makes sense to have this initialized.
As it is meant to mostly behave like a QLineEdit, lets use the same
default value of 32767.
Detected by PVS-Studio.
ExeldroandRyan Foster
Ruwen HahnandRyan Foster
Warchamp7andRyan Foster
tytan652andRyan Foster
derrodandLain
Kurt Kartaltepeandtt2468
VainockandRyan Foster
PenwywernandRyan Foster
Ed MasteandRyan Foster
Alex LuccisanoandRodney
Fabien LavocatandRyan Foster
gxalphaandRyan Foster
cg2121andLain