Add the channel masks for all the extensible formats
Pass the number of channels instead of reading them from caps.

fixes #690591

We need to mark our clock as using some other clock source. Alsa source uses the
clock type to decide if it can use alsa driver timestamps or not.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=690465

We need to initialize this variable because we can't be sure that the subclass
will set it.

comparison is always true due to limited range of data type

Otherwise baseaudiosrc won't go into the error code path.

https://bugzilla.gnome.org/show_bug.cgi?id=690197

Use new ringbuffer ERROR state to make all the various
threads bail out correctly when the subclass posts an
error. It's a bit iffy to communicate this properly
between the different bits of code.

https://bugzilla.gnome.org/show_bug.cgi?id=690197

API: GST_AUDIO_RING_BUFFER_STATE_ERROR

https://bugzilla.gnome.org/show_bug.cgi?id=690197

The naming is not perfect, but at least we can keep the exact same behaviour as
before.

In SKEW mode, use next_sample == -1 to check for the first sample
when starting to read samples so it resyncs the ringbuffer and
timestamps are ok.

Suggestion from Teemu Katajisto <teemu.katajisto@digia.com>

https://bugzilla.gnome.org/show_bug.cgi?id=648359

The codec data blob we get from matroskademux with the SSA/ASS
init section is supposed to be valid UTF-8. If it's not, just
continue with the bits that are valid UTF-8 instead of erroring
out. We don't actually parse the init section yet anyway..

https://bugzilla.gnome.org/show_bug.cgi?id=607630

https://bugzilla.gnome.org/show_bug.cgi?id=625113

Don't loop forever if an USB audio device gets disconnected
while in use. Post an error message instead. This is not
enough yet though, we still need to make the base class
and/or the ring buffer bail out.

https://bugzilla.gnome.org/show_bug.cgi?id=690197

For later use.

https://bugzilla.gnome.org/show_bug.cgi?id=636753
https://bugzilla.gnome.org/show_bug.cgi?id=549111

Add a limit to the amount of queued bytes or messages we allow on the watch.

API: GstRTSPConnection::gst_rtsp_watch_set_send_backlog()
API: GstRTSPConnection::gst_rtsp_watch_get_send_backlog()

Block the pad before the resample and convertor elements to give the a chance to
negotiate new caps with the newly switched vis plugin.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=679976

https://bugzilla.gnome.org/show_bug.cgi?id=688785

https://bugzilla.gnome.org/show_bug.cgi?id=689740

Otherwise we just pass through the timestamps directly and don't
need to waste additional memory for them.

Fixes bug #689814.

https://bugzilla.gnome.org/show_bug.cgi?id=689873

The behaviour is sensibly changed here. Instead of purely falling when a
preset is set on the #GstEncodingProfile, we now make sure that the
element that is plugged corresponds to the one specified as preset. Then,
if we have a preset_name, we use it, if it fails, we fail (we might rather
just keep working even without setting the element properties?)

 + Add tests that it behave correctly

It was possible to decide only what #GstElement implementing #GstPreset
to use during the encoding, we can now let the user select a specific preset previously
saved using #gst_preset_save_preset specifying the name chosen when it was saved
in the gst_encoding_profile_set_preset_name.

Actually loading a preset with %NULL as a name would have always failed, so
in the current state of the API that feature is unusable

API:
  gst_encoding_profile_set_preset_name
  gst_encoding_profile_get_preset_name

Makes the parameter accept NULL as input for GI bindings

And mention this in docs.

https://bugzilla.gnome.org/show_bug.cgi?id=689326

Make sure appsink works multiple times in a row.
Disable it though for now though.

https://bugzilla.gnome.org/show_bug.cgi?id=644989

In order for 1.x and 1.(x+1) versions to not invade on each other
we need to have different lib versions.

So we need a consistent and predictable scheme:
   library version number = MINOR * 100 + MICRO

Ex:
  1.0.0 => 0 (duh)
  1.0.3 => 3
  1.1.0 => 100
  1.1.1 => 101
  1.2.0 => 120
  1.10.5 => 1005

When the input buffers for a stream don't have a duration set,
timestamp_end might still be GST_CLOCK_TIME_NONE. When advancing
EOSed streams via GAP events (with other streams not yet EOS), we
would then use the invalid timestamp_end to calculate the duration
of the gap. This in turn would make baseaudiosink abort, because it
would try to allocate memory for a trizillion samples.

So if buffers don't have a duration set, assume a duration of
one second for stream catch-up purposes, just so we can still
continue to catch up in those cases. And make sure that
timestamp_end is valid before doing calculations with it.

http://bugzilla.gnome.org/show_bug.cgi?id=678530