This commit adds a .gitlab-ci.yml file, which uses a feature
to fetch the config from a centralized repository. The intent is
to have all the gstreamer modules use the same configuration.
The configuration is currently hosted at the gst-ci repository
under the gitlab/ci_template.yml path.
Part of https://gitlab.freedesktop.org/gstreamer/gstreamer-project/issues/29
Avoid switch/case per frame for format decision and detect the format
only if where it could be changed. Note that, whenever encoder->input_state
is changed, gst_x264_enc_init_encoder() is called.
https://bugzilla.gnome.org/show_bug.cgi?id=797164
Don't use GST_EVENT_TIMESTAMP to transfer any PTS
associated with a highlight event, instead store
it in the event structure directly, as
GstEvent::timestamp will disappear in GStreamer 2.0
https://bugzilla.gnome.org/show_bug.cgi?id=761477
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