flv: Tag timestamp are DTS not PTS

The tags in FLV are DTS. In audio cases, and for many video format this makes
no difference, but for AVC with B-Frames, PTS need to be computed from
composition timestamp CTS, with PTS = DTS + CTS.

https://bugzilla.gnome.org/show_bug.cgi?id=731352
flvmux: Ensure Timestamp starts at 0

FLV documentation stipulates that timestamp must start at zero.
In order to respect this rule, keep the first timestamp around
and offset the timestamp from this value. This allow for longer
recording time in presence of timestamp that does not start
at 0 already.

https://bugzilla.gnome.org/show_bug.cgi?id=731352
flvmux: Save dts from buffer

We no longer set dts in muxed buffer. This would lead to encoding tags
with timestamp 0 instead of the timestamp of previous buffer.

https://bugzilla.gnome.org/show_bug.cgi?id=731352
flvmux: Correctly offset timestamp

The previous method would break AV sync in the case audio or video
didn't start at the same point in running time.

https://bugzilla.gnome.org/show_bug.cgi?id=731352
gdkpixbufdec: EOS and NOT_LINKED are no errors in general

Don't post an error message for them but let upstream handle
anything accordingly.

https://bugzilla.gnome.org/show_bug.cgi?id=735564
imagefreeze: Remove impossible error condition

We return EOS after the first buffer, and GstPad will make sure now that we
won't get any other buffer afterwards until a flush happens. No need to check
for it ourselves.

https://bugzilla.gnome.org/show_bug.cgi?id=735581
flvmux: Fallback to PTS if DTS is missing

Fixing a regression introduce when fixing:
https://bugzilla.gnome.org/show_bug.cgi?id=731352
multipartdemux: Ensure caps before pad added.

This stores the stream-start, sets caps, and then adds the pad,
which ensures that the caps are set for the "pad-added" callback.

https://bugzilla.gnome.org/show_bug.cgi?id=735626
wavparse: support rf64 format

https://bugzilla.gnome.org/show_bug.cgi?id=735627
wavparse: Use 64 bit scaling functions now that fact is a 64 bit integer
wavparse: Store size of data tag in a 64 bit integer locally too

Otherwise we will clip the DS64 value of RF64 files to 32 bits again.
v4l2: get_nearest_size: Always reinit all struct fields on retry

They may have been modified by the ioctl even if it failed. This also makes
the S_FMT fallback path try progressive first, making it consistent with the
preferred TRY_FMT path.

https://bugzilla.gnome.org/show_bug.cgi?id=735660
v4l2: get_nearest_size: Fix "Unsupported field type" errors

Most V4L2 ioctls like try_fmt will adjust input fields to match what the
hardware can do rather then returning -EINVAL. As is docmented here:
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-fmt.html

EINVAL is only returned if the buffer type field is invalid or not supported.

So upon requesting V4L2_FIELD_NONE devices which can only do interlaced
mode will change the field value to e.g. V4L2_FIELD_BOTTOM as only returning
half the lines is the closest they can do to progressive modes.

In essence this means that we've failed to get a (usable) progessive mode
and should fall back to interlaced mode.

This commit adds a check for having gotten a usable field value after the first
try_fmt, to force fallback to interlaced mode even if the try_fmt succeeded,
thereby fixing get_nearest_size failing on these devices.

https://bugzilla.gnome.org/show_bug.cgi?id=735660
imagefreeze: Don't call gst_caps_unref() on template caps when already unreferenced

Adding an extra condition while calling gst_caps_unref (templ)
and replacing gst_caps_make_writable (gst_caps_ref (caps)) with
gst_caps_copy (caps) in line 177, since the functionality is same.

https://bugzilla.gnome.org/show_bug.cgi?id=735795
vp8dec: Reset output and input states when changing format

https://bugzilla.gnome.org/show_bug.cgi?id=734266
tests: vp8dec: add test for caps renegotiation

Check that vp8dec can properly accept a new caps when upstream
changes it

https://bugzilla.gnome.org/show_bug.cgi?id=734266
vp9dec: Fix segfault when a new caps is received

Remember to unref the output caps when a new caps event is received
as it should generate a new one based on the new caps.

https://bugzilla.gnome.org/show_bug.cgi?id=734266
vp8dec: Fix for handling resolution changes when decoding VP8

If the resolution changes in the bitstream without the input caps changing we
would previously output corrupted video or crash.

https://bugzilla.gnome.org/show_bug.cgi?id=719359
vp9dec: Get input width/height from the codec instead of the input caps

They are reported properly by libvpx if the correct struct members are used.
This also fixes handling of resolution changes without input caps changes.

https://bugzilla.gnome.org/show_bug.cgi?id=719359
aacparse: Fix parsing issue when the buffer does not have a complete ADTS/LOAS frame

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