x264 has to be compiled specifically for a target bit depth.
Distributions currently ship various libraries in their packages, with
different bit depths.
This change now allows to provide them all at configure time and have
the x264enc element dynamically switch between them based on the bit
depth of the input format.
https://bugzilla.gnome.org/show_bug.cgi?id=763297
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.
_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.
Don't artificially limit the bitrate, x264enc allows much
higher bitrates, and for intra-only 4k AVC they are needed.
x264 clips to 2Gbps internally, so use that as limit for now.
https://bugzilla.gnome.org/show_bug.cgi?id=758620
This method replace the manual adjustment of PTS and DTS to avoid
negative DTS issues. Using this method will also update the segment so
we don't loos sync.
https://bugzilla.gnome.org/show_bug.cgi?id=740575
Provide new frame-packing property to directly set
x264enc frame packing, or pass through upstream settings
The explicit layout from the frame-packing property is
preferred over any info from the caps.
The meaning of the max latency is *not* the maximum latency this element will
introduce. It is the maximum latency this element can endure without
overflowing any buffers, which is infinite for x264enc.
Fixes latency configuration in zero latency mode, where max latency was
becoming 0... which usually won't work well if something else introduces
latency as then max < min in the end, and latency configuration just fails.
There is no reason x264enc should enforce a maximum allocation size.
The maximum is normally set by buffer pool which cannot grow, but we
don't offer a buffer pool. This would lead to stall when used with
element that don't implement allocation query.
Related to: https://bugzilla.gnome.org/show_bug.cgi?id=738302
Currently we only shift DTS to compensate that we don't support negative
timestamp. This cause a problem that PTS is no longer >= DTS and may
make muxers live much harder. Instead, shift both PTS/DTS forward. Also
remove all the hack to handle this which seems the result of thinking libx264
is bugged.
https://bugzilla.gnome.org/show_bug.cgi?id=731351
We were assigning to a guint64 value (frame->dts) the sum of a unsigned
and signed value... resulting it the result never being < 0.
Instead just check if it is smaller before assigning to frame->dts.
and decide at runtime which subset of these (8-bit or 10-bit video
formats) is supported. libx264 will be compiled for one of these
two options, and it is possible to switch by pointing the dynamic
linker to a different libx264 build at runtime. If we want our
template caps to be correct, they should contain all then, with
the actually supported ones determined at runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=691935
Min. latency needs to be a valid time, so pass 0 as default
value in the fallback case where we can't determine any latency,
and avoid nasty criticals at runtime.
