This element will merge video buffers in order to use the alpha stream
luma plane as the alpha of the video stream. The implementation is zero-copy
and currently only support merging I420 stream with an I420, NV12 or GRAY8
alpha stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2199>
The previous test was preventing the pad to be in EOS
when the segment position was greater than segment stop.
It ended up consuming all the data before getting in EOS.
Regarding GST_SEEK_FLAG_SEGMENT it seems to be
correctly handled later in the method.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2173>
The path caps describe the input caps that will select each path, don't
intersect those with the srcpad caps, which could be completely
different. Instead, when querying allowed caps for the srcpad, just
construct the union of all possible output caps from all path srcpads.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2018>
When handling a caps query on the src pad, don't return the union
of input caps. Even when not active, a path element can be queried
for srcpad template caps, or for dropping paths the allowed downstream
caps is anything - as data will be dropped anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2018>
In a case of a scr different from 0, after a seek,
the src_segment.stop has been updated with the duration
not including the base_time (scr). The segment position
needs to be tested upon segment.stop + base_time (scr)
to check for an EOS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2048>
In order to always insert a PCR packet right on time, we need to
check whether one is needed when outputting any packet, not only
a packet for the PCR stream. Most of the PCR packets will remain
data-carrying packets, but as a last resort we may insert stuffing
packets on the PCR stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2073>
Change PCR / SI scheduling so that instead of checking if
the current PCR is larger than the next target time, instead
check if the PCR of the next packet would be too late, so PCR
and SI are always scheduled earlier than the target, not later.
There are still cases where PCR can be written too late though,
because we don't check before each output packet.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2073>
Especially specify the field-order in the interleaved mode. Otherwise it
might cause the negotiation to fail, because
GST_PAD_SET_ACCEPT_INTERSECT is not set on the sinkpad, and the
field-order is missing in the sink template but can be present in the
outside caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2062>
The first time update_src_caps is called, there's no frame parsed yet,
therefore we don't know whether the file has alternate-field interlacing
mode. If we run it again after we have a frame, it might be that now we
have the SEI pic_struct parsed, and therefore we know that it's
field-based interlaced, and therefore the height must be multiplied by
two. Earlier on this was not detected as a change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2022>
Instead of relying on GstBaseParse default behaviour of computing
the duration of a parsed buffer based on the framerate passed
to gst_base_parse_set_framerate(), we instead compute the duration
ourselves, as we have more information available.
In particular, this means we now output buffers with a duration
that matches that of raw interlaced buffers when each field is
output in a separate buffer.
This fixes DTS interpolation performed by GstBaseParse, as the
previous behaviour of outputting each field with the duration of
a full frame was messing up the base class calculations.
When not enough information is available, h264parse simply falls
back to calculating the duration based on the framerate and hope
for the best as was the case previously.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1973>
1. Set the default output alignment to frame, rather than current
alignment of obu. This make it the same behaviour as h264/h265
parse, which default align to AU.
2. Set the default input alignment to byte. It can handle the "not
enough data" error while the OBU alignment can not. Also make it
conform to the comments.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1979>
The current behaviour for obu aligned output is not very precise.
Several OBUs will be output together within one gst buffer. We
should output each gst buffer just containing one OBU. This is
the same way as the h264/h265 parse do when NAL aligned.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1979>
