Enhance open gop detection to drop B-frame which are invalid
before the first reference frame.
In stream such
gst-integration-testsuites/medias/defaults/mxf/op2b-mpeg2-wave_hd.mxf,
the two first frames must be dropped as we detect an open GOP situation
but in another media, such as http://col.la/1920X1080IXDCAMEX5MIN, the
first frames should not be dropped as we are in a closed GOP situation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/merge_requests/84>
- x264 encoder bitrate profile manager: alloc size is based
on existing allocation
- asfdemux: change length var to 64-bit and check for G_MAXUINT
- realmedia: opaque_data_len is read from 32 bits and then
only subtracted upon.
g_memdup() is deprecated since GLib 2.68 and we want to avoid
deprecation warnings with recent versions of GLib.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/merge_requests/83>
If downstream is constrained to an 8-bit profile, caps queries would
still allow I420_10LE as input. If upstream actually sends such a caps
event, downstream would fail to accept the high-10 profile.
The following pipeline now fails earlier, during the negotiation phase
instead of the stream start:
gst-launch-1.0 videotestsrc ! video/x-raw,format=I420_10LE \
! x264enc ! video/x-h264,profile=constrained-baseline \
! fakesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/merge_requests/59>
This is needed for cross-compiling without a build machine compiler
available. The option was added in 0.54, but we only need this in
Cerbero and it doesn't affect older versions so it should be ok.
Will just cause a spurious warning.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/merge_requests/50>
The --ref option indicate the size of the DPB, hence should be in the range of
0 to 16. This patch also fix the default to match x264enc default 3. This
change isn't a behaviour change since we don't enforce the reported default.
It's needed by the dvdread plugin but also by the x264 plugin in certain
circumstances. As it's part of GLib and always available, simply move it
as a hard dependency to the top-level meson.build.
It's technically true but not for this specific type.
dvdreadsrc.c:394:65: error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
394 | gst_dvd_read_src_make_clut_change_event (src, src->cur_pgc->palette);
| ~~~~~~~~~~~~^~~~~~~~~
Otherwise we get some compiler warnings:
../subprojects/gst-plugins-ugly/ext/x264/gstx264enc.c:200:1: warning: ‘unload_x264’ defined but not used [-Wunused-function]
unload_x264 (GstX264EncVTable * vtable)
^~~~~~~~~~~
../subprojects/gst-plugins-ugly/ext/x264/gstx264enc.c:154:1: warning: ‘load_x264’ defined but not used [-Wunused-function]
load_x264 (const gchar * filename)
^~~~~~~~~
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
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
