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.
Also modifies libobs & deps/media-playback.
AV_CODEC_CAP_TRUNCATED was removed in avcodec 60 [1].
We ifdef the code depending on it to allow compilation.
[1] avcodec: remove FF_API_FLAG_TRUNCATED
3ceffe7839
Signed-off-by: pkv <pkv@obsproject.com>
This reverts commit bcb73cb599.
Annoyingly, this breaks WebEx, likely due to their own bug. This only
breaks Discord under very specific circumstances due to their own bug,
so if I'm going to choose between Discord breaking under very specific
circumstances that rarely occur versus choosing WebEx not working at
all, I'm going to just let Discord be broken under specific/rare
circumstances.
I hate DirectShow.
Certain programs can start the virtualcam filter, then they may choose
to call `Stop()` on the filter, call `SetFormat()` to change the
resolution, then call `Run()` again to start the filter again. The
Windows virtual camera filter did not account for this, thus if the
resolution was different, it had potential to cause a crash.
To fix this, store the last filter resolution, then check the resolution
every frame, and if it changes, reset the scaling information.
(Author note: This code is unclean. What we need to do with the virtual
camera filter is make it only create the thread on `Run()`, then join
the thread on `Stop()`. It's currently a bit complicated to make it do
that at the moment, so this code is a kind of an annoying stopgap for
now.)
The `cx`/`cy`/`interval` variables specifically specify the
OBS/placeholder resolution/interval. The resolution may not be the same
as the filter's resolution (when scaling is used).
Instead, prefix these variables with `obs_` to improve clarity.
Sending frames on initial pause seems to cause an odd crash on
subsequent frame calls.
(Note by author: I do not know why the crash happened because code
beyond OBS is a proprietary black box. I suspect it's just a bug in
WebRTC or something, but I can't know for sure. This is incredibly
frustrating. But at least this particular crash seems to be fixed.
...for now.)
This reverts commit a36b5bee99.
After this commit was merged, apparently devices were not functioning
correctly for some people. Especially regarding their internal settings.
Just revert it for now.
