To increase performance remove tsparse element.

To increase performance of the timeshifter remove tsparse element
from the bin after it's no longer needed.

tsparse is only needed to obtain PID of the stream we're interested in.
Once this is done we don't need to parse the stream. By removing
tsparse it's possible to lower the CPU usage by a few percent
(relative to the other elements in the tsshifterbin).

To make removal of element in a live pipeline possible, a fix had to
be applied in tsshifter, because it was dropping caps event which
was upsetting upstream elements (non-negotiated error).
Fix incorrect error case handling

gst_element_clear is not correctly clearing elements when
error case is hit in gst_ts_shifter_bin_init.
Fix if glib is built in debug=none mode
Timeshifter: Avoid trashing caches and degrading performance

The timeshifter writes incoming mpeg-ts data to disk and reads it back
out again.  This involves a lot of disk I/O which goes via the linux
kernel page-cache.

The kernel caches pages in memory as it usually improves performance.
Unfortunately, due to limited resources, the kernel must drop some pages
from the cache to let others in.  If the kernel gets it wrong it may
evict some pages which are required in favour of pages which are not
likely to be used again.  We have seen this cause performance degredation
when an channel is tuned to for a long time.  This is because some of the
code pages required for other uses have been evicted from cache and must
be read again from disk.

This change modifies the timeshifter to give the kernel more information
about the expected use of the pages it uses.  There are two hints given:

1. When a timeshifter slot is filled with mpeg-ts data the timeshifter
   will now tell the kernel to start writing it to disk such that the
   page will become "clean" rather than "dirty".
2. After giving the kernel some time to asynchronously write it to disk
   the writer will ensure that it has been written (blocking if
   necessary) and instruct the kernel to drop the page from cache.
3. We also drop the page if it has been read as it it unlikely to be read
   again.

You can measure which pages are resident in memory with linux-ftools[1].
With this it's easy to see the difference in the number of pages of the
timeshift-buffer are resident in memory.

With this patch there is no performance degredation when as the
timeshifter is used.

[1]: http://code.google.com/p/linux-ftools/
Fix a problem when a PCR would wrap causing the timeshifter to fail

PCR or Program Clock Reference is a 90Khz clock that is embedded into
mpegts packets. Timeshifter uses this clock to bind stored buffers
and they time of arrival for future reference. One of the properties
of PCR clock is that it is stored as a 33 bit value hence it will wrap
every ~26.5 hours. Timeshifter would previously fail in such a case
because stream time was directly derived from the arriving PCR and if
discontinuity would be encountered timeshifter would fail to properly
account arriving buffers. Also buffer level would be incorrectly flagged.

This change amends that by not using PCRs as direct time reference.
Implement an element that will aid in PCR wraping tests.

Timeshifter has to be robust against PCR wraps. This element
can manipulate PCRs of the mpegts stream such that it is easy to produce
a situation where such a wrap occurs.

This is only meant to be used in tests for timeshifter element.
This is because one of the limitations of tsstamper is the fact
that only restamps PCRs and *NOT* PTSs, DTSs, SCRs etc.
This will effect in a stream that is confusing for the decoder.
For this reason it is only useful in tests of timeshifter where
we don't do any decoding.
Fix unintended buffer cap caused by erroneous u64 to u32 cast

An error in gst_ts_cache_new signature meant that timeshift buffer size
was casted from 64 to 32-bit. This is preventing timeshift buffer going
above 4GB limit and as unintended has now been fixed.
Reduce memory usage when using large backing files

For easy tracking of what data has been written where the timeshifter
divides its backing file store into slots, each 32kB in size.  It keeps
accounting information in memory for each one of these slots in RAM as
a `struct Slot`.  This in turn contains a pointer to a GstBuffer which
corresponds to that slot.

Unfortunately this means that timeshifter memory usage scales linearly
with backing store size.  For realistic sizes of the backing store for
storing 2 hours of HD video (~10GB) this memory overhead can be on the
order of ~100MB.  This is too much.

This commit fixes this issue by reducing this per slot overhead by not
storing a `GstBuffer` for each slot.  Instead `GstBuffer`s are created
on demand on the read side and not used at all on the write side.  This
has necessatated a change in abstraction.  Previously the timeshifter
wasn't even directly aware that it was backed by a file[1].  A Gstreamer
`GstAllocator` was injected into it which in this case was a
`GstFileMemAllocator`, requiring a patch adding this to the gstreamer
sources.

Instead now a file descriptor is injected into the timeshifter for use
as a timeshift buffer.  This provides a different kind of flexibility
to the model of injecting a `GstAllocator`.  This patch also means that
there is no longer a dependency on `GstFileMemAllocator` at all so the
timeshifter can be built against pristine Gstreamer.

With this patch memory usage still scales linearly with backing store
size, just less severely.  Future work could involve removing `struct
Slot` entirely to reduce memory usage further.

[1]: This is not strictly true.  The introduction of the efforts to avoid
     cache trashing actually made timeshifter directly dependant on the
     fact that the `GstFileMemAllocator` was used to allocate these
     buffers.
Fix refcounting error

A refcounting error, causing a significant memory leak has been fixed.
It error was caused by gsttsseeker and gsttsindexer set_property function
calling g_value_dup_object which increases the refcount. This was sufficient
to preserve the ownership, but the erronous code was increasing the refcount
once more. This has been corrected and it appears that memindex is properly
cleaned up.