Previously a NULL item would cause a crash when reading transform info.
The crash can be reproduced by e.g. editing scenes.json so that two
scenes contain each other. Example scenes.json:

{
    "current_scene": "Scene",
    "sources": [
        {
            "flags": 0,
            "id": "scene",
            "mixers": 0,
            "name": "Scene",
            "settings": {
                "items": [
                    {
                        "align": 5,
                        "bounds": {
                            "x": 1440.0,
                            "y": 900.0
                        },
                        "bounds_align": 0,
                        "bounds_type": 2,
                        "name": "Scene 2",
                        "pos": {
                            "x": 0.0,
                            "y": 0.0
                        },
                        "rot": 0.0,
                        "scale": {
                            "x": 1.0,
                            "y": 1.0
                        },
                        "visible": true
                    }
                ]
            },
            "sync": 0,
            "volume": 1.0
        },
        {
            "flags": 0,
            "id": "scene",
            "mixers": 0,
            "name": "Scene 2",
            "settings": {
                "items": [
                    {
                        "align": 5,
                        "bounds": {
                            "x": 1.0,
                            "y": 1.0
                        },
                        "bounds_align": 0,
                        "bounds_type": 0,
                        "name": "Scene",
                        "pos": {
                            "x": 854.0,
                            "y": -520.0
                        },
                        "rot": 0.0,
                        "scale": {
                            "x": 1.75,
                            "y": 1.7562724351882935
                        },
                        "visible": true
                    }
                ]
            },
            "sync": 0,
            "volume": 1.0
        }
    ]
}

Display "No properties available" text in the property view if there are
no properties available.

Closes Pull Request #377

Since we rely on the dynamic linker to find the library for us via
dlopen(), we need to have DL_OPENGL be .so.N, not the full library
filename, as ldconfig doesn't cache the full filename

Use of TARGET_SONAME_FILE requires the library to be marked as SHARED,
not MODULE

This closes pull request #370

Using advanced output mode, the stream encoder could be updated with the
same settings, causing the encoder to output those changes
unnecessarily.

The recording settings are updated only when not using the streaming
encoder for recording.

Fix typo in README

Do not update the avermedia encoders if they are already active, they
weren't designed to be updated in real time, so it will cause encoding
to break.

If the jsonData string is null, then there's nothing that should be
written.

Closes pull request #366 from Socapex/debugcrash

win-dshow: Reorder CapsMatch for gcc

UI: Small fixes to advanced audio settings

I had this issue where IDXGISwapChain::ResizeBuffers would fail in the
hooks, causing games to crash when they resized their backbuffers
because ResizeBuffers would return an 'invalid call' HRESULT value.  In
the ResizeBuffers documentation it says that it will only happen if a
backbuffer currently has any outstanding references, but there's no way
this would happen unless ResizeBuffers internally calls Present or vise
versa.

After ResizeBuffers has been called, the very first call to Present will
somehow seemingly invalidate and/or destroy the current backbuffer.
It's very strange, but that seems to be what's going on, at least for
the game I was testing.  So if you are performing a post-overlay
capture, then you must ignore the capture on the very first call to
Present.

It's Microsoft's code so you can't really know what's going on, you just
have to work around these strange issues seemingly in the dark.

Although STDMETHODCALLTYPE is technically WINAPI (__stdcall), it's best
not to make any assumptions.

Slight clarification (I guess)

These had an older name of what the function used to be named

Fixed a bug in color conversion code for 16bit textures.

Add a check to prevent that the advanced audio settings dialog is only
once. When the dialog is already present raise it to the top instead.

Delete source controls when the settings window is deleted.

Add latest translations from crowdin

Add latest translations from crowdin

Currently, this allows the setting of values such as:
- Audio buffering time
- Color format (still somewhat unsupported)
- YUV color space (if a YUV format)
= YUV color range (if a YUV format)

More color formats will be added in the future, such as RGB and YUV
4:2:2 formats.

Certain devices may have a different color space or color range than
they may report, so allow the user to set it manually themselves if they
so wish.

Martell changed this function without realizing that this was calling a
function below it, not recursively calling itself.  The reason why he
got the warning was because there was no forward declaration of the
function that was being called; I think he's used to C where only one
function definition can exist with the same name.  In this case, it was
another function with the same name but with different parameters,
something that's permitted in C++.  I wish I had realized this sooner.

This fixes the crashes people have been having with devices.

This should (hopefully) allow URLs of the form rtmp://[abcd::1]/app

OS X doesn't like sizeof(struct sockaddr_storage) as last parameter
for connect

This reverts commit ac72e039.

This fixes the issue where the labels wouldn't have enough space for
localization text in certain circumstances, and also fixes some issues
with alignment

People were getting a bit confused over what the "Syphon" source was,
and often wouldn't use it because they didn't know what it was for.

When using multiple video encoders together with a single audio encoder,
the audio wouldn't be in sync.

The reason why this occurred is because the dts_usec variable of the
encoder packet (which is based on system time) would always be reset to
a value based upon the dts (which is not guaranteed to be based on
system time) in the apply_interleaved_packet_offset function.  This
would then in turn cause it to miscalculate the starting audio/video
offsets, which are required to calculate sync.

So instead of calling that function unnecessarily, separate the check
for whether audio/video has been received in to a new function, and only
start applying the interleaved offsets after audio and video have
actually started up and the starting offsets have been calculated.