This reverts commit b5a3d603.

Reverting this for now, since no one really seems to remember why this
property exists or what it could possibly be good for. It seems to have
been in the original mp3parse since the beginning of time and was back-
ported from there.

We lose the reference to the buffer after gst_pad_push(), so the debug
print should happen before.

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

... in pull mode or upstream driven.

... provided a corresponding decoder with sufficient leading and following
frames to carry out full decoding for a particular segment.

... as it logically belongs there as one or the other; either subclass
can provide a duration, or an estimate must be made (reguarly updated).

That is, loop pause handling, segment seek support, newsegment for gaps, etc

Seekability, like duration, etc is unlikely to change (frequently), and
the default assumption covers most cases, so let subclass set when needed.
At the same time, allow subclass to indicate if it has seek-metadata (table)
available, and possibly have it provide an average bitrate.

... and allow subclass to perform custom segment clipping, or to
emit tags or messages at this time.

This allows the child class to chain its event handler with
GstBaseParse, so that subclasses don't have to duplicate all the default
event handling logic.

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

Also don't post an error message for UNEXPECTED and do it
for NOT_LINKED.

Allow a few more seek event type combinations, and really use the result
of gst_segment_set_seek to perform the seek.  Also add some debug.

We wait to parse a minimum number of frames (10, arbitrarily) before
emiting bitrate tags so that our early estimates are not wildly
inaccurate for streams that start with a silence. If the stream ends
before that, we just emit the tags anyway.

While it _would_ be nicer to be specify the threshold to start pushing
the tags in terms of duration, this would introduce more complexity than
this merits.

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

...instead of not setting it at all.

Instead of taking the last stop (which could be buffer endtime instead
of starttime) always take the buffer starttime.

Fixes bug #614016.

This makes baseparse keep a running average of the stream bitrate, as
well as the minimum and maximum bitrates. Subclasses can override a
vfunc to make sure that per-frame overhead from the container is not
accounted for in the bitrate calculation.

We take care not to override the bitrate, minimum-bitrate, and
maximum-bitrate tags if they have been posted upstream. We also
rate-limit the emission of bitrate so that it is only triggered by a
change of >10 kbps.