This is needed if the LCEVC enhancement data is part of the video stream as SEI
and the demuxer outputs 'lcevc=false' src caps because LCEVC enhancement data is
not stored as a separate stream in the container.
To clarify, 'lcevc=true' just means that the video buffers have LCEVC metadata
attached. Therefore, it is valid to have a stream with LCEVC enhancement data as
SEI with 'lcevc=false' as long as it is not attached as metadata.
This will be needed once we add support for the demuxer to attach LCEVC metadata
to video buffers if it is stored in a separate track.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9427>
Similar to h264parse and h265parse, this patch enhances the element to parse
LCEVC enhancement data from SEI, and attach it to output buffers as GstLcevcMeta.
The 'lcevc' field in the output caps is also set to TRUE or FALSE depending on
whether LCEVC data is present or not.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9365>
Similar to h264parse and h265parse, this patch improves the element to parse
the SEI registered user data from NAL units. The core structure of H266 SEI for
ITU-T T.35 is the same as the other parsers, so we can re-use the same logic.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9365>
Similar to h264parse, this patch enhances the element to parse LCEVC enhancement
data from SEI, and attach it to output buffers as GstLcevcMeta. The 'lcevc'
field in the output caps is also set to TRUE or FALSE depending on whether LCEVC
data is present or not.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9335>
This reverts commit fd1428d3ebf937d7656c3788df3ef3ff85fecc31.
As reported in #4524, this changes cause regressions. The problem is due to a
bug in how vp9parse interact with parsebin, presenting downstream negotiation of
alignment to work. This revert to being stuck using frame alignment always,
which fortunately works with libvpx, though less efficient.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9329>
Only the last frame of a super frame should be displayed by default. When
converting from super frame to frame, mark all frames as decode only except the
last one. This fixes vp90-2-22-svc_1280x720_3.ivf conformance test with
stateless decoders such as VA.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8944>
Change so that the handling of NAL unit that can't be parsed when using
AU alignment is the same as when using NAL alignment, ie drop the data
if it can't be parsed.
If the AU contains more than one NAL unit any correctly parsed NAL unit
in the AU is kept.
Fixes#4436
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8976>
If using NAL aligment and only dropping part of the AU, the size
argument given to gst_base_parse_finish_frame was wrong and this assert
in gst_base_parse_finish_frame hit
'gst_adapter_available (parse->priv->adapter) >= size' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8976>
It's not really possible to safely interpret the content afterwards if
it's missing.
Even for AVC3, the codec_data doesn't need to contain a SPS/PPS, but
it still needs to be present to tell downstream elements about the size
of the nal unit length field.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8955>
If we find VPS/SPS/PPS in codec_data and call gst_h266_parse_process_nal
with them, we need to have negotiated before in order to correctly
process them with flags like h266parse->transform set or not depending
on the negotiation. This is important because in certain vvc1/vvi1 streams we
may have correct codec_data but faulty parameter sets in the stream and
we would want to push the parameter sets from codec_data first.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8359>
implement serialization of codec_data containing VvcDecoderConfigurationRecord
as defined in ISO/IEC 14996-15.
The VPS/SPS/PPS NALs are added to the codec_data. APS NALs could be
optionally included as well but will be pushed in-band instead, because:
1. Logic is easier that way. We'd have to filter out for PREFIX_APS only
(SUFFIX_APS aren't allowed in codec_data).
2. APS NALs can also be sent for every non-keyframe slice, and often are, so just pushing
them in-band makes more sense to have less to keep track and avoid possible
duplicates.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8359>
This adds the data required in AVCDecoderConfigurationRecord for
higher profile (High variants) configurations - everything in the if(...) {...} part
of ISO/IEC 14496-15:2024 Section 5.3.2.1.2. (or 5.3.3.1.2 in the 2019 version).
Resolves an error flagged by ComplianceWarden when muxing this into ISOBMFF.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8308>
When a TD is being processed, it is not always pushed immediatly. Resetting
the time information lead to lost of timestamp in TU to Frame conversion. The
TU would be formed by buffer of [TD][Frame], and the timestamp taken from
the TU buffer was lost then the TD was handled.
The handling of TS should be entirely done by the 3 functions:
- gst_av1_parse_handle_obu_to_obu() (direct input to output)
- gst_av1_parse_handle_to_big_align() Reset DTS on detected TU or TD
- gst_av1_parse_handle_to_small_and_equal_align() PTS on show frame, flat DTS
Fixes: 79312357a6
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8026>
We get loads of warnings when parsing videos from users:
gsth264parser.c:1115:gst_h264_parser_parse_user_data_unregistered: No more remaining payload data to store
gsth264parse.c:646:gst_h264_parse_process_sei:<h264parse0> failed to parse one or more SEI message
Those are raised because of unregistered SEI without user data.
The spec does not explicitly state that unregistered SEI needs to have
data and I suppose the UUID by itself can carry valuable information.
FFmpeg also parses and exposes such SEI so there is no reason for us no
too as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7931>
When encoding an image to mpeg2 video, with something like:
gst-launch-1.0 encodebin name=e profile=mpegpsmux:video/mpeg,mpegversion=2,systemstream=false ! \
filesink location=sample.mpg filesrc num-buffers=1 blocksize=$(stat -c%s sample.png) \
location=sample/dts.png ! pngdec ! e.
The only frame's type is set to an invalid value 0
The consequence is that mpegvideoparse sets the delta unit flag on the buffer because
it is not an I frame, then decodebin3 drops this only frame because the delta
unit flag is set and the decoder receives eos before it was able to receive any
encoded data
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7832>
The calculated position was off. I'm not sure of the exact cause;
possibly because we're in AU-aligned byte-stream mode, which means
`transform` is true.
Replacing the math that calculates the NALU positions with code more
similar to what is already in use for `idr_pos` seems to have fixed it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7318>
