We have better replacements such as the mpg123 plugin.
The main reason to keep around mad was for 'freeform'
mp3 support, but mpg123 can handle those too nowadays.
Also, mad is GPL and has been unmaintained for years.
https://bugzilla.gnome.org/show_bug.cgi?id=776140
If the caps are interlaced, interlacing is always enabled on the
encoder. If the interlace-mode field is missing or if it's progressive,
the encoder uses the "interlaced" property.
https://bugzilla.gnome.org/show_bug.cgi?id=775228
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.
Avoid compiler warnings "‘foo’ may be used uninitialized in this
function" when building with -O3 by checking the return bool value
of format conversion function.
https://bugzilla.gnome.org/show_bug.cgi?id=769116
Fix syntax errors when compiling against cerbero-provided libmpg123
headers. We do the same as the libmpg123 internal visual studio
build here.
mpg123.h(1378): error C2143: syntax error: missing ')' before '('
mpg123.h(1378): error C2081: 'ssize_t': name in formal parameter list illegal
mpg123.h(1378): error C2143: syntax error: missing ')' before '*'
mpg123.h(1378): error C2091: function returns function
mpg123.h(1378): error C2143: syntax error: missing '{' before '*'
mpg123.h(1378): error C2059: syntax error: ')'
mpg123.h(1379): error C2143: syntax error: missing ')' before '*'
mpg123.h(1379): error C2365: 'off_t': redefinition; previous definition was 'typedef'
...
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).
gstsiddec.cc:78:17: error: invalid suffix on literal; C++11 requires a space between literal and string macro [-Werror=literal-suffix]
#define FORMATS "{ "GST_AUDIO_NE(S16)","GST_AUDIO_NE(U16)", S8, U8 }"
^
gstsiddec.cc:78:38: error: invalid suffix on literal; C++11 requires a space between literal and string macro [-Werror=literal-suffix]
#define FORMATS "{ "GST_AUDIO_NE(S16)","GST_AUDIO_NE(U16)", S8, U8 }"
^
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 old code was using gst_caps_normalize() and was generally overly
complex. Simplify by picking sample rate and number of channels from
upstream and the sample format from the allowed caps. If the format caps
is a list of strins, just pick the first one. And if the srcpad isn't
linked yet, use the default format (S16).
https://bugzilla.gnome.org/show_bug.cgi?id=740195
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
Removing instead of updating as previously pointed-to page
(now http://dvd.sourceforge.net/dvdinfo/) is already linked
from dvd.sourceforge.net's homepage as: "Collection of
information on file formats/data structures relating to DVD
navigation/SPUs."
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.
a52_init initializes the IMDCT global state as well as creating
a new state. When two A52 decoders are created (eg, when two AC3
tracks are contained in a video), calls to a52_init may happen
at the same time, and the IMDCT initialization is not reentrant.
https://bugzilla.gnome.org/show_bug.cgi?id=746781
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>
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
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
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).
