tests: videodecoder: add simple playback test

Add a simple playback test that makes sure that video decoder pushes
buffers in the same order it receives and that it respects the
set timestamps and durations
tests: videodecoder: add check for serialization of events

Tests that events are properly serialized with buffers, also checks
that the usual events are sent (stream start, caps, segment and eos).
videodecoder: use new segment earlier for reverse playback

For reverse playback, the segment event will only be pushed when
the first buffer is actually pushed. But for decoding frames and storing
those into the list to be pushed the output_segment.rate value is used
to determine if it is forward or reverse playback.

In case a previous segment event (or none) is in use it will mistakenly
think it is doing forward playback and push the buffers immediatelly and
try to clip buffers based on an old segment (or an uninitialized one, leading
to an assertion)

This patch fixes this by copying the segment earlier if on reverse playback

https://bugzilla.gnome.org/show_bug.cgi?id=721666
tests: videodecoder: add test for reverse playback

Checks that buffers are pushed backwards in reverse playback

https://bugzilla.gnome.org/show_bug.cgi?id=721666
videodecoder: do not lose events when dropping frames

Events must be persisted after a frame is dropped to avoid
losing obligatory information for the stream.

https://bugzilla.gnome.org/show_bug.cgi?id=721835
tests: videodecoder: check that segment events are not dropped

Adds a test that simulates a scenario where the first buffers after
a segment can't be decoded and the decoder asks for those frames
to be released. The videodecoder base class should make sure that
the events attached to those first buffers are pushed even if the
buffers aren't going to be.

https://bugzilla.gnome.org/show_bug.cgi?id=721835
textoverlay: don't leak GAP events
oggdemux: use an adaptive chunksize for performance reasons

Ogg data is read chunk by chunk, and the chunk size used was
originally taken from libvorbisfile. However, this value leads
to poor performance when used on an Ogg file with large pages
(Ogg pages can be close to 64 KB).

We can't just use a larger chunk size, since this will decrease
performance on small page streams, so we use an adaptive scheme
where the chunk size is twice the largest page size we've seen
so far in the stream. For "typical" Ogg/Vorbis, this gives us
almost the same chunk size (a bit lower), and this lets us get
better performance on streams with large pages.
oggdemux: fix broken seeking reading the whole file

A change in gst_ogg_demux_do_seek caused oggdemux to wait for
a page for each of the streams, including a skeleton stream if
one was present. Since Skeleton only has header pages, that
was never going to end well.

Also, the code was skipping CMML streams when looking for pages,
so would also have broken on CMML streams.

Thus, we change the code to disregard Skeleton streams, as well
as discontinuous streams (such as CMML and Kate). While it may
be desirable to consider Kate streams too (in order to avoid
losing a subtitle starting near the seek point), this may be
a performance drag when seeking where no subtitles are. Maybe
one could add a "give up" threshold for such discontinuous
streams, so we'd get any page if there is one, but do not end
up reading preposterous amounts of data otherwise.

In any case, it is important that the code that determines
the amount of streams to look pages for remains consistent with
the "early out" conditions of the code that actually parses
the incoming pages, lest we never decrease the pending counter
to zero.

This fixes seeking on a file with a skeleton track reading all
the file on each seek.

https://bugzilla.gnome.org/show_bug.cgi?id=719615
tests: audiodecoder: add basic playback test for audio decoder

Simple test that just check that audio decoding works as expected

https://bugzilla.gnome.org/show_bug.cgi?id=722144
tests: audiodecoder: check that negotiation works buffers and gaps

Adds 2 tests to verify that output caps are the expected value, reusing
input structure values for both buffers and gaps

https://bugzilla.gnome.org/show_bug.cgi?id=722144
audiodecoder: make sure caps is set before forwarding gap event

Before trying to generate a default fixated caps when handling a gap
event, make sure that the same strategy that is used when handling
a buffer has been attempted. Otherwise audiodecoder will ignore
upstream caps settings such as rate and channels and will likely
end with a caps with channels=1 and rate=1.

https://bugzilla.gnome.org/show_bug.cgi?id=722144
audiodecoder: avoid parsing caps event if it is not used

Saves some cpu
xvimagesink: don't recreate xvcontext

A xvcontext can be created early in gst_xvimagesink_set_window_handle().
In this case don't recreate, i.e. overwrite it in gst_xvimagesink_open().
Otherwise XEvents won't be handled in the xevent listener thread.

Fixes a regression when setting the window handle on the sink in
the very beginning before changing its state.

https://bugzilla.gnome.org/show_bug.cgi?id=715138
audiodecoder: copy rate and channels from input before fixating output caps

For default caps generation when handling gap events that are sent
before any buffer, try to use caps that are closer to what upstream
provided to avoid fixating rate or channels to 1 as default.

So there are the steps:
1) Try to set rate, channels and channel-mask from upstream if provided
2) Fixate the rate and channels to the default rate and channels from
   audio lib
3) Fixate the caps just to be sure everything is fixed
4) If no channel-mask was provided and channels > 2, use a default
   channel-mask (taken from audioconvert code)

https://bugzilla.gnome.org/show_bug.cgi?id=722144
tests: audiodecoder: add another test for negotiation with gap event

Check that even if the subclass doesn't call set_output_format, the base
class should use upstream provided caps to fill the output caps that is
pushed before the gap event is forwarded, otherwise it ends again fixating
the rate and channels to 1.

https://bugzilla.gnome.org/show_bug.cgi?id=722144
videodecoder: plug leak when frames are released on subclass stop

They end up stored in the 'pending_events' list and should be
freed after calling stop