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.
libmpeg2 0.5.1 was released in mid-2008, let's bump the requirement
and get rid of version-dependent code paths. There's still
avdec_mpeg2video for those who are stuck on ancient distros which
we don't target any more.
Also fixes build with MSVC, which doesn't like #if #else #endif
inside macro arguments (like the GST_DEBUG_OBJECT in line 941).
This allow using external pools that have different strides from the
default. These strides need to respect certain rules, which we check
and if these are not met, we fallback to generic pool.
https://bugzilla.gnome.org/show_bug.cgi?id=735379
This is a rewrite of the pool negotiation and configuration. Direct
to output decoding is now achieved by configuring the pool using
video-alignment. This removes copies when dealing with any elements that
supports VideoAlignment, and enable usage of generic video buffer pool,
XVImagePool and GLPool. It drops the crop meta implementation for now.
https://bugzilla.gnome.org/show_bug.cgi?id=735379
A pipeline like:
gst-launch-1.0 filesrc location=file.ts ! tsdemux ! mpegvideoparse ! mpeg2dec ! vaapisink
would look bad when file.ts contains 704x576 video, because vaapisink would
give you buffers of stride 768, but libmpeg2 was not told about this and
used a stride of 704.
Tell libmpeg2 about the stride from downstream; in the process, teach it to
reject buffer pools that don't meet libmpeg2's chroma stride requirements
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
New changes to gstvideo will reset all the video info state
when calling _set_format, overwriting what was previously set
in the preceding code.
The comment says the following code is meant to preserve the
pre-crop size, so let's just keep the size and related data
as this does not seem to break anything else (this is what
the _set_format call would have set before the change that
reset all data, except the colorimetry).
If the sequence is not flagged as progressive its buffers are marked
interlace mode mixed. There is an individual picture flag indicating
whether picture in the sequence are interlaced or not. This is used
along with the new GST_VIDEO_BUFFER_FLAG_INTERLACED to correctly and
completely indicate the buffer's interlaced state.
Also, TFF and RFF should only be set if the sequence is not progressive.
When mpeg2dec needs to do cropping (because downstream can't handle it),
we need temporary buffers to decode to.
Use the user_data field to store those, and unify the rest of the code
that needs to touch a buffer (regardless of how/where it was allocated).
https://bugzilla.gnome.org/show_bug.cgi?id=680194
