Some plugin does that by deleting the QAction returned by
obs_frontend_add_dock().
Now that obs_frontend_add_dock() is deprecated,
obs_frontend_add_custom_qdock() replace this usage.
before: widgets docked on the sides of the preview are of the height of
the preview
after: the user can toggle the setting in the docks menu so the side
widgets are of the height of the whole window
UI: change menu label to Full-height docks
This fixes the shortcuts not showing up in the filters context
menu for rename and remove. This also has a code cleanup for
the rename action, as now it is created in the ui file.
This change allows the virtual camera to really output what is in the
program view, some plugin interract with this view but their changes
does not appear on the virtual camera.
Switching to a static library that contains version information as
const char strings has multiple benefits:
* The version information provided externally via compiler definitions
will fail compilation early if malformed
* An updated version string (which will happen with every commit) will
not invalidate existing compilation units, because only the static
library is affected by the change
* An update of the version change just requires a recompilation of the
static library and a linker update
* An update of the version will _not_ infect the rest of the codebase
(as it does currently, because everything includes obsconfig.h one
way or another)
* Other modules which used the macro definition directly have been
updated as much as possible to use the proper getter method from
`libobs` instead (some Windows-specific modules use preprocessor
string composition, the value has been added as a compiler definition
directly in those cases)
* Because the impact of a version change due to a commit hash change
is limited to the static library, ccache hit rates should be
improved considerably
#8873 accidentally used `log_flag_encoded()` instead of `flag_encoded()` in `obs_output_begin_data_capture()`, which was causing a warning to be logged when it shouldn't.
The pixel buffer pool is used to create pixel buffers with both the CMIO
extension and the DAL plugin. As such, it is created independent of
which camera type is used, and should be released independent of it as
well.
Meta have filed a patent application on the Go Away feature. This goes
against the spirit of free software and puts the use of this feature in
questionable legal status, so let's remove this code until the patent
situation is resolved.
This reverts commits a593fe6755 and
dada82fec1.
Adds a check to make sure that delayed preload is ignored if the stinger
is restarted/interrupted. Just adds this check to the previous commit to
make sure that it doesn't redundantly try to preload a frame when
playback is restarted.
The `mp_media::obsframe` varaible is a variable used to store the
current frame, or the first frame on stop. However, it's never cleared,
and while decoding a frame, it's invalid. The variable was added for
delayed preloading of the first frame for stingers.
Now, for more context, when media sources stop, it stores the first
frame of the video so it can set the source's current async texture to
that frame, effectively preloading the first frame into the backend,
making it so that when you play back that media, it's able to start
playback instantly without having to wait for the thread to play back
that frame, causing seamless playback.
Normally, preload happens right when first frame is finished decoding,
thus it wasn't a problem before these variables and delayed preloading
was added. However, with stingers, I delayed that preload further
because stingers are kind of a special case because the stinger does not
clear itself right away on stop. Because of that, it was causing it to
flash the first frame at the end of the stinger. This is why `obsframe`
and `request_preload` were added: it's a way of signaling the media
source to preload the first frame when the stinger itself is fully
completed. It was added to fix that stinger bug.
However, if the user interrupts playback of the stinger (e.g. swaps to
another scene while in the middle of the transition), that
`request_preload` might still be queued and happen while the media
source is still decoding, and thus, while `obsframe` is invalid.
I realize that we should probably refactor and clean up the
media-playback lib.
Deferring properties was only ever made for input and transition
sources. As other property dialogs do not have an "Ok" button that would
cause an update to happen, if the deferred flag was set the callback
would never be called.
Also clarifies the docs to reflect this.
Using UUIDs to store display references in obs-studio's settings file
allows us to "rediscover" devices even between restarts
(as CGDirectDisplayID changes between those) and select the same device.
This deprecates the following functions, replacing them with new
versions:
- `obs_output_can_begin_data_capture()` - now `*capture2()`
- `obs_output_initialize_encoders()` - now `*encoders2()`
- `obs_output_begin_data_capture()` - now `*capture2()`
The flags parameter was initially designed to support audio-only or
video-only operation of an output which had the `OBS_OUTPUT_AV` flag,
however, full support for that was never implemented, and there are
likely fundamental issues with an implementation, mainly that most
outputs are programmed assuming that there will always be at least one
audio and one video track. This requires new flags specifying support
for optional audio/video, among other things.
An implementation to allow audio/video to be optional is best done
using the flag technique above, with audio/video enablement specified
by whether media (raw, `video_t/audio_t`) or encoder (`obs_encoder_t`)
objects are specified.
Since every implementation I could find always specifies `flags` as 0,
I was able to safely conclude that immediately removing the parameter's
functionality is safe to do.
In its current form `struct dstr` is used in functions declarations
in the header file before the actual type is included (as `dstr.h` is
included after in `window-helpers.c`.
`clang-cl` is unable to compile this code because the function signature
defined in the header will not match the implementation in the source
code due to the implicit forward-declaration of `struct dstr` before
the type is included in the actual header.
