Change default audio smoothing threshold to 50ms

70 milliseconds is a bit too high for the default audio timestamp
smoothing threshold.  The full range of error thus becomes 140
milliseconds, which is a bit more than necessary to worry about.  For
the time being, I feel it may be worth it to try 50 milliseconds.
Fix a typo ('timetamp')
Add flag to obs_source_frame for unbuffered video

Add 'flags' member variable to obs_source_frame structure.

The OBS_VIDEO_UNBUFFERED flags causes the video to play back as soon as
it's received (in the next frame playback), causing it to disregard the
timestamp value for the sake of video playback (however, note that the
video timestamp is still used for audio synchronization if audio is
present on the source as well).

This is partly a convenience feature, and partly a necessity for certain
plugins (such as the linux v4l plugin) where timestamp information for
the video frames can sometimes be unreliable.
linux-v4l2: Add 'unbuffered' property

This allows the user to select whether to use unbuffered video or not.
Unbuffered video cause the video frames to play back as soon as they're
received, rather than be buffered and attempt to play them back
according to the timestamp value of each frame.
Use MAX_TS_VAR for timestamp jump detection

This combines the 'direct' timestamp variance threshold with the maximum
timestamp jump threshold (or rather just removes the max timestamp jump
threshold and uses the timestamp variance threshold for both timestamp
jumps and detecting timestamps).

The reason why this was done was because a timestamp jump could occur at
a higher threshold than the threshold used for detecting OS timestamps
within a certain threshold.  If timestamps got between those two
thresholds it kind of became a weird situation where timestamps could be
sort of 'stuck' back or forward in time more than intended.  Better to
be consistent and use the same threshold for both values.
Detect audio time values within OS time thresh.

If audio timestamps are within the operating system timing threshold,
always use those values directly as a timestamp, and do not apply the
regular jump checks and timing adjustments that normally occur.

This potentially fixes an issue with plugins that use OS timestamps
directly as timestamp values for their audio samples, and bypasses the
timing conversions to system time for the audio line and uses it
directly as the timestamp value.  It prevents those calculations from
potentially affecting the audio timestamp value when OS timestamps are
used.

For example, if the first set of audio samples from the audio source
came in delayed, while the subsequent samples were not delayed, those
first samples could have potentially inadvertently triggered the timing
adjustments, which would affect all subsequent audio samples.
Add timestamp circlebuf for video input/output

At the start of each render loop, it would get the timestamp, and then
it would then assign that timestamp to whatever frame was downloaded.
However, the frame that was downloaded was usually occurred a number of
frames ago, so it would assign the wrong timestamp value to that frame.

This fixes that issue by storing the timestamps in a circular buffer.
Fix bug removing output from its previous encoders

When the output sets a new audio/video encoder, it was not properly
removing itself from the previous audio/video encoders it was associated
with.  It was erroneously removing itself from the encoder parameter
instead.
Fix a bug where audio would not restart (outputs)

Apparently I unintentionally typed received_video = false twice instead
of one for video and one for audio.

This fixes a bug where audio would not start up again on an output that
had recently started and then stopped.
media-io: Fix repeating video timestamps

In video-io.c, video frames could skip, but what would happen is the
frame's timestamp would repeat for the next frame, giving the next frame
a non-monotonic timestamp, and then jump.  This could mess up syncing
slightly when the frame is finally given to an outputs.
util: Fix bug with darray_erase_range

Did not multiply the element size for the memory move operation.
Fix a major sync bug

This bug would happen if audio packets started being received before
video packets.  It would erroneously cause audio packets to be
completely thrown away, and in certain cases would cause audio and video
to start way out of sync.

My original intention was "don't accept audio until video has started",
but instead mistakenly had the effect of "don't start audio until a
video packet has been received".  This was originally was intended as a
way to handle outputs hooking in to active encoders and compensating
their existing timestamp information.

However, this made me realize that there was a major flaw in the design
for handling this, so I basically rewrote the entire thing.

Now, it does the following steps when inserting packets:

- Insert packets in to the interleaved packet array

- When both audio/video packets are received, prune packets up until the
  point in which both audio/video start at the same time

- Resort the interleaved packet array

I have tested this code extensively and it appears to be working well,
regardless of whether or not the encoders were already active with
another output.
Revert "linux-v4l2: Add 'unbuffered' property"

This reverts commit cd306d975a5711e6c9bffe9943ba6e78d346828b.

This removes the 'unbuffered' property for the time being.  There should
be a better way of handling this, such as using system timestamps.
Also, the obs_source_frame::flags member needs to be removed and
replaced with something a bit more ideal.
Revert "Add flag to obs_source_frame for unbuffered video"

This reverts commit c3f4b0f01802692fee33c0504e16189def6063c4.

The obs_source_frame should not need to take flags to do this.  This
shouldn't be a setting associated with the frame, but rather a setting
associated with the source itself.  This was the wrong approach to
solving this particular problem.
Add optional source flags

This moves the 'flags' variable from the obs_source_frame structure to
the obs_source structure, and allows user flags to be set for a specific
source.  Having it set on the obs_source_frame structure didn't make
much sense.

OBS_SOURCE_UNBUFFERED makes it so that the source does not buffer its
async video output in order to try to play it on time.  In other words,
frames are played as soon as possible after being received.

Useful when you want a source to play back as quickly as possible
(webcams, certain types of capture devices)
linux-v4l2: Add 'Use System Timing' property

Due to potential driver issues with certain devices, the timestamps are
not always reliable.  This option allows of using the time in which the
frame was received as a timestamp instead.
linux-v4l2: Start timestamps from 0 per device

When a new device starts up, make it so that the first timestamp that
occurs starts from 0.  This prevents the internal source timestamp
handling from trying to buffer new frames to the new timestamp value in
case the device changes.
mac-syphon: Add "Allow Transparency" property

Transparency is now disabled by default, so that alpha values from
injected back buffers don't propagate to OBS (e.g. Minecraft doesn't
render properly in OBS unless "Allow Transparency" is disabled)
Remove ingest server live-ord.twitch.tv from services.json

Server doesn't exist anymore
https://api.twitch.tv/kraken/ingests
http://blog.twitch.tv/2014/09/service-update-chicago-point-of-presence-closure/
Merge pull request #289 from Gol-D-Ace/remove-twitch-ingest-server

Remove ingest server live-ord.twitch.tv from services.json