xvimage: fix crash when outputting debug log

Can't print a GstMemory via GST_PTR_FORMAT, it will crash
inside GObject checking if it's a GObject, and we can't
check generically whether it's a derived GstMemory type,
as boxed types don't allowe derivation.
configure: use pkg-config to detect x11 and xv libs

AC_PATH_XTRA macro unnecessarily pulls in libSM and libICE.

https://bugzilla.gnome.org/show_bug.cgi?id=731047
videodecoder: In reverse playback, flush the output queue after decoding each keyframe chain

This fixes the reverse playback scenario when upstream is not fully
parsing the stream and does not send every keyframe chain separately
with the DISCONT flag on the keyframe.

To explain this, let's suppose we have this stream:
 0 1 2 3 4 5 6 7 8
 K     K     K

In most circumstances, the upstream parser will chain in the
decoder the buffers in the following order:

 6 7 8 3 4 5 0 1 2
 D     D     D

In this case, GstVideoDecoder will flush the parse queue every time
it receives discont (D) and we will eventually get in the output queue:

  (flush here) 8 7 6  (flush here) 5 4 3 (flush here) 2 1 0

In case the upstream parser doesn't do this work, though,
GstVideoDecoder will receive the whole stream at once and will flush
the parse queue afterwards:

 0 1 2 3 4 5 6 7 8
 D

During the flush, it will look backwards for keyframes and will
decode in this order:

 6 7 8 3 4 5 0 1 2

This is the same order that it would receive from upstream if
upstream was parsing and looking for the keyframes, only that now
there is no flushing of the output queue in between keyframes,
which will result in the output queue looking like this:

 2 1 0 6 5 3 8 7 6

This will confuse downstream obviously and will play incorrectly.
This patch forces the decoder to flush the output queue every time
it picks a new keyframe to decode, so it will end up decoding 6 7 8
and then flushing before picking 3 for decoding, so the output will
get 8 7 6 before 6 5 3 and the video will play back correctly.

https://bugzilla.gnome.org/show_bug.cgi?id=734441
videodecoder: Don't set decoding timestamps on raw video

https://bugzilla.gnome.org/show_bug.cgi?id=733720
decodebin: Remove buffering special casing for adaptive streaming demuxers

They output smaller buffers now and we should be able to handle the buffering
limits like in every other situation now.
encodebin: delay missing encoder error as passthrough is still possible

Set up a fakesink with a pad probe to replace the missing encoder to detect
if encoding was really required and only error out in this case. Otherwise
just let passthrough branch work.

This delays the error posting from the set_state function to when buffers
are really flowing. Unit test updated accordingly

https://bugzilla.gnome.org/show_bug.cgi?id=650652
basetextoverlay: always intersect with the filter caps

Avoids returning values that upstream can't produce

https://bugzilla.gnome.org/show_bug.cgi?id=733916
basetextoverlay: rework caps negotiation

Make textoverlay negotiate caps more correctly.

1) Check what caps we received in the video-sink
2) If it already has the overlay meta -> use it directly
3) If it doesn't, textoverlay try adding the overlay meta and using it,
   if downstream doesn't support it, just use what is received in the
   video-sink
4) Check if the allocation query also supports the meta to enable
   really using it

Before it wasn't really doing renegotiation of any kind, just
re-checking if it should use the overlay meta or not

Also had to update the caps in the test as memory:SystemMemory seems
to be required when you use a caps feature otherwise intersection/subset
checks will fail.

https://bugzilla.gnome.org/show_bug.cgi?id=733916
tests: fix decodebin signal used in icles/playback/ decodetest, test and test5

Since release 1.1.4, "new-decoded-pad" no longer exists.
videoscale: Add NV21 support

https://bugzilla.gnome.org/show_bug.cgi?id=734650
audiodecoder: Don't drain and flush on SEGMENT events.

As was done for the base video decoder in commit 695675, don't
flush out the decoder on a new SEGMENT event. Segment events
may be a new segment, but are also often segment updates for
the current segment where the old data should be kept. For new
segments, a STREAM_START event will already trigger a drain, but
make sure to flush any remaining partial data then as well.

https://bugzilla.gnome.org/show_bug.cgi?id=734666
playsinkconvertbin: Make sure to intersect raw caps with our converter caps

Otherwise we end up allowing video/x-raw with arbitrary caps features that are
not handled by our converters.

https://bugzilla.gnome.org/show_bug.cgi?id=734683
basetextoverlay: fix caps negotiation filter
decodebin: consider all deadend pads as drained

Otherwise when switching out a group with a deadend pad it will block
as it would be waiting for EOS on a deadend that already got one

https://bugzilla.gnome.org/show_bug.cgi?id=733169
decodebin: handle group switching for deadend group

Gracefully handle switching groups that all pads are deadend.

This can happen when quickly switching programs on mpegts as the
output is unaligned it can happen that not enough data was accumulated at
parsers to generate any buffers, causing the stream to receive EOS before
any data can be decoded.

To handle this scenario, the _expose function now also gets if there is
any next group to be exposed along with the list of endpads. If there are
no endpads and there is another group to expose it will switch to this next
group and then retry exposing the streams.

Also, the requirement to only switch from the chain that has the endpad had
to be modified to care for when the drainpad is NULL

https://bugzilla.gnome.org/show_bug.cgi?id=733169
videodecoder: Reset last_timestamp_out on new segment

Reset last_timestamp_out when applying the output segment
change, to avoid decoder confusion over new timestamp timelines when
a seamless segment change happens.

Move some locks/unlocks to later when they're actually needed.

https://bugzilla.gnome.org/show_bug.cgi?id=734617
video: Various simple docs fixes
video: Add gst_video_guess_framerate() function

Takes a nominal frame duration and returns a standard
FPS if it matches closely enough (< 0.1%), or else
calculates a framerate that'll do.
gstvideo: add missing entry to win32 .def

gst_video_guess_framerate
discoverer: Set 'processing = FALSE' when done discovering SYNC

This avoids a race where we would get new tag but we are already
prerolled and analyzing results.

It is the way it is supposed to be handled as stated in comment:
"If preroll is complete, drop these tags - the collected information is
possibly already being processed and adding more tags would be racy"