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 is going to be used for other code as well, so may as well put it
in its own file.

Waiting for the first packet to arrive before sending the headers helps
prevent issues with certain types of encoders that may not get their
header/SEI until the first packet has been received.

If an encoder did not possess any SEI data, it would never send data at
all because the sent_first_packet wasn't set despite the first packet
being sent.

Added obs_avc_keyframe that returns whether an avc packet is a keyframe
or not.  This function is particularly useful for when writing custom
encoder plugins.

I encountered some cases where I needed to use these enumerations
outside of the file, so this allows other modules to use AVC
enumerations without having to redefine them each time.  Especially
useful for custom encoder modules.

I neglected to surround some files with extern "C", so if something
written with C++ used the files it would cause function exports to not
be mangled by it correctly.

I don't know why on earth I set the limit to 16000.  There's no reason
why there should really be a low hard limit.

In certain cases the video thread could end up trying to lock itself
recursively.  This just allows the mutexes to safely be locked
recursively.

linux x11: get monitors with x11 if xinerama is not found

This adds bicubic and lanczos scaling capability to libobs to improve
scaling quality and sharpness when the output resolution has to be
scaled relative to the base resolution.  Bilinear is also available,
although bilinear has rather poor quality and causes scaling to appear
blurry.

If the output resolution is close to the base resolution, then bilinear
is used instead as an optimization, as there's no need to use these
shaders if scaling is not in use.

The Bicubic and Lanczos effects are also exposed via exported function
to allow the ability to use those shaders in plugin modules if desired.

The API change adds a variable 'scale_type' to the obs_video_info
structure that allows the user interface to choose what type of scaling
filter should be used.

Copying this binary is kind of unnecessary because it's something that
everyone has as long as they update DirectX, and isn't something we can
distribute because it's a Microsoft DLL.

This causes x264 to use the currently set color space and color range
of the video media.  This helps prevent issues with decoding where the
colors wouldn't look right due to the fact that these settings were
never specified to x264, and prevents darkness and brightness from
looking washed out due to a potentially incorrect color range.

This was an important change because we were originally using an
hard-coded 709/partial range color matrix for the output, which was
causing problems for people wanting to use different formats or color
spaces.  This will now automatically generate the color matrix depending
on the format, color space, and range, or use an identity matrix if the
video format is RGB instead of YUV.

This is useful for keeping track of what the current colorspace/range is
if a YUV format is being used.

This adds the windows version of game capture.

New features:

- An option to hook any fullscreen application automatically (that
  doesn't have borders) so that no specific window configuration is
  required.  Definitely a sorely needed feature

- An option to force memory capture for the sake of compatibility with
  things such as SLI, multi-adapter setups (usually laptops), as well as
  the ability to be used with the OpenGL renderer

- An optimization option to force scaling on the GPU before texture
  transfer, reducing the transfer bandwidth (which is especially
  important for compatibility capture)

- An optimization option to limit framerate to the current OBS framerate
  to improve capture performance (mostly useful for compatibility
  capture)

- An option to capture third-party overlays (such as steam)

- Logging improvements, game capture log will now be sent via pipe
  instead of written to a separate file, making diagnosing problems a
  little bit easier

This library is a completely refactored and rewritten version of the
original graphics hook.  The code is more clean, readable, and has a
variety of new features, such as scaling and forcing memory capture.

Currently, only D3D9, 10, and 11 are implemented.  (This commit may be
updated on this branch)

This program simply injects a library in to the target progress using
SetWindowsHookEx.

Before, game capture would find addresses to important graphics
functions by creating a graphics context for the desired API inside of
the hook, and then find the function addresses that way.

The big problem with that is that the context could often cause the
hooked application to crash, especially if another hook was active.

This bypasses that entire need by a simple console application that
creates the contexts, finds the hook address offsets and then returns
them via console output.

These headers allow Direct3D 8 to be used.

This header contains global defines, structures, and helper inline
functions for the graphics hook that will be shared between game
capture, the hook, and the get-graphics-addrs helper application.

These inline functions simplify the process of using windows IPC
objects, such as mutexes and events.

These functions allow the safe hooking of windows functions,
specifically windows API functions that may or may not have built-in
machine code to help aid in reverse chain hooks.

If a new hook is applied to an existing forward hook, that hook will be
preserved to prevent that new hook's data from being removed
unintentionally.

Hopefully with all these precautions this will reduce the likelihood of
crashes and abnormal hook behavior, while allowing existing hooks to be
preserved, and allowing new hooks to be applied.

These functions allow you to insert items at a specific index in a list
instead of being forced to always append to the end.

The glDebugMessageCallback function will set a callback that will relay
all messages coming from the driver (on supported drivers at least).
For nvidia, sometimes there are a lot of irrelevant messages, which is
nice depending on the type of application you're writing.

I actually at first thought these messages were important, but it turns
out that they're almost always irrelevant and not actually warnings.
Most of the messages at a certain type/severity are mostly for debugging
purposes or minor hints about how to maximize performance, so
unfortunately there ends up being a lot of pointless spam in the debug
output.

The particular performance messages are related to optimizations you can
get via multithreading, and are optimizations you would expect for games
more than for this type of application.  They don't really apply for our
use cases most of the time.

High severity messages however are not omitted regardless of message
type.

These messages can be enabled again by simply defining the
SHOW_ALL_GL_MESSAGES macro.

Just for a quick background: D3D's fmod intrinsic is very imprecise.
Naturally floating points aren't precise at all, and when the numbers
you're dealing with become very large, it can often be off by 0.1 or
more.

However, apparently 0.1 isn't enough of an offset to ensure a proper
value when using the fmod intrinsic and then flooring the value.  0.2
seems to fix the issue and make the image display properly.

Originally I made the "win_pipe" stuff for named pipes on windows but it
was argued that it should be available to all modules and
programs/libraries that the modules might communicate with.

It cannot really be put in to libobs due to the fact that there would
hypothetically be things unrelated to libobs that might want to use it,
so I felt the best option was just to create a simple static library
specific for interprocess communication.

Non-windows versions of these functions are still yet to be implemented.

This allows get_window_exe to be used with other .c files in the module.

This fixes a bug where if INCLUDE_MINIMIZED was set and the window size
was (0, 0), the window would still be excluded from the resulting list
that was created.

OpenProcess can often be misinterpreted as invasive.  To avoid it, a
simple obfuscation workaround does the trick.