libx264 used to be built for one specific bit depth, and if we
wanted to support multiple bit depths we would have to dynamically
load the right .so from different paths. That has changed now, and
libx264 can include support for multiple depths in the same lib,
so we don't need to do the dlopen() dance any more. We'll keep
the vtable stuff around until we can drop support for older x264.
gstx264enc.c:2927:36: error: ‘x264_bit_depth’ undeclared
https://bugzilla.gnome.org/show_bug.cgi?id=792111
add_global_arguments() can't be used in subprojects. It's
entirely possible that -ugly is a subproject but gstreamer
is picked up from an installed location, so we should
really use add_project_arguments() in both cases.
WARNING: Trying to compare values of different types (str, int).
The result of this is undefined and will become a hard error
in a future Meson release.
VUI(Video Usability Information) parameters should be set
according to the specification. However, some of the existing
hardware decoders refuse to decode in certain combinations of
the resolution and VUI parameters. To support the legacy
decoders, this patch provides 'insert-vui' to skip the settings.
https://bugzilla.gnome.org/show_bug.cgi?id=791331
LIBCDIO_VERSION_NUM was defined as e.g. 94 for 0.94 but is now defined
as 1 for 1.0. We had various checks for < 83, which of course succeeded
now although we are >= 0.83.
Fix this by checking for < 76 (0.76) too, as that is the minimum version
we currently support and everything < 76 is going to be >= 1.0.
https://bugzilla.gnome.org/show_bug.cgi?id=791301
This is a regression that was introduced by
commit 1803b3c185
" asfdemux: Add support for dvr-ms"
The problem is that some files/streams might contain stream definition
but there is no actual packets for those streams.
This was used to "define" streams with different bitrates for example.
The first_ts calculation resulted in never ever finding a valid first_ts
since some streams were empty, and therefore never "activating" itself.
Instead of that we first check if we are prerolled. And if we are we
unconditionally get the "first_ts"
The preroll check has been adapted to check whether streams of
each defined type (i.e. audio/video/sub) has been prerolled. This solves
the problem of having different streams of a particular type where only
one stream actually has data.
Only plugin entry points should be exported.
Currently plugins might export more symbols with
the meson build, as we don't have the exports
regexp there that we pass to libtool.
