Allows the ability to hint at encoders what format should be used.

This is particularly useful if libobs is currently operating in planar
4:4:4, but you want to force an encoder used for streaming to convert to
NV12 to prevent streaming issues.

This effect preserves detail of images that are scaled below half size
by using sampling 9 pixels.

This function sets the background color for a display

If you don't need to see what's displayed, then this is particularly
useful for two reasons:
1. It reduces the number of draw/present calls
2. It can prevent issues with certain hardware setups where rendering on
   a monitor hooked up to a separate card can experience slowdowns

Sometimes it can be useful to turn off rendering to the display in order
to reduce the number of draw calls and present calls.

These are basically just capabilities of a source, that and too much
text on one line.

Gets the output flags by its source type.

obs_source_process_filter tried to do everything in a single function,
but the problem is that effect parameters would not properly be
accounted for due to the way it internally draws, therefore it was
necessary to split the functions in to two, you first call
obs_source_process_filter_begin, then you set your effect parameters,
then you finally call obs_source_process_filter_end.  This ensures that
when the filter is drawn, that the effect parameters are set.

This allows a filter to skip its step and move on to the next target in
the chain without affecting performance.

These functions are primarily for use with filters, filters need to be
able to get the width/height of a target source without it necessarily
getting the post-filtered dimensions.

When a frame is processed by a filter, it comes directly from the
source's video frame cache.  However, if a filter is using or processing
those frames for whatever reason, there would be no guarantee that the
frames would persist during processing, and frames could eventually be
deallocated unexpected, for example when the resolution or format
changes.

So the solution is to implement simple reference counting for the frames
so that the frames will exist until they have been released by any
source or filter that's using them.

This returns a common effect useful for rendering an image with the
alpha channel overridden to 1.0.

Certain callbacks and API functions were a bit vague on when and how
they were supposed to be used.

Core API functions changed:
-----------------------------
EXPORT bool obs_reset_audio(struct audio_output_info *aoi);
EXPORT bool obs_get_audio_info(struct audio_output_info *aoi);

To:
-----------------------------
EXPORT bool obs_reset_audio(const struct obs_audio_info *oai);
EXPORT bool obs_get_audio_info(struct obs_audio_info *oai);

Core structure added:
-----------------------------
struct obs_audio_info {
	uint32_t            samples_per_sec;
	enum speaker_layout speakers;
	uint64_t            buffer_ms;
};

Non-interleaved (planar) floating point output is standard with audio
filtering, so to prevent audio filters from having to worry about
different audio format implementations and for the sake consistency
between user interfaces, make it so that audio is always set to
non-interleaved floating point output.

API changed from:
------------------------
EXPORT void obs_service_apply_encoder_settings(obs_service_t *service,
		obs_encoder_t *video_encoder,
		obs_encoder_t *audio_encoder);

void obs_service_info::apply_encoder_settings(void *data
			obs_encoder_t *video_encoder,
			obs_encoder_t *audio_encoder);

To:
------------------------
EXPORT void obs_service_apply_encoder_settings(obs_service_t *service,
		obs_data_t *video_encoder_settings,
		obs_data_t *audio_encoder_settings);

void obs_service_info::apply_encoder_settings(void *data
			obs_data_t *video_encoder_settings,
			obs_data_t *audio_encoder_settings);

These changes make it so that instead of an encoder potentially being
updated more than once with different settings, that these functions
will be called for the specific settings being used, and the settings
will be updated according to what's required by the service.

This fixes that design flaw and ensures that there's no case where
obs_encoder_update is called where the settings might not have
service-specific settings applied.

Enumerates filters that are currently present on a source.

The obs_source_get_width and obs_source_get_height functions need to
account for filters that may change their width/height such as a crop
filter or something similar.

As a side effect of this commit, because these functions need to lock
the filter mutex, these functions can no longer be used with a
const-qualified obs_source_t pointer.

Allows setting a specific position for scene items rather than just
up/down/top/bottom

obs_source_inc_showing and obs_source_dec_showing are used to indicate
that a source is showing or no longer being shown in a particular area
of the program outside from the main render view.

One could use an obs_view, but I felt like it was unnecessary because
using an obs_view just to display a single source feels somewhat
superfluous.

Instead of having services automatically apply encoder settings on
initialization (whether the output wants to or not), instead make it
something that must be explicitly called by the developer.  There are
cases where the developer may not wish to apply the service-specific
settings, or may wish to override them for whatever reason.

Before:                After:
obs_service_gettype    obs_service_get_type

It seems there was an API function that was missed when we were doing
our big API consistency update.  Unsquishes obs_service_gettype to
obs_service_get_type.

'obs_encoder_get_type' to get the type of an existing encoder, and
'obs_get_encoder_type' to get the type via its identifier

This allows the ability to get the codec of an encoder via its
identifier string

API changed:
--------------------------

void obs_output_set_audio_encoder(
		obs_output_t *output,
		obs_encoder_t *encoder);

obs_encoder_t *obs_output_get_audio_encoder(
		const obs_output_t *output);

obs_encoder_t *obs_audio_encoder_create(
		const char *id,
		const char *name,
		obs_data_t *settings);

Changed to:
--------------------------

/* 'idx' specifies the track index of the output */
void obs_output_set_audio_encoder(
		obs_output_t *output,
		obs_encoder_t *encoder,
		size_t idx);

/* 'idx' specifies the track index of the output */
obs_encoder_t *obs_output_get_audio_encoder(
		const obs_output_t *output,
		size_t idx);

/* 'mixer_idx' specifies the mixer index to capture audio from */
obs_encoder_t *obs_audio_encoder_create(
		const char *id,
		const char *name,
		obs_data_t *settings,
		size_t mixer_idx);

Overview
--------------------------
This feature allows multiple audio mixers to be used at a time.  This
capability was able to be added with surprisingly very little extra
overhead.  Audio will not be mixed unless it's assigned to a specific
mixer, and mixers will not mix unless they have an active mix
connection.

Mostly this will be useful for being able to separate out specific audio
for recording versus streaming, but will also be useful for certain
streaming services that support multiple audio streams via RTMP.

I didn't want to use a variable amount of mixers due to the desire to
reduce heap allocations, so currently I set the limit to 4 simultaneous
mixers; this number can be increased later if needed, but honestly I
feel like it's just the right number to use.

Sources:

Sources can now specify which audio mixers their audio is mixed to; this
can be a single mixer or multiple mixers at a time.  The
obs_source_set_audio_mixers function sets the audio mixer which an audio
source applies to.  For example, 0xF would mean that the source applies
to all four mixers.

Audio Encoders:

Audio encoders now must specify which specific audio mixer they use when
they encode audio data.

Outputs:

Outputs that use encoders can now support multiple audio tracks at once
if they have the OBS_OUTPUT_MULTI_TRACK capability flag set.  This is
mostly only useful for certain types of RTMP transmissions, though may
be useful for file formats that support multiple audio tracks as well
later on.

The comment says "these are different", but doesn't state why.
Actually, I should really rename the output flags so they're not flags,
but instead just "caps", because that's really all that they are.

If an async video source stops video for whatever reason, it would get
stuck on the last frame that was played.  This was particularly awkward
when I wanted to give the user the ability to deactivate a source such
as a webcam because it would get stuck on the last frame.

This allows sources to set default flags on creation without interfering
with user set flags

This allows the ability to see whether the source is being displayed
somewhere (though not necessarily active in the main output)

This flag is actually useful under a number of circumstances, and has
been requested a number of times.