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.
Request pads are requested by applications and as such should only be released
by them again. Instead of releasing them when stopping the muxer, just clear
their state so that they can be used again when starting the muxer again.
https://bugzilla.gnome.org/show_bug.cgi?id=763862
This works usually in this place, unless the compiler optimizes things in
interesting ways in which case it causes stack corruption and crashes later.
The compiler in question here is clang with -O1, which seems to pack the stack
a bit more and causes writing to the guint as pointer to overwrite map.memory,
which then later crashes during unmapping of the memory.
rename gst-launch --> gst-launch-1.0
replace old elements with new elements(ffmpegcolorspace -> videoconvert, ffenc_** -> avenc_**)
fix caps in examples
https://bugzilla.gnome.org/show_bug.cgi?id=759432
The edit rate is only supposed to be the same in a source package, but there
might be multiple source packages with the same essence container. As such
just comparing the body/index SID is not sufficient.
This was completely broken before and could only work on a very constrained
set of files. After these changes it should work except for situations where
PTS != DTS, which is not handled at all in mxfdemux currently.
https://bugzilla.gnome.org/show_bug.cgi?id=759118
According to S377-1-2009c 9.2 the local tags must not be resolved from the
primer pack, which as a result means that there can't be any other tags than
statically assigned ones.
0x04 signifies a MPEG elementary stream but according to RP2008, 0x10 should
be used for a h264 byte-stream. This also fixes compatibility of our files
with ffmpeg.