As the H265/H264 bitstream can support multiple slices,
mastering_display_info_state and content_light_level_state
should be changed only on first slice segment.
Fix#1152
... by seeking to target offset determined by new seek segment,
rather than that of the previous segment. The latter would typically
seek back to start for a non-accurate seek, and lead to a lot
of skipping in case of an accurate seek.
If one of the inputs is live, add a latency of 2 frames to the video
stream and wait on the clock for that much time to pass to allow for the
LTC audio to be ahead.
In case of live LTC, don't do any waiting but only ensure that we don't
overflow the LTC queue.
Also in non-live LTC audio mode, flush too old items from the LTC queue
if the video is actually ahead instead of potentially waiting forever.
This could've happened if there was a bigger gap in the video stream.
According to H264 ITU standards from 06/19, GST_H264_PROFILE_HIGH_422
(profile_idc = 122) with constraint_set1_flag = 0 and
constraint_set3_flag = 0 can be mapped to high-4:2:2 or high-4:4:4.
GST_H264_PROFILE_HIGH_422 with constraint_set1_flag = 0 and
constraint_set3_flag = 1 can be mapped to high-4:2:2, high-4:4:4,
high-4:2:2-intra or high-4:4:4-intra.
The previous implementation had a very high reproducibility race where
if after a track switch, the ex-active track pad completed a buffer
chain (now returning not-linked) the flow combiner had all their pads in
non-linked state, propagating it as an error and stopping the pipeline.
By resetting the flow combiner in response to RECONFIGURE events that
race is made impossible.
Incrementing it afterwards will always have to phase_index >= 1 and we
will never be at the beginning (0) of the phase again, and thus never
reset timestamp tracking accordingly.
This was broken in bea13ef43b in 2010, and
causes interlace to run into integer overflows after 2^31 frames or
about 5 hours at 29.97fps. Due to usage of wrong types for the integers
this then causes negative numbers to be used in calculations and all
calculations spectacularly fail, leading to all following buffers to
have the timestamp of the first buffer minus one nanosecond.
Allowing the UDP elements to bind on an interface is needed in more
complex networks where there are mutiple networks interfaces without
default gateway
From the documentation of gst_base_parse_set_infer_ts, it should be
disabled for non-audio data. Currently just disabling for all video
parsers that have reordered data: h264, h265, mpeg, mpeg4, vc1. Was
already disabled in h263.
Currently tsdemux timestamps only the PTS, and only issues the DTS if
it's different. In that case, parsers tend to estimate the next DTS
based on the previous DTS and the duration, which can accumulate
rounding errors.
Clean up path objects nicely when shutting down,
first by dropping pointers to elements during dispose,
and then by making sure to drop the ref to the path object
when finalizing the switch bin.
Fixes valgrind checks in the unit test.
Coverity rightly complains that checking a pointer for NULL after
dereferencing it is pointless.
Remove the check, and to be safe, assert that gst_buffer_add_meta
returns non-NULL.
CID 1455485
The message buffers are created using `gst_rtmp_message_new` and thus
always contain a GstRtmpMeta. Add checks to appease Coverity's static
analysis.
CID 1455596
CID 1455384
According to the spec, the least significant bit is reserved and should
always we set to 1. Though, some wrong file has been found. Considering
how low important this reserved bit is, relax the validation.
Related to #660
Packets of a given PID are meant to have sequential continuity counters
(modulo 16). If there are not sequential, this is the sign of a broken
stream, which we then consider as a discontinuity.
But if that new packet is a frame start (PUSI is true), then we can resume
from that packet without any damage.
Sometimes, one wants to force a clock on some pipelines - for instance,
when testing TSN related pipelines, one usually uses GstPtpClock or
CLOCK_REALTIME (assuming system realtime clock is in sync with network
one). Until now, one needs to write an application for that - not
difficult, but quite boring if one just wants to test something. This
patch presents a new element to help that: clockselect.
clockselect is a pipeline with two properties to select a clock. One
property, "clock-id", enables one to choose between "monotonic",
"realtime", "ptp" or "default" clock - where default keeps pipeline
behaviour of choosing a clock based on its elements. The other property,
"ptp-domain" gives one the choice of which PTP domain should be used.
Some very simple tests also added for this new element.
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
The peer is already gone when pad_removed_cb() called, so the ghost cannot
be removed. Use g_object_set_data() instead to remember the ghost pad.
Copied from similar code in GstRTPBin.
Since we are not requiring that profile equals GST_JPEG2000_PARSE_PROFILE_BC_SINGLE,
(as the standard requires) we can allow profile to be null. We relax this condition because
OpenJPEG can't create broadcast profiles.
