The FFmpeg-origin check can't work if it isn't provided the
dependency library.

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

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

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

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

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

But only if upstream did not provide that information.

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

Make avdec_opus work.

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

Release 3.2.0 is planned tomorrow and we should keep track of the latest
major version for 1.10 as we did in the past too.

Assignments must not have spaces around the '='

Use the default for each compiler on every platform instead. This
improves our compatibility with compilers that don't have gnu99 as
a c_std.

We expect it to be a int or uint, however it changed the type to a
int64_t in later versions of ffmpeg. As such it would be passed as a 64
bit value to varargs functions, while the consumer of the arguments
assumes only 32 bits. This causes crashes.

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

From b18d820 to f980fd9

From f49c55e to b18d820

And bump version to 1.9.2

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

https://github.com/mesonbuild/meson

We only support building with ffmpeg installed system wide and not as
subproject yet.

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

Fixes "clang: error: argument unused during compilation: '-pthread'"

Usually means no framerate / variable framerate. Also the
fraction arguments were swapped.

Otherwise it will pick it up when the system has the relevant headers,
and then linking produces an unusable plugin later as we don't ensure
that the plugin also links against the crystalhd library.

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

When switching playback modes, like from TRICKMODE or TRICKMODE_KEY_UNITS
back to regular playback, we need to make sure we set the skip mode
back to the default setting.

While this field would be properly reset when we *have* feedback from
downstream (i.e. diff != G_MAXINT64), it would not be reset during
the initial phase (i.e. when the decoder hasn't pushed a buffer yet,
and therefore the sink hasn't sent back QoS information).

This avoids dropping plenty of frames when going back to regular playback