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.
mad expects extra bytes at the end of a buffer (see discussion in
http://www.mars.org/mailman/public/mad-dev/2001-May/000262.html),
and since we inject these without the base class' knowledge, we
need to hide the bodies better.
This fixes an assert at EOS when decoding an mp3 manually without
an intervening mpegaudioparse.
If http://www.mars.org/mailman/public/mad-dev/2001-May/000262.html is
to be believed, the last buffer must be followed by a number of 0 bytes
in order for the last frame to be decoded (at least in some cases).
Doing so seems to work here, fixing a missing 1152 samples when using
mp3parse before mad (not using mp3parse would yield the correct amount
of samples, if there's extra non-MP3 data after (eg, tag data)).
This time using the base class. Still something
wrong with the parsing though, when there's no
parser or demuxer upstream (which of course
shouldn't happen in a normal playback scenario).
Taken from commit 6e7e3657396454fe95fbd89170281865d4d1cec3
of Mark's baseaudio branch.
Would probably be too risky to drop this into 0.10 given
all the things mad is doing.
The mad mp3 decoder element shouldn't parse tags at all really, but we
have so far kept this code around for backwards-compatibility reasons
for people building manual pipelines for some reason. However, as it
turns out that code has never actually worked in 0.10 in practice,
since it only gets executed if mad_frame_decode() returns LOSTSYNC,
which doesn't actually seem to happen any more though because of the
preceding mad_header_decode(), which will discover and report the
sync loss if it runs into a tag and make mad_frame_decode() try to
resync right away.
Discovered this while trying to make it use gst_tag_list_from_id3v2_tag().
