Reverts much of PR #11906 in favor of a different way to detect whether
or not the output capabilities must be reset.
The new approach will contain false positives for which the workaround
is not needed but it won't have negative side effects.
Make sure to use the invalid fd -1 when the output is not opened, and
only close valid fds. If fd 0 is closed, then this closes stdin. The
second time this happens, some other important fd will have become fd 0,
breaking something.
This causes random things to break (browser/CEF in reports, but really
it could be anything) as the wrong fds get closed.
Add function that tries to reset v4l2loopback output for module versions
from 0.12.5 to 0.12.7. If successful, then set flag that STREAMON and
STREAMOFF are necessary each time the device is opened/closed.
These days you might capture card a 175Hz monitor with a framerate
defined as 10000000/57143 that doesnt fit in a short. And reporting a
negative FPS in that case isnt very helpful.
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.
Matt Gajownik