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>
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.
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
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
Move creation of supported sink pads into class_init function
which is also the only place where they're used. Unref the
caps when no longer needed, the pad template will take its
own ref.
https://bugzilla.gnome.org/show_bug.cgi?id=784982
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
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
