Effectively reverting parts of d314d47, this commit removes the new
functions that got added to remove the flags parameter. Instead, it just
marks the parameter as unused and documents this. Having what is
effectively an API break just to remove a parameter is a bit overkill.
The other parts of d314d47 which cleaned up the usage of the flags
parameter are untouched here.
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.
Adds links to release functions for "new/incremented reference".
Extra info on signal handler.
Parameter description on `obs_property_list_add_*` functions, since
their parameter `name` can be confusing and it is unclear which value
is stored in obs_data_t.
Adds clarifications on calldata_ptr.
Rec. 2020 is really an SDR spec, but I think HDR10 made it okay to slap
PQ on it, call it an HDR spec. Rec. 2100 came along after and formally
allowed the use of PQ/HLG, so we should use 2100 instead.
Deprecates:
obs_source_addref()
obs_output_addref()
obs_encoder_addref()
obs_service_addref()
obs_scene_addref()
These functions should be considered unsafe and not used. Instead, use:
obs_source_get_ref()
obs_output_get_ref()
obs_encoder_get_ref()
obs_service_get_ref()
obs_scene_get_ref()
These functions return a pointer to the incremented object only if the
object is still valid, otherwise they will return null, indicating that
the object is no longer valid or is unsafe to use.
The reason why this is being done is because certain third party plugins
seem to be using addref, and are somehow managing to call addref on
sources that have already been fully released. For the sake of safety,
almost all usage of these functions within OBS have also been replaced
as well.
This implements pausing of outputs. To accomplish this, raw audio/video
data is halted to the encoders or raw output. Pausing is as precisely
timed as possible according to the timing of the obs_output_pause call,
and audio data will be spliced down to the exact audio sample in
accordance to that timing at the start/end marks.
Outputs that support this (outputs used for recording) can set the
OBS_OUTPUT_CAN_PAUSE capability flag.
(This commit also modifies the UI, obs-ffmpeg, and obs-output modules)
Fixes a long-time regression where the program would lock up if an
encode call fails. Shuts down all outputs associated with the failing
encoder and displays an error message to the user.
Ideally, it would be best if a more detailed error could be displayed to
the user about the nature of the error, though the primary problem is
the encoder errors are typically not something the user would be able to
understand. The current message is a bit of a generic error message;
improvement is welcome.
Another suggestion is to try to have the encoder restart seamlessly,
though it would take a significant amount of work to be able to make it
do something like that properly, and it sort of assumes that encoder
failures are sporadic, which may not necessarily be the case with some
hardware encoders on some systems. It may be better just to use another
encoder in that case. For now, seamless restart is ruled out.
