This allows the ability to output the audio of the device as desktop
audio (via the WaveOut or DirectSound audio renderers) instead of
capturing the audio only.
In the future, we'll implement audio monitoring which will make this
feature obsolete, but for the time being I decided to add this option as
a temporary measure to allow users to play the audio from their devices
via the DirectShow output.
I'm putting this option in due to the fact that there are legitimate
cases where a device may flip the output unexpectedly (such as the
Datapath VisionDVI-DL running in RGB video format), and that a user may
want to be able to view the source in a projector or source properties
without the image being inverted.
My original line of thinking was that they can just use a transform to
flip the image, but I felt this problem impacts rendering everywhere,
such as in the projector and in the source properties, so having it as
an option in the source itself feels like the best way to ensure that a
user can get it to render everywhere properly.
The DirectShow input source would always turn on first use, whether the
user wanted it to or not. I feel like having an activate/deactivate
option is a really nice thing to have, and makes configuration feel a
little bit less awkward.
Allow the user to select whether to buffer the source or not. The
settings are auto-detect, on, and off. Auto-Detect turns it off for
non-encoded devices, and on for encoded devices.
Webcams, internal devices, and other such things on windows do not
really need to be buffered, and buffering incurs a tiny bit of delay, so
turning off buffering is actually a little better for non-encoded
devices.
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.
This implements audio support, allowing not only the ability to capture
the built-in audio from the video device's audio capture pin, but also
the ability to override the default audio with a custom audio device.
The DShowInput::Update function was split up and refactored a bit, as it
was getting a bit large and messy.
dodgepong
jp9000
Ben Torell
BtbN