Placeholder sources are created when a plugin providing a source type is
unavailable. Since they're not marked as having audio any audio track
settings for them get lost. With this change we retain mixer information
if the source owns its id to avoid that.
New video formats introduced for ProRes 4444 encoding have not been
implemented in function calls used for video decoding, which makes the
switch statements non-exhaustive.
This does not functionally change the status quo (decoding ProRes 4444
files could still be broken because libobs does not explicitly handle
the colour format).
This reverts commit 90a409fe58.
Reverts #7077 for now. This really shouldn't be done so close to
release. This crash technically only happens under very niche scenarios,
and the fix seems to have some other potential issues. Prematurely
merged by Jim.
Only warn when the pointer provided to obs_source_release() is
non-NULL. In some custom usages of libobs, libobs may be freed before
OBS* smart pointers (like OBSSource) are destructed, leading to a
misleading warning if the pointers have already been cleared with
nullptr.
Previous behavior is basically:
- Clear OBS* pointers with nullptr
- Unload libobs
- Those smart pointers that were cleared will still call
obs_source_release() on destruct
- Warning appears
Timestamp of some of audio sources desync over the time and audio glitch
is suspected to be caused when the difference between `timestamp` and
`next_audio_ts_min` exceeds TS_SMOOTHING_THRESHOLD.
When such condition happens, leave a log message to investigate the
glitch of the audio.
HLG output uses MovieLabs-recommended procedure.
- If peak luminance is greater than 1000, use maxRGB EETF to 1000.
- Otherwise, don't tonemap.
- Then use normal HLG conversion procedure with gamma 1.2 (1000 nits).
This provides the framework for automatically compositing SDR and HDR
sources together. Source will need to leverage the new
video_get_color_space to opt into HDR support.
With this, you can now cast normal obs objects (services, outputs,
sources, encoders) to an obs_object_t, and then use obs_object_*
functions to get references, release references, and similar for weak
object references as well. This allows the ability for the frontend to
use an object of any of those types interchangeably in certain
situations without having to handle each specific type individually.
This is useful because the properties view in particular doesn't care
what type of object it uses, it just needs to be able to hold weak
references to abstract OBS objects.
This prevents double destroys from happening on sources and causing
crashes. If someone's doing a double destroy it'll probably crash anyway
but at least we'll know what happened if it does. (Jim note: I suspect
third party plugins are calling addref on sources when they shouldn't
be. Either that or we're missing something ourselves, but I suppose
we'll see.)
Removes all callbacks in use on sources right when a source is about to
be destroyed.
Fixes a crash where callbacks would still be executed while in a
destroyed state (particularly sidechain filters). Could also just mark
the source as being in a destroyed state and not accept anymore
obs_source_output_[audio/video] calls.
(This also modifies the UI)
The purpose of deferring destruction of sources is to ensure that:
1.) Hard locks from enumeration cannot occur with source destruction.
For example, if the browser source is destroyed while in the graphics
thread, the browser thread would wait for the graphics thread, but the
graphics thread would still be waiting for the browser thread, causing
a hard lock.
2.) When destroys occur during source enumeration, that the integrity of
the context's next pointer in the linked list can no longer be
compromised
3.) Source releases are fully asynchronous rather than having the risk
of stalling the calling thread
4.) We can wait for source destruction when switching scene collections
or when shutting down rather than hoping for threads to be finished
with sources.
This introduces a new requirement when cleaning up scene/source data:
the obs_wait_for_destroy_queue() function. It is highly recommended that
this function be called after cleaning up sources. It will return true
if at least one or more sources were destroyed. Otherwise it will return
false. Forks are highly advised to call this function manually on source
cleanup -- preferably in a loop, in conjunction with processing
outstanding OBS signals and UI events.
Holds an active reference to a source during signaling of the
`source_remove` signal, to prevent receivers from being given an
already-destroyed source.
- Call obs_source_remove(source)
- Receiver 1 gets signal, calls `obs_source_release(source)`
- Receiver 2 gets signal, calls `obs_source_release(source)`,
refs == -1, source destroyed
- Receiver 3 gets signal, source already destroyed, is forced to ignore
signal due to invalid source
This is a theoretical situation which is currently possible in
obs-websocket.
When sources output NULL frames, it is generally used to disable the
source and prevent the last frame from being left on screen. However,
when the source begins outputting video again, the last frame is
still in the async cache.
Depending on the stability of the source's frame output, this still
frame can end up being shown for 5+ output frames.
By freeing the async cache when a NULL frame is submitted, we avoid
the issue of old frames being re-displayed.
