https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Matej Knopp <matej.knopp@gmail.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.
_stdint.h is generated by Autotools and we don't really need it. All
supported platforms now ship with stdint.h. The only stickler was MSVC,
and since Visual Studio 2015 it also ships stdint.h now.
It now returns the correct values for both orthographic and perspective
projections and takes into account the aspect ratio of the video, handles
the Y-flipping in GL and by us and uses some more helpers from graphene.
Multiple threads may be accessing the wayland fd at the same time which
requires the use of special wayland API to deal with to ensure nobody
will steal reads and cause a stall for anyone else.
Fixes spurious segfault in unit test, where the task was started again during
shutdown when all pads were removed... and was then still running while the
element was finalized.
Uncompressed RGB frames can be (usually are) bottom-up
layout in DirectShow, and the code to flip them wasn't
properly ported from 0.10. Fix it.
Fix post-processing of RGB buffers. We need a writable
buffer, but the requests pool is holding an extra ref.
This could use more fixing to use a buffer pool
It uses random data streams but dashdemux nowadays actually looks into the
streams and doesn't like randomness very much. The tests should probably just
become validate tests on real streams.
https://bugzilla.gnome.org/show_bug.cgi?id=769553
We don't have to do yet another additional request but can just download the
data directly.
Also unify the key-unit only mode buffer pushing and extract it into its own
function now that it became more complicated.
https://bugzilla.gnome.org/show_bug.cgi?id=741104
This allows to gradually download part of a fragment when the final size is
not known and only a part of it should be downloaded. For example when only
the moof should be parsed and/or a single keyframe should be downloaded.
https://bugzilla.gnome.org/show_bug.cgi?id=741104
We need to mark every first buffer of a key unit as discont, and also every
first buffer of a moov and moof. This ensures that qtdemux takes note of our
buffer offsets for each of those buffers instead of keeping track of them
itself from the first buffer. We need offsets to be consistent between moof
and mdat
https://bugzilla.gnome.org/show_bug.cgi?id=741104
