Since the helper function also needs to pack/unpack the resolution, the
pack/unpack functions were moved to the helper library and prefixed with
v4l2_ in order to avoid possible collisions.

This was added at a time where the source properties dialog did not
pop up automatically on source creation. Now when the properties are
displayed the first device in the select input will be selected by
default if there was none already specified by the source settings.

This will make the code cleaner and also save one redundant round of
device enumeration.

The capabilities flags that were used previously describe all
capabilities the physical device offers. This would cause devices
that are accessible through multiple device nodes to show up with
all device nodes while only one of the nodes might actually offer
the needed video capture capability.

If the device has more nodes the CAP_DEVICES_CAP flag might be set
in which case the device_caps field is filled with the capabilities
that only apply to that specific node that is opened.

This apparently can cause issues with certain modules (as noted by
faruton with his browser plugin)

This prevents certain issues I've encountered with devices where they
expect to shut down in a specific thread they started up in, as well as
a number of other issues, such as the configuration dialogs.

The configuration dialogs require that a message loop be present, and
this was not the case previously because everything was in the video
thread, which has no windows-specific code.

Configuration/crossbar/etc dialogs will now execute correctly.

This adds support for dynamic format changes on the fly.  Format,
resolution, sample rate, can all now be changed by the current
directshow device on the fly.

On an asynchronous video source, the source resolution is automatically
handled by the core, and set to the resolution of the last video data
that was sent.  There is no need to manually specify a resolution.

This is not a com pointer; it should not release/close the handle when
an & operator is used, it should only return the handle value.  Clearing
is only used on assignment.

This helps ensure that an asynchronous video source is played as close
to its framerate as possible, reduces the risk of duplication as
much as possible, and helps to ensure that playback is as smooth as
possible.

This prevents multiple needless calls to obs_source_get_frame and other
functions.  If the texture has already been processed, then just render
it as-is in any subsequent calls to obs_source_video_render.

Use default source settings for recording in pulse input

This doesn't really have a purpose, and appears to cause issues for
faruton's plugin, so removing it for the time being.

These values were erroneously using their opposing types for the source
frame format.

This is actually unnecessary now that there's a hard limit on the
maximum offset in which audio can be inserted.

This also assumes too much about the audio; it assumes audio is always
on, where as with some devices (such as the elgato) audio is not on
until the stream starts, and when the video has already incremented the
counter.

Audio that goes below the minimum expecting timing (current time -
buffering time) is automatically removed.  However, delayed audio is not
removed regardless of its delay.  This puts a hard cap of 6 seconds from
current time that the maximum delay audio can have.  This will also
prevent the circular buffer from dynamically growing too large.

Followup to d5643230, it apparently
still crashed (on slower machines?) when closing the properties window
via mouse (by clicking the X button)

Apparently there was no check for a null pointer file name.

This adds another statistics counter to the pulse plugin in order
to print the average latency reported by pulse when the source is
destroyed.

This adds the ability to get members via the -> operator.

Use a macro to prefix debugging messages instead of prepending manually.

When setting up the capture, the plugin will now query pulse for the default
format of the specific source instead of the server.
This is useful if a source has different settings than what the defaults are
for the server, e.g. when the source is an output with 5.1 surround sound
and the microphone input is mono while the server defaults to stereo sound.

Doing timestamp smoothing in obs-source.c is good because timestamps can
typically operate on a different timebase, however, obs-source.c can
also change that time base dynamically (such as with async video and
unexpected timestamp jumps), so in order to ensure that audio is
seamless in the output as well, perform timestamp smoothing in
audio-io.c as well just as an extra precautionary measure.