When the stream resolution change it is needed to negotiate
a new pools and to update the caps.
Resolution change could occurs on a new sequence or a new
picture so move resolution change detection code in a common
function.
Only call streamoff if the resolution occur while decoding a key frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8064>
We must drain the pending output picture so that subclass can renegotiate
the caps. Not doing so while still renegotiating would mean that the
subclass would have to do an allocation query before pushing the caps.
Pushing the caps now without this would also not work since these caps
won't match the pending buffers format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8064>
With the old method of adding build RPATHs, only the libsoup as
a subproject was supported. However, it's possible to use Homebrew for
libsoup too by adding libsoup as a dependency to the target (even
though we don't link to it).
Apple ld will not add a LC_LOAD_DYLIB entry for a library unless there
are symbols that need it because meson passes `-dead_strip_dylibs`, so
we can do this without issue.
As a bonus, this ensures the correct build RPATHs in all cases.
Additionally, we still need to explicitly add an LC_RPATH for the
installed case.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4027
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8403>
In many places in the log tracer %d was used for data types we have
string format functions. This is especially problematic when the data
type is not immediately obvious to the reader (e.g. gboolean vs
GstFlowRet, where TRUE==1 but GST_FLOW_OK==0) or the values are not easy
to memorize (GST_STATE_CHANGE_PLAYING_TO_PAUSED==35).
This patch replaces all the integer codes with string representations so
that the logs are easier to understand by humans.
The formatting of GstBufferList by the log tracer is also updated to use
GST_PTR_FORMAT instead of a raw pointer, so the user can see the
timestamps, size and number of buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8414>
For VPS, PPS, APS, OPI and DCI, the extension flags are the last syntax
in the structures, and according to the spec, should be ignored if set to 1.
Therefore, we can just ignore them rather than failing.
This fixes a few failures in fluster, like in the PSEXT_A_Nokia_2 stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8359>
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>
If collecting the backchannel stream after the stream has begun
preparing, make sure to join it to the RTSP media bin, as is
done for dynamic payloaders in the pad-added handler. Add a
new internal stream creation method for it, that could be
publically exposed later if it proves useful.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8378>
When prerolling / blocking an RTSP media, don't consider receiver
streams like onvif backchannel in the 'is everything blocked' check,
as those streams won't receive data until after the RTSP stream
is running.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8378>
