Originally there was an issue using FLAC for audio in AVI files, AVI
files wouldn't play back with some players.  Because FLAC doesn't work,
and lossless should be lossless, instead just used uncompressed WAV
data for the lossless audio, which is always supported.

This reverts commit 6e203109.

FLAC doesn't work properly in AVI files, and MKV files don't work in
vegas.  So, sadly the only solution is to use lossless audio at a super
high bitrate for the time being.

(This commit also modifies the UI)

Closes jp9000/obs-studio#502

Closes jp9000/obs-studio#487

Apple wants to get people to move over to their own crypto APIs instead
of using OpenSSL, so disable the warning in the files where OpenSSL is
used for the time being.

A lot of people had the problem where they'd initialize video settings
with 0 width or height on their output resolution value.  This just
changes it so that the user always has a valid resolution so video
initialization doesn't just outright fail.

Originally an intentional design decision, right-clicking would also
perform selection, which is actually rather annoying and unnecessary.

It was mistakenly using ac3 at a high bitrate -- lossless should be
lossless, both video and audio.

Makes the log message a bit less confusing

If the media source is set to restart on activation, it also shuts down
when not active.  However, it would *always* start regardless of
active/inactive when the source is first created.  It shouldn't do that,
it should start up only when it becomes active.

If scene duplication mode is disabled and studio mode is turned on, it
would always initially duplicate scene regardless of whether scene
duplication mode was activated or not.

If obs_source::audio_ts is set to 0 (such as by discard_if_stopped in
obs-audio.c), but the push_back variable in the source_output_audio_data
function in obs-source.c was being set to true (meaning it's within the
seamless audio smoothing threshold), it would cause it to never reset
the obs_source::audio_ts value, and thus all audio data from the source
would become perpetually ignored by the audio subsystem until there was
finally some sort of timestamp jump that caused it to call
source_output_audio_place, and thus reset obs_source::audio_ts.

obs_source::audio_ts is only reset in source_output_audio_place, not in
source_output_audio_push_back, so the most simple solution is to just
call source_output_audio_push_back is obs_source::audio_ts is 0.

Only allow discard_if_stopped to be called if the audio data is marked
as pending, and the pending audio data is below the audio tick threshold
size.

This code causes audio data in general to be reset (and subsequently
deleted).  It should just be marked as pending and ignored until the
data is ready.  The discard_if_stopped function will serve the same
purpose if the source's audio has actually stopped.

There's technically no need to clear the audio data here, nor is there
any need to try to trick the timestamp in to a different position.  It
can simple just reset the audio timing.

Prevents a possible case where audio data might be deleted when it's not
necessary to delete any.

Fixes a bug introduced in 6407707a where if you open the settings
window the settings would always think there were new changes.  It was
marking a control as changed when it shouldn't be

Add latest translations from CrowdIn

This variable is used to detect whether audio has stopped -- if audio
stops, it detects that no new data is coming in, and resets the audio
position so that it eliminates the chance of causing the audio buffering
to go haywire if audio starts up again.  However, this variable was not
being reset every time the value changes, which it should.

Sometimes the A and B sources of a transition would a large difference
in their timestamps, and the calculation of where to start the audio
data for one of the sources could be above the tick size, which could
cause a crash.

If the circular audio buffer of the source has data remaining that's
less than the audio frame tick count (1024 frames), it would just leave
that audio data on the source without discarding it.  However, this
could cause audio buffering to increase unnecessarily under certain
circumstances (when the next audio timestamp is within the timestamp
jump window), so it would append data to that circular buffer despite
the audio stopping that long ago, causing audio buffering to have to
increase to compensate.

Instead, just discard pending audio if it hasn't been written to.  In
other words, if the audio has stopped and there's insufficient audio
left to continue processing.

With the new audio subsystem, audio buffering is minimal at all times.
However, when the audio buffering is too small or non-existent, it would
cause the audio encoders to start with a timestamp that was actually
higher than the first video frame timestamp.  Video would have some
inherent buffering/delay, but then audio could return and encode almost
immediately.  This created a possible window of empty time between the
first encoded video packet and the first encoded audio packet, where as
audio buffering would cause the first audio packet's timestamp to always
be way before the first video packet's timestamp.  It would then
incorrectly assume the two starting points were in sync.

So instead of assuming the audio data is always first, this patch makes
video wait for audio data comes in, and conversely buffers audio data
until video comes in, and tries to find a starting point within that
video data instead, ensuring a synced starting point whether audio
buffering is active or not.

When starting a multi-track output, attempt to pair the video encoder
with one of the audio encoders to ensure that the video and audio
encoders start as close together in time as possible.  This ensures the
best possible audio/video syncing point when using multi-track audio
output.

When using multi-track audio, encoders cannot be paired like they can
when only using a single audio track with video, so it has to choose the
best point in the interleaved buffer as the "starting point", and if the
encoders start up at different times, it has to prune that data and wait
to start the output on the next video keyframe.  When the audio encoders
started up, there was the case where the encoders would take some time
to load, and it would cause the pruning code to wait for the next
keyframe to ensure startup syncing.

Starting the audio encoders before starting the video encoder should
reduce the possibility of that happening in a multi-track scenario.

In a multi-track scenario it was not taking in to consideration the
possibility of secondary audio tracks, which could have caused desync on
some of the audio tracks.

Gets the index of the first interleaved packet of a given/type and audio
index

audio_input_buf should never be accessed outside of audio_buf_mutex.

The seamless audio looping code would erroneously trigger for things
that weren't loops, causing the audio data to continually push back and
ignore timestamps, thus going out of sync.

There does need to be loop handling code, but due to the fact that other
things may need to trigger this code, it's best just to clear the audio
data and start from a fresh sync point.  Unfortunately for the case of
loops, this means the window in which audio data loops and video frames
loop need to be muted.

This is an additional method/helper that prevents composite sources from
treating non-audio sources as audio sources.

Fixes an issue where audio data would not be popped if they were not
activated/presenting.  This would cause the audio subsystem to
needlessly buffer when they were reactivated again.  Rendering all audio
sources (excuding composite/filter sources) helps ensure that audio data
is always popped and not left to pile up.

When the new UI was put in, the action shortcuts were unintentionally
removed from the list boxes.

UI: Fix GCC 4.8 compilation issue