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.
This reverts commit 4065fcb80a.
flacparse should not push tags by itself, the base class is going to do that
while properly merging in upstream tags. It just didn't because of a bug in
the base class, which was hidden by this commit.
https://bugzilla.gnome.org/show_bug.cgi?id=763553
SBC frame length calculation wasn't being rounded up to the nearest byte
(as specified in the A2DP 1.0 specification, section 12.9). This could
cause 'stereo' and 'joint stereo' mode SBC streams to have incorrectly
calculated frame lengths.
Incorrect frame length calculation causes frame coalescing to fail, as
subsequent frames in the stream aren't found in the expected locations.
https://bugzilla.gnome.org/show_bug.cgi?id=742446
For someone that read the spec is clear the only *invalid*
data block type is 127. For the rest, its useful information.
Additionally. values 7-126 are currently reserved by the
spec so the situation might change in the future.
We are only interested on the first bit of the first
byte of the metadata block header to figure out whether
is marked as the last one. The shift makes it quite
clearer.
If we get anything from 7 to 126 as type when parsing
a metadata block header, we are likely dealing with a
FLAC stream version we don't fully understand. Issue
a warning if so.
Document function assumptions regarding the passed-on
type while at this.
As CRCs are calculated for the comparition already, we
might as well (cheaply) inform the user how the numbers
differ if a missmatched pair is found.
While at it:
Rephrase candidate-frame message to make more sense
There might be multiple LOAS config in a row in a full frame. The first
one might be a multi-layer config (which we can't properly parse yet)...
but then followed by a valid (single-layer) one.
The code was previously skipping whole frames (instead of just the LOAS
config we failed to read) resulting in multiple frames (seen up to 6s in
some situation) being dropped before finally getting the configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=758826
On reading LOAS config, flag v=1 and vA=1 combination can occur, leading to warning
"Spec says "TBD"...". Returning TRUE on this case while parameters 'sample_rate' and
'channels' are pointing to uninitialized values can end on setting random values as
rate and channels on src caps.
https://bugzilla.gnome.org/show_bug.cgi?id=755611
It's normal when dropping into the middle of a stream to
not always have the config available immediately, so skip LOAS
until a valid config is seen without either setting invalid
caps or erroring out.
https://bugzilla.gnome.org/show_bug.cgi?id=751386
flac contains the sample offset in the frame header, so after a seek
without index flacparse will know the exact position we landed on and
timestamp buffers accordingly. It only set the pts though, which means
the baseparse-set dts which was set to the seek position prevails, and
since the seek was based on an estimate, there's likely a discrepancy
between where we wanted to land and where we did land, so from here on
that dts/pts difference will be maintained, with dts possibly multiple
seconds ahead of pts, which is just wrong. The easiest way to fix this
is to just set both pts and dts based on the sample offset, but perhaps
parsed audio should just not have dts set at all.
https://bugzilla.gnome.org/show_bug.cgi?id=752106
