But we should only do that if it comes straight from a
container or wavparse, not if it comes from a decoder,
otherwise it's probably not really meaningful.

It's all been ported to the latest GLib API now.

Instead of home-grown solution.

People expect audiorate to fix things up and not make things worse
by default, so let's default to a similar tolerance as audiosinks
do. Should help with transcoding and the like, though one might
possible still want higher values then.

We can't just make a vfunc that takes a union of int
and pointer as argument, and then set up subclass-specific
action signals and signals that take int (in multifdsink's
case) or a GSocket * (in multisocketsink's case), and then
expect everything to Just Work. This blows up spectacularly
on PPC G4 for some reason.

Fixes multifdsink unit test on PPC, and fixes aborts in
multisocketunit test (now hangs in gst_pad_push - progress).

This reverts part of "visual: enable commented out code again."
(commit 8222ba16).

The shader code does indeed look broken (or rather,
it makes assumptions that are not necessarily true here,
namly that pixel stride is 4, for example), which
makes totem very crashy and causes other weird behaviour.

Also see https://bugzilla.gnome.org/show_bug.cgi?id=683527

Also add a bit more debug.

See also https://bugzilla.gnome.org/show_bug.cgi?id=679443

audiotestsrc only does native endianness.

Most payloaders set/send their own output format from the setcaps
function, so if we don't get input caps, things probably wont' work
right, even if the input format is fixed (as in the case of the mpeg-ts
payloader for example).

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

Not that anyone should ascribe too much meaning to these return
values in the age of sticky caps.

Check if the buffer is DISCONT before making a potentially expensive copy to
unset the DISCONT flag.

... rather than an empty buffer