Status output related to OBS configuration is prefixed with the string
"OBS" and added padding for enabled and disabled features. This padding
was not aligned between platforms.
By moving the padding and prefix decoration into its own function,
both elements are controlled in a single place. CMake scripts were
changed to use this new function `obs_status` instead of using CMake's
`message` function directly.
This updates the libdshowcapture submodule to the latest commit.
This also changes win-dshow CMakeList to ensure compatibility.
Full commit list:
- Add support of RGB24 format
- CMake: Add Win32 libs instead of pragma directives.
- Implement FindPin
- Simplify error handling
- Fix log level of DebugHR
- Use default constructor instead of empty function
- Use std::move instead of copy where appropriate
- Mark some strings as const
This adds two batch scripts to install and uninstall the virtual cam
devices for installations where the installer could not be used. Most
commonly, this is for portable installations or those who prefer the
.zip file.
The virtual camera adds the ability to use the output of OBS itself as a
camera that can be selected within other Windows applications. This is
very loosely based upon the catxfish virtual camera plugin design.
There is a shared memory queue, but instead of having 10-20 frames in
the queue, there are now only 3 frames in the queue to minimize latency
and reduce memory usage. The third frame is mostly to ensure that
writing does not occur on the same frame being read; the delay is merely
one frame at all times.
The frames of the shared memory queue are NV12 instead of YUYV, which
reduces the memory and data copied, as well as eliminate unnecessary
conversion from NV12. Some programs (such as chrome, which uses webrtc
to capture) do not support NV12 however, so an I420 conversion is
provided, which is far less expensive than YUYV. The CPU cost of NV12
-> I420 is negligible in comparison.
The virtual camera filter itself is based upon the output filter within
the libdshowcapture library, which was originally implemented for other
purposes. This is more ideal than the Microsoft example code because
for one, it's far less convoluted, two, allows us to be able to
customize the filter to our needs a bit more easily, and three, has much
better RAII. The Microsoft CBaseFilter/etc code comprised of about 30
source files, where as the output filter comprises of two or three
required source files which we already had, so it's a huge win to
compile time.
Scaling is avoided whenever possible to minimize CPU usage. When the
virtual camera is activated in OBS, the width, height, and frame
interval are saved, that way if the filter is activated, it will always
remember the last OBS resolution/interval that the virtual camera was
activated with, even if OBS is not active. If for some reason the
filter activates before OBS starts up, and OBS starts up with a
different resolution, it will use simple point scaling intermittently,
and then will remember the new scaling in the future. The scaler could
use some optimization. FFmpeg was not opted for because the FFmpeg DLLs
would have to be provided for both architectures, which would be about
30 megabytes in total, and would make writing the plugin much more
painful. Thus a simple point scaling algorithm is used, and scaling is
avoided whenever possible.
(If another willing participant wants to have a go at improving the
scaling then go for it. But otherwise, it avoids scaling whenever
possible anyway, so it's not a huge deal)
Code submissions have continually suffered from formatting
inconsistencies that constantly have to be addressed. Using
clang-format simplifies this by making code formatting more consistent,
and allows automation of the code formatting so that maintainers can
focus more on the code itself instead of code formatting.
Remove the .lib postfix from strmiids
ksuser provides KSCATEGORY_ENCODER and similar GUIDS used
wmcodecdspuuid provides MEDIASUBTYPE_H264 MEDIASUBTYPE_RAW_AAC1 and
MEDIASUBTYPE_I420 so no need to define them in dshow-formats. The
submodule will have to be updated to support this change.
This adds support for the AverMedia C985 encoder (which is available on
C985 capture cards) as well as the C353 hardware encoder (which is
currently available on the X99S Gaming 9 motherboards).
These encoders have some limitations, such as limited resolutions
(1280x720 and 1024x768), a max GOP size of 30, and the encoder format
only supports YV12, which requires conversion if the current output
format isn't the same. The C985 and C353 encoders seem to be pretty
much identical, although it seems like the C353 has a bit more efficient
encoding.
I don't believe these are really suitable for streaming, as they do not
really have the encoding efficiency needed to stream at lower bitrates,
and seem to only support variable bitrate. However, for recording these
encoders are quite nice to have available, and work quite well.
The main module code was originally all packed in to the win-dshow.cpp
file, which isn't exactly ideal or clean if one wants to add other
things to the module as a whole.
Previously, due to a bug in libdshowcapture, the NV12 format was
actually being used for YV12 erroneously, and no actual support for YV12
existed. This fixes the bug with NV12 and adds support for YV12.
This covers the basics of devices. Mostly functional but not at 100%
yet. Uses 'libdshowcapture' library to capture directshow video/audio.
Both libdshowcapture and the plugin still need some work. Should at
least capture basic webcams and capture cards for the time being.
