This is similar to how the same issue was handled in qtdemux.
In order for the "DTS <= PTS" constraint to be respected, we calculate the
maximum temporal reordering that can happen (via index tables).
If there is a non-0 temporal reordering, we:
* Shift all outgoing PTS by that amount
* Shift segment for that stream by that amount
* Don't modify DTS (i.e. they might end up having negative running-time, before
the start of the segment)
Also ensure all entries have a valid PTS set, previously this wouldn't be set
for entries with a temporal offset of 0.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/584
(and maybe a lot of other issues)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2371>
When the muxer is operating in VBR mode, it's kind of expected
for now that we might not put the PCR in exactly the right place,
because the muxer doesn't schedule packets that way. In that case
don't warn constantly about the PCR ending up a few ms off target.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2295>
This is a work-around to identify some main profile streams having
wrong profile_idc. There are some wrongly encoded main profile streams
which doesn't have any of the profile_idc values mentioned in Annex-A,
instead, general_profile_idc has been set as zero and the
general_profile_compatibility_flag[general_profile_idc] is TRUE.
Assuming them as MAIN profile for now.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2322>
Some elements will make use of the automatically generated names to
create new pads in future muxer instances, for example splitmuxsink.
Previously we would've created a pad with a random pid that would become
"sink_0", and then on a new muxer instance a pad "sink_0" and tsmux
would've then failed because 0 is not a valid PID.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2318>
Previously pads might have been requested already (e.g. in NULL state),
then reset was called (e.g. because changing state) and then a new pad
was requested. Resetting is re-creating the internal muxer object and as
such resetting the pid counter, so the next requested pad would get the
same pid as the first requested pad which then leads to collisions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2317>
Some decoder implementations might drain out internal buffers and
reset its status on segment-done event. So, in case that
upstream stream-format is packetized but downstream supports only
byte-format, required codec-data might not be forwarded toward
downstream if such parameter set NAL units don't exist in inband
bitstream. Therefore, parse elements should re-send parameter set NAL
units like the case of flush event.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2334>
alphacombine element is a simple element that assumes buffers are always
paired, or at least that missing buffers are signalled with a GAP. The QoS
implementation in the GstVideoDecoder base class allow decoders dropping
frames independently and that could lead to stall in alphacombine.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2326>
This is a video specific sink used to test video CODEC conformance. This is similar
to a combination of filesink and testsink, but will skip over any type of
padding that GStreamer Video library introduces. This is needed in order to obtain the
correct checksum or raw yuv data.
This element currently support writing back non-padded raw I420 through the
location property and will calculate an MD5 and post it as an element message
of type conformance/checksum. More output format or checksum type could be
added in the future as needed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2287>
Alpha combine works by appending the GstMemory for the alpha channel
to the GstBuffer containing I420, thereby pushing A420 on its src pad.
Add support for the same workflow for NV12, thereby producing the
recently introduced AV12 format (NV12 + Alpha).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2277>
Each stream stores the `program_array_index` of its position in its
program's `streams` array. When we remove a stream from this array, we
need to correct the `program_array_index` of all streams that were
backshifted by the removal.
Also extract the removal into a new function and add some more safety
checks.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2266>
Even though input/output resolutions are identical there, default
buffer size of progressive and interleaved formats could be different
because we are rounding up height of all plane of interlaced frame
to be multiple of two.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2244>
As per usage of this element, everything from this pad is a
duplicate. Instead of implemented needless aggregation, simply
drop all events from this pad and let the one from the main stream
passthrough. Also stop proxying some queries from the alpha pad_too.
This fixes racy test failure:
- validate.file.playback.scrub_forward_seeking.opus_vp9-alpha_webm
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2247>
It turns out that downstream returning OK after EOS is a bug in
multiqueue. As we moved to queue, we no longer have this issue.
Let's keep the code clean and just assuming that downstream will
keep returning EOS and allow convergence of flow.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2247>
As the alphacombine is simplified to received matching pair of buffers,
we can't just stop streaming when we receive EOS from downstream. Due
to usage of queue, the moment we get this return value may differ.
Though, by continuing pushing, we override the last_flowret on the pad
which can make us miss that we effectively can combine all flow into
EOS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2238>
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>
