Waiting for the next NAL increases the latency. If alignment=nal/au
has been negotiated, assumes the the buffer contains a complete
NAL and don't expect a second start-code. This way, nal -> nal,
au -> au and au -> nal no longer introduce latency.
As a side effect, the collect_pad() function was not able to poke at the
following NAL. This call is now moved before processing the NAL, so
it's looking at the current NAL before it's ingested into the parser
state in order to dermin if the end of an AU has been reached. The AUD
injection state as been adapted to support this.
This change will break pipelines if alignment=nal is used without respecting the
alignment. Effectively, the parser will no longer fix the broken aligment
which will result in parser error and the termination of the pipeline. Such
issue existed in tsdemux element and might exist in any forks of that code.
Related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1193
Waiting for the next NAL increases the latency. If alignment=nal/au
has been negotiated, assumes that the buffer contains a complete
NAL and don't expect a second start-code. This way, nal -> nal,
au -> au and au -> nal no longer introduce latency.
As a side effect, the collect_pad() function was not able to poke at the
following NAL. This call is now moved before processing the NAL, so
it's looking at the current NAL before it's ingested into the parser
state in order to dermin if the end of an AU has been reached. The AUD
injection state as been adapted to support this.
This change will break pipelines if alignment=nal is used without respecting the
alignment. Effectively, the parser will no longer fix the broken aligment
which will result in parser error and the termination of the pipeline. Such
issue existed in tsdemux element and might exist in any forks of that code.
Related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1193
Until now, any streams in tsmux had to be present when the element
started its first buffer. Now they can appear at any point during the
stream, or even disappear and reappear later using the same PID.
Use GST_OBJECT_LOCK (srtobject->element) to protect only the fields
involved in property access.
Introduce a new mutex srtobject->sock_lock to go with
srtobject->sock_cond and protect the list of callers from concurrent
access.
Per specification in 2.14.2 "For PES packetization, no specific data
alignment constraints apply". So we should not advertise NAL
alignment.
This bug was introduced at the same moment the alignment field was introduced
10 years ago. The plan was that alignment=none (or no alignment field) was to
be used for mpegtsdemux, but no one noticed the error. The reason is that at
the same moment, everything dealing with H264 started defaulting to AU
alignment.
https://bugzilla.gnome.org/show_bug.cgi?id=606662#c22
This patch will have a side effect that a parser is now needed after the
tsdemux element. The following pipeline will not negotiate anymore as the
mpegtsmux element requires alignment={nal,au}.
... ! tsdemux ! mpegtsmux ! ...
As a side effect, anyone that forked from tsdemux should updated their code to
fix this bug.
The previous version of the SHM export support still required a valid
EGLDisplay. The upcoming WPEBackend-FDO 1.8.x aims to remove this requirement,
hence allowing wpesrc to be used without GPU.
in C, & is weaker than the ! operator and clang is giving the following
error about it.
```
../subprojects/gst-plugins-bad/sys/msdk/gstmsdkdec.c:731:7: error: logical not is only applied to the left hand side of this bitwise operator [-Werror,-Wlogical-not-parentheses]
if (!gst_msdk_context_get_job_type (thiz->context) & GST_MSDK_JOB_DECODER) {
^ ~
../subprojects/gst-plugins-bad/sys/msdk/gstmsdkdec.c:731:7: note: add parentheses after the '!' to evaluate the bitwise operator first
if (!gst_msdk_context_get_job_type (thiz->context) & GST_MSDK_JOB_DECODER) {
^
( )
../subprojects/gst-plugins-bad/sys/msdk/gstmsdkdec.c:731:7: note: add parentheses around left hand side expression to silence this warning
if (!gst_msdk_context_get_job_type (thiz->context) & GST_MSDK_JOB_DECODER) {
^
( )
1 error generated.
```
... to prevent requesting decoding before the preparation.
For instance, baseclass should not request decoding a picture if there
is no parsed valid headers, since subclass is most likely
not ready to decoding it.
gst_h265_parser_parse_{vps,sps,pps} APIs were used to parse VPS/SPS/PPS and
also in order to update parser's internal state at once. Meanwhile
gst_h265_parse_{vps,sps,pps} APIs are to parse VPS/SPS/PPS without state update.
This commit introduces new APIs so that only accepted VPS/SPS/PPS by user
can be updated to be used by parser.
gst_h264_parser_parse_{sps,pps} APIs were used to parse SPS/PPS and
also in order to update parser's internal state at once. Meanwhile
gst_h264_parse_{sps,pps} APIs are to parse SPS/PPS without state update.
This commit introduces new APIs so that only accepted SPS/PPS by user
can be updated to be used by parser.
Too many decode surface would waste GPU memory. Also it seems to be
introducing additional latency depending on stream. Since nvcodec
sdk version 9.0, CUVID parser API has been providing the minimum
required number of surface. By using it, we can save GPU memory
and reduce possible latency.
The comparision was not testing anything meaninful. This fixes the comparision
so we now update the caps whenever the value differ. This was detected by
coverity.
CID 1461291
We need to do this without holding the lock as the `g_async_queue_pop`
waits on the loop thread to deliver the stats. The loop thread might
attempt to take the lock as well, leading to a deadlock.
Taking a reference to the connection should be enough to keep this
safe.
Add new property "update-timecode" to allow updating timecode
in picture timing SEI depending on timecode meta. Since the picture
timing SEI message requires proper VUI setting but we don't support
re-writing SPS, this might not work for some streams
... and store all parsed values.
We are storing pic_struct_present_flag although it's not part of
this SEI message but GstH264PicTiming includes it to clarify
following syntax values.
In addition to that, by adding CpbDpbDelaysPresentFlag, we don't need to
refer to VUI anymore.
The rtpbin sends signals for all SSRCs. Don't send an EOS when the SSRC
does not match the stream SSRC.
This avoids problems when an SSRC from another receiver times out.
In some scenarios the fakevideosink shouldn't advertize the overlay-composition
meta for instance, so that overlay elements perform subtitles blending
themselves.
According to the specification, the adaptation field length must be 183 if
there is no payload data and < 183 if the packet contains an adaptation
field and payload data.
Unfortunately some payloaders always set the flag for payload data, even if
the adaptation field length is 183.
Don't return with an error in this case. Clear the payload data flag
instead and parse the adaptation field as usual. This avoids visual
artefacts for such streams.
As per specification in A.3.1 h) and A.3.2 f), the maximum size of the DPB is
16. Fix the maximum in the fine and fix the formula to use MIN instead of MAX
so that we no longer always use the maximum for the profile/level.
