Previously the wrapping of the 24-bit reference time was not handled
correctly when transforming it into GstClockTime. Given the unit of 64ms
the span that could be represented by 24 bits is 12 days and depending
on the start value we could get a wrapping problem anytime within this
time frame. This turned out to be particularly problematic for the GCC
algorithm in gst-plugins-rs which tried to evict old packages based on
the "oldest" timestamp, which due to wrapping problems could be in the
future. Thus, the container managing the packets could grow without
limits for a long time thereby creating both CPU and memory problems.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7527>
Don't assume that video/x-raw caps means buffers are mappable
or can be processed by videoconvert and friends. Only plug
those converters for real system memory, and treat other
memory capsfeatures as hardware surfaces
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7741>
Some file format standards don't require mastering-display-info
and content-light-level values to be provided.
Decklink however requires the static HDR metdata for the PQ transfer
function which we may not have.
CTA-861-G mentions that in this case, 0 may provided as an 'unknown'
value which is what we use here.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7742>
* Consistently name parse functions according to their message type and
deprecate the misnamed ones,
* Add missing parse functions,
* Check for the correct message type when parsing
* Use correct field name for warning message details
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7754>
If a stream has an 'irregular' frame rate (e.g. metadata) RTCP SR
may be generated way too early, before the RTPSource has received
the first packet after Latency was configured in the pipeline.
We skip such RTPSources in the RTCP generation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7740>
This is documented as:
> you can query how many buffers are queued by reading the
> #gstqueue:current-level-buffers property. you can track changes
> by connecting to the notify::current-level-buffers signal (which
> like all signals will be emitted from the streaming thread). the same
> applies to the #gstqueue:current-level-time and
> #gstqueue:current-level-bytes properties.
... but was not implemented.
This also respects the `notify::silent` property for the notify signals
to be less intrusive.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7486>
Instead of registering the whole list of formats associated to a chroma, our
experience with GstVA tells that entry points only handles one color format per
supported chroma, and they are reflected in the static table.
This avoids exposing unsupported color formats for negotiation.
Fixes: #3914
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7708>
There is the possibility than an element/code/helper creates an identical
`GstStream` (same type and stream-id) instance instead of re-using a previous
one.
For those cases, when detecting whether a `GstStream` is already present in a
collection, we need to do more checks than just comparing the pointer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7716>
If we can't get the current caps when receiving a stream-start, that's fine,
they can/will be provided by other means at a later time.
What we definitely should not do is provide the starting caps of the chain,
which are potentially completely different from the end ones (like for example
`application/x-rtp`)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7716>
If an encoder supports multiple codecs (a bin wrapping/auto-plugging encoders)
then its src pad template caps might list the supported codecs. Without this
patch the selected parser would be the one corresponding to the first codec,
leading to caps negotiation error later on. The proposed fix is to check the
media type on the parser candidates sink pad templates according to the
requested encoded format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7670>
