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.
1. only recalculate src codec format if sink caps change
2. use correct value for "jp2c" magic in J2C box ID
3. only parse J2K magic once, and store result
4. more sanity checks comparing caps to parsed codec
This adds two properties:
* scte-35-pid: If not 0, enables the SCTE-35 support for the current
program. This will write the proper PMT and send SCTE-35 NULL
commands (i.e. heartbeats) at a regular interval
* scte-35-null-interval: This specifies the interval at which the
NULL commands should be sent
Sending SCTE-35 commands is done by creating the appropriate SCTE-35
GstMpegtsSection and then sending them on the muxer. See the
associated example
We were unconditionally adding top-level descriptors in the PMT which
were only related to bluray support for PS3 (from 10 years ago).
These should be re-added conditionally
This went un-noticed for 6 years :( The issue is that for short
sections (without subtables and CRC), we would always fail when
checking whether we had enough data or not and then default to the
long section checking.
Use the long section checking would then cause interesting side-effects
for short sections (such as believing they were already seen and therefore
would be dropped/ignored).
This allows selecting whether we continue updating our last known
upstream timecode whenever a new one arrives or instead only keep the
last known one and from there on count up.
This uses the last known upstream timecode (counted up per frame), or
otherwise zero if none was known.
The normal last-known timestamp uses the internal timecode as fallback
if no upstream timecode was ever known.
The convert-error signal is emitted whenever we get a GstFlowReturn
other than GST_FLOW_OK. The handler can then decide what to convert that
into - for instance, return the same GstFlowReturn to not convert it.
The default handler will act according to the ignore-error,
ignore-notlinked, ignore-notnegotiated and convert-to properties. If a
handler is connected, these properties are ignored.
In file included from ../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/gstbin.h:27,
from ../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/gst.h:35,
from ../gst/rtp/gstrtpsink.h:23,
from ../gst/rtp/gstrtpsink.c:49:
In function ‘gst_rtp_sink_start’,
inlined from ‘gst_rtp_sink_change_state’ at ../gst/rtp/gstrtpsink.c:509:11:
../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/gstelement.h:422:18: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
422 | gchar *__txt = _gst_element_error_printf text; \
../gst/rtp/gstrtpsink.c:476:3: note: in expansion of macro ‘GST_ELEMENT_ERROR’
476 | GST_ELEMENT_ERROR (self, RESOURCE, NOT_FOUND,
| ^~~~~~~~~~~~~~~~~
../gst/rtp/gstrtpsink.c: In function ‘gst_rtp_sink_change_state’:
../gst/rtp/gstrtpsink.c:477:37: note: format string is defined here
477 | ("Could not resolve hostname '%s'", remote_addr),
| ^~
In file included from ../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/gstbin.h:27,
from ../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/gst.h:35,
from ../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/rtp/gstrtpdefs.h:27,
from ../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/rtp/rtp.h:25,
from ../gst/rist/gstristsink.c:72:
In function ‘gst_rist_sink_setup_rtcp_socket’,
inlined from ‘gst_rist_sink_start’ at ../gst/rist/gstristsink.c:658:10,
inlined from ‘gst_rist_sink_change_state’ at ../gst/rist/gstristsink.c:801:13:
../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/gstelement.h:422:18: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
422 | gchar *__txt = _gst_element_error_printf text; \
../gst/rist/gstristsink.c:595:3: note: in expansion of macro ‘GST_ELEMENT_ERROR’
595 | GST_ELEMENT_ERROR (sink, RESOURCE, NOT_FOUND,
| ^~~~~~~~~~~~~~~~~
../gst/rist/gstristsink.c: In function ‘gst_rist_sink_change_state’:
../gst/rist/gstristsink.c:596:37: note: format string is defined here
596 | ("Could not resolve hostname '%s'", remote_addr),
| ^~
Allows for "low latency" mpeg-ts mode which is not standard, but somewhat common.
For this to work the sender has to put timestamps at a higher frequency than the spec requires.
PES packets with size 0 are unbounded, and
could therefore overflow the 32-bit size
accumulator.
Add a 32MB limit, which is larger than
any PES packet should ever get. If one does,
then output a 32MB chunk and continue.
A guint32 greater than 2^31 would be interpreted as negative by
gst_util_uint64_scale_int() and critical. Use the 64-bit integer version
of the function instead.
Don't signal a pipeline error when processing incomplete
j2pk PES packets that are too small. That can happen normally
during a DISCONT and shouldn't shut down the whole pipeline
Remove some custom and incomplete seek calculation
logic in favour of gst_segment_do_seek(), and
short-circuit any actual seeking or recalculation
if the position didn't change and just send an updated
segment directly.
This removes the custom seeking logic in favour of
using standard core seek handling.
The default behaviour of rtponviftimestamp is to drop buffers
outside the segment. This creates obvious problems for reverse
playback.
The ONVIF specification unfortunately doesn't describe how to handle
that specific use case, but we can expose a property to let the
user disable the dropping behaviour, and forward these buffers with
a G_MAXUINT64 ONVIF timestamp.
Also modify rtponvifparse to handle such timestamps appropriately.
