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>
There was an override to fake an IDR as soon as a SPS/PPS
is encountered, but that's not valid, at least an i-slice is needed.
Amend the visl result, as the output is slightly more correct, not
duplicating frame_num.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7330>
This improves the h264parse element to attach LCEVC enhancement data to buffers
using the new GstLcevcMeta API. This metadata will eventually be used downstream
by LCEVC decoders to enhance the RAW video frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7330>
A previous fix, a275e1e029, is correct but was too
permissive since it treats all un-matched NAL units the same as AU delimiters
even though some other NAL unit types can be encountered in the processing loop.
The problem this can cause is that some hardware decoders experience bad
performance when handling FD units that precede the SPS.
This change restores the original behavior for FDs so that they're ignored until
the SPS is received and it preserves the codec conformance test gains that the
fix has achieved.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7166>
When transforming from unknown alignment to frame or obu, the TU timestamp
was not properly transferred. Fix this by saving the TU DTS as the first
DTS seen within the the TU data, and the PTS as the last PTS seen in that
TU data. Finally, reset the TU timestamp after each TU have completed.
Fixes#1496
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6895>
