The parser is used all over the place assuming that after calling
gst_h265_parser_identify_nalu(), the start-code found is can also be
identified. In H264 this works, because scan_for_start_code rely on
gst_byte_reader_masked_scan_uint32() that ensures that 1 byte passed the 3
bytes start code is found. But for HEVC, we need two bytes to identify the
following NAL.
This patch will return NO_NAL_END, even if a start code is found in the case
there was not enough bytes. This solution was chosen to maintain backward
compatibility, and reduce complexicity.
Fixes#1287
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1251>
If the input has a miss-placed filler zero byte (e.g. a filler without a 4
bytes start code on the next NAL), we would endup using the same timestamp
twice. Ask the base class to read the timestamp from the buffer were the NAL
actually starts.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1251>
Same as done for H264, this error was trying to catch the case where we had
a start code without any bytes afterward. This will never happen since the
start code scanner only returns a match if there is one byte after start
code (pattern 0x00000100 / mask 0xffffff00). In H264, once byte is sufficient
to identify the NALU.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1251>
This will stop stripping four bytes start code. This was fixed and broken
again as it was causing the a timestamp shift. We now call
gst_base_parse_set_ts_at_offset() with the offset of the first NAL to ensure
that fixing a moderatly broken input stream won't affect the timestamps. We
also fixes the unit test, removing a comment about the stripping behaviour not
being correct.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1251>
This error was trying to catch the case where we had a start code without any
bytes afterward. This will never happen since the start code scanner only returns
a match if there is one byte adter start code (pattern 0x00000100 / mask
0xffffff00).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1251>
else gst_video_meta_validate_alignment will report error like
"videometa gstvideometa.c:416:gst_video_meta_validate_alignment: Stride of plane 0 defined in meta (384) is different from the one computed from the alignment (320)"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1224>
When negotiating the SDP we should only connect the streams that are
actually mentioned in the SDP. All other streams are not relevant at
this time and would likely be part of a future SDP update. Fixes a
couple of the renegotiation webrtc unit tests.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1240>
In section 9.3.4 a), segment_feature_mode have 0 for absolute and 1 for delta,
while in 19.2, it says the opposite. But the reference code, which usually
rules over the text state that 1 means absolute:
if (hdr->update_data)
{
hdr->abs = bool_get_bit(bool);
And uses it with that meaning to decide weither to override the existing value
or just add the detla. This fixes multiple decoding issues.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1245>
Proper calculate running time for buffers that are out of current
segment and try to honor them.
A typical case is for AVTP packets coming from avtpcvfpay element, as
those may have DTS that falls out of segment (which is about PTS).
By using gst_segment_to_running_time_full(), avtpsink can properly
calculate when to transmit those buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1004>
Seek events will cause new segments to be sent to avtpcvfpay, and for
flushing seeks, a pipeline running time reset. This running time
reset, which effectively changes pipeline base time, will cause
avtpcvfpay element to generate incorrect DTS for the initial set of
buffers sent after FLUSH_STOP.
This happens due the fact that base time change happens only when the
sink gets the first buffer after the FLUSH_STOP - so avtpcvfpay used
the wrong base time to do its calculations.
However, if the pipeline is paused before the seek, sink will update
base time when pipeline state goes to PLAYING again, before avtpcvfpay
gets the first buffers after the flush. Then avtpcvfpay element will be
able to normally calculate DTS for the outgoing packets.
This patch simply adds a warning message in case a flushing seek is
performed on a playing pipeline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1004>
TSN streams are expected to send packets to the network in a well
defined "pace", which is arbitrarily defined for each stream. This pace
is defined by the "measurement interval" property of a stream.
When the AVTP CVF payloader element - avtpcvfpay - fragments a video
frame that is too big to be sent to the network, it currently defines
that all fragments should be transmitted at the same time (via DTS
property of GstBuffers generated, as sink will use those to time the
transmission of the AVTPDU). This doesn't comply with stream definition,
which also has a limit on how many packets can be sent on a given
measurement interval.
This patch solves that by spreading in time the DTS of the GstBuffers
containing the AVTPDUs. Two new properties, "measurement-interval" and
"max-interval-frames", added to avptcvfpay element so that it knows
stream measurement interval and how many AVTPDUs it can send on any of
them. More details on the method used to proper spread DTS/PTS according
to measurement interval can be found in a code commentary inside this patch.
Tests also added for the new property and behaviour.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1004>
This is the first version of AV1 parser implementation in GStreamer.
A test file is also provied with several test cases. It contains a
test sequence taken from the aom testdata set, with one key and one
inter-frame. The same test sequence has been reencoded to annexb.
testdata is taken from aom testdata (and reencoded for annexb) as well
as handcrafted testcases. Once reference testdata is available, the
testing could be imporved aswell.
Co-author: He Junyan <junyan.he@hotmail.com>
Co-author: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/785>
The volatile is not needed here and causes compiler warnings
with newer GLib versions.
gstautoconvert.c: In function ‘gst_auto_convert_dispose’ (and elsewhere):
glib/gatomic.h:108:3: warning: initialization discards ‘volatile’ qualifier from pointer target type [-Wdiscarded-qualifiers]
gstautoconvert.c:224:24: note: in expansion of macro ‘g_atomic_pointer_get’
224 | GList *factories = g_atomic_pointer_get (&autoconvert->factories);
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1237>
If the remote is bundling, but we are not and remote is offering.
we cannot put the remote media sections into a bundled transport as that
is not how we are going to respond.
This specific failure case was that the remote ICE credentials were
never set on the ice stream and so ice connectivity would fail.
Technically, this whole bunde-policy=none handling should be removed
eventually when we implement bundle-policy=balanced. Until such time,
we have this workaround.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1231>
This adds tests to validate whether the avtpcrfsync element applies the
adjustment correctly.
Also, the infrastructure to include additional source files while compiling
is added. This change is exactly the same as the one in gst-plugins-good.
This commit introduces the AVTP Clock Reference Format (CRF) Checker
element. This element re-uses the GstAvtpCrfBase class introduced along
with the CRF Synchronizer element.
This element will typically be used along with the avtpsrc element to
ensure that the AVTP timestamp (and H264 timestamp in case of CVF-H264
packets) is "aligned" with the incoming CRF stream. Here, "aligned" means
that the timestamp value should be within 25% of the period of the media
clock recovered from the CRF stream.
The user can also set an option (drop-invalid) in order to drop any packet
whose timestamp is not within the thresholds of the incoming CRF stream.
