(This commit also modifies the decklink, linux-v4l2, mac-avcapture,
obs-ffmpeg, and win-dshow modules)
Originally, async buffering for sources was supposed to be a
user-controllable flag. However, that turned out to be less than ideal
because sources (such as the win-dshow plugin) were programmed with
automatic control over their buffering (such as automatically detecting
USB 2.0 capture devices and then enabling in those cases).
The fact that it was a flag caused a design flaw to where buffering
values would be overwritten when a source is loaded from save data.
Because of that, this flag is being deprecated and replaced with a
specific function to enable unbuffered mode instead.
Certain types of sources (display captures, game captures, audio
device captures, video device captures) should not be duplicated. This
capability flag hints that the source prefers references over full
duplication.
API changed from:
obs_source_info::get_name(void)
obs_output_info::get_name(void)
obs_encoder_info::get_name(void)
obs_service_info::get_name(void)
API changed to:
obs_source_info::get_name(void *type_data)
obs_output_info::get_name(void *type_data)
obs_encoder_info::get_name(void *type_data)
obs_service_info::get_name(void *type_data)
This allows the type data to be used when getting the name of the
object (useful for plugin wrappers primarily).
NOTE: Though a parameter was added, this is backward-compatible with
older plugins due to calling convention. The new parameter will simply
be ignored by older plugins, and the stack (if used) will be cleaned up
by the caller.
Add the include directories found by cmake to the v4l2 plugin.
This allows for the plugin to compile when the vl42 headers were
found in a directory that is not normally in the search path of the
compiler (e.g. /usr/local/include)
Fix build errors for older versions of the api where
VIDIOC_ENUM_DV_TIMINGS was defined but V4L2_IN_CAP_DV_TIMINGS was not.
I was under the impression that they were added at the same time, but
apparently i was wrong there.
Thanks to kmoore@FreeBSD.org for spotting this on FreeBSD.
Add compatibility with older versions of the api by not failing to
build when the VIDIOC_ENUM_DV_TIMINGS is missing. In older versions
of the api there was a different system to get dv-timing presets, which
was replaced by the current enumeration system with Linux 3.4.
This will allow for the plugin to be built against older versions of the
api by disabling the enumeration support, thus reducing the
functionality for some devices.
Improve compatibility with older versions of the api by not requiring
V4L2_CAP_DEVICE_CAPS. If we don't have this, we fall back to using the
capabilities member for the whole device instead of the device_caps
member for the currently selected subdevice. Just like we would do if
the device would not support this.
The new device_caps field was introduced with Linux 3.3.
Add BGRX and BGRA as supported video formats, since obs can handle them
directly. I unfortunately missed those when i initially wrote this
mapping due to my webcam not offering those formats.
Add a source property to enable buffering of frames, which is enabled by
default. This replaces the old "Use system timing" option by setting the
unbuffered source flag instead of using different timestamps.
While similar in intentions to the old option, this method should reduce
latency even more.
Use the macro from the mac capture plugin to convert the fourcc integer
value to a string. This makes the debug statement for the pixel format
slightly more readable for the casual developer.
Remove the "Leave Unchanged" option for the input and video format
select.
This option was primarily added for cases in which the
resolution and framerate are set by another program or the capture
device itself and the values are not directly supported by the plugin.
One major usecase here would be capture devices for tv signals which
might be set to a spcific resolution and refresh rate, and might fail
to initialize in case any other combination of those settings is forced.
In case of the input this option did not make much sense, as the first
input is probably the best default option in most cases.
For the video format this default is even bad in some cases. If an
format emulated by libv4l2 is selected for example, this will usually
configure the device to use mjpeg with libv4l2 converting it to some
format obs can use. When obs or the source is then restarted and the
"Leave Unchanged" is enabled the plugin will fail, because it will only
notice that the device is set to mjpeg, without any knowledge about the
possibility of letting libv4l2 handle the conversion.
Using the first available and supported format is not nescessarily the
best choice, but still preferable to some random format that will
cause the plugin to not capture at all. Forcing a choice here will
hopefully also make the plugin behaviour more predicatable for the user.
Remove the constraint for device inputs to be of the type "CAMERA".
This was added under the false assumption that inputs of the type
"TUNER" are only used for control purposes.
