https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
WAV is too generic to impose more-or-less arbitrary boundaries on the
sample rate and channel count caps. For example, there are 384 kHz WAV
files. Another example: it is in theory possible that somebody puts DSD
data into a WAV file, which will then have a sample rate of ~2.8 MHz.
For this reason, get rid of the rate and channel caps unless they are
fixed values. Downstream anyway usually knows the limitations better.
https://bugzilla.gnome.org/show_bug.cgi?id=761514
The API does not follow the type naming convention. Re-enable
only if one take the time to box and rename (see (rename-to SYMBOL)
annotation) all types.
Windows Media Video Screen (WMV Screen) are video formats that
specilise in screencast content. This provides a correct media type
for them instead of just video/x-asf-unknown.
Xsub (fourcc DXSB) is a subpicture stream used for embeded
subtitles on divx files. This provides a correct media type
for them instead of just video/x-avi-unknown.
Some ADPCM encoding tools like Oxelon generate WAV files with
wrong format header declaring an invalid bitrate.
As wavparse uses the average bitrate to calculate timestamps
and duration the decoder can be confused by receiving timestamps
completely out of sync with the decoded samples.
ADPCM is a CBR audio codec so we can calculate the average bitrate
instead of trusting the format header.
https://bugzilla.gnome.org/show_bug.cgi?id=636245
The _1_0 suffixed environment variables override the
non-suffixed ones, so if we're in an environment that
sets the _1_0 suffixed ones, such as jhbuild, we need
to set those to make sure ours actually always get
used.
This reverts commit e39fbe6b7e.
Looks like we need to pass the full .la file after all in a setup
with libtool, or it might not find the library, e.g. like
ERROR: can't resolve libraries to shared libraries: gstfft-1.0
Conflicts:
gst-libs/gst/audio/Makefile.am
gst-libs/gst/pbutils/Makefile.am
Also see https://bugzilla.gnome.org/show_bug.cgi?id=603710
