This commit adds a Find Module implementing the necessary logic to link
against GStreamer, while implementing some extra bits to enhance the
compatibility.
The first addition is the `mobile` target, which implements the
monolithic `gstreamer_android` library, and which here gains
compatibility with Apple's operating systems.
The second addition is the handling of the basic GStreamer libraries as
`--whole-archive` when statically linked, which was ported from the
ndk-build project in Cerbero. This is not easy to do, as CMake suffers
from several issues that impede its proper usage of pkg-config:
- It cannot differentiate between system/compiler specific libraries
e.g. `-lm`, `-ldl`, but especially `-framework Cocoa`.
- It does not support `--whole-archive` natively until 3.27
- It attempts to reorder flags blindly by separating them with spaces,
thus requiring the use of `-Wl,` wrapping or (in the case of Apple
frameworks) manual framework lookup
The third addition is the port of the Fontconfig and ca-certificates
bundling logic.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6881>
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>
We do not own any ref to queries when running them.
If we end up processing the query from the streaming thread, it means that it was
a serialized query, and the query is being waited to be processed on the sinkpad
streaming thread, thread which owns the reference.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7767>
Add missing pixel format constants, and mappings for
P010, packed variants of 420 and RGBA layouts to GStreamer
buffer formats. This fixes problems with android decoders
refusing to output raw video frames with decoders that
announce support for these common pixel formats and
only allowing the 'hardware surfaces output' path.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7743>
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>
The diff between compared timestamps might be outside the gint range
resulting in wrong sorting results. This patch corrects that by
comparing the timestamps and then returning -1, 0 or 1 depending on the
result.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7726>
The wraparound handling code assumes that the PCR gets updated regularly for
being able to detect wraparounds. With ignore-pcr=true that was not the case and
it stayed initialized at 1h forever.
To avoid this problem, update the fake PCR whenever the PTS advanced by more
than 5s, and also detect wraparounds in these fake PCRs.
Problem can be reproduced with
$ gst-launch-1.0 videotestsrc pattern=black ! video/x-raw,framerate=1/5 ! \
x264enc speed-preset=ultrafast tune=zerolatency ! mpegtsmux ! \
tsdemux ignore-pcr=true ! fakesink
which restarts timestamps at 0 after around 26h30m.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7588>
Some servers (e.g. Axis cameras) expect the client to propose the encryption
key(s) to be used for SRTP / SRTCP. This is required to allow re-keying so
as to evade cryptanalysis. Note that the behaviour is not specified by the
RFCs. By setting the 'client-managed-mikey-mode' property to 'true', rtspsrc
acts as follows:
* For a secured profile (RTP/SAVP or RTP/SAVPF), any media in the SDP
returned by the server for which a MIKEY key management applies is
elligible for client managed mode. The MIKEY from the server is then
ignored.
* rtspsrc sends a SETUP with a MIKEY payload proposed by the user. The
payload is formed by calling the 'request-rtp-key' signal for each
elligible stream. During initialisation, 'request-rtcp-key' is also
called as usual. The keys returned by both signals should be the same
for a single stream, but the mechanism allows a different approach.
* The user can start re-keying of a stream by calling SET_PARAMETER.
The convenience signal 'set-mikey-parameter' can be used to build a
'KeyMgmt' parameter with a MIKEY payload.
* After the server accepts the new parameter, the user can call
'remove-key' and prepare for the new key(s) to be served by signals
'request-rtp-key' & 'request-rtcp-key'.
* The signals 'soft-limit' & 'hard-limit' are called when a key
reaches the limits of its utilisation.
This commit adds support for:
* client-managed MIKEY mode to srtpsrc.
* Master Key Index (MKI) parsing and encoding to GstMIKEYMessage.
* re-keying using the signals 'set-mikey-parameter' & 'remove-key' and
then by serving the new key via 'request-rtp-key' & 'request-rtcp-key'.
* 'soft-limit' & 'hard-limit' signals, similar to those provided by srtpdec.
See also:
* https://www.rfc-editor.org/rfc/rfc3830
* https://www.rfc-editor.org/rfc/rfc4567
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7587>
When force-live is TRUE, aggregator will correctly change its state with
NO_PREROLL, but unless something upstream is live did not previously set
live to TRUE on the latency query.
Fix this by or'ing force_live into the result.
Also improve debug
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7718>
Clients that already gotten a signal for synced clock, may rely on
getting the same when marked as corrupted to take appropriate action. So
send clock signal indicating no sync at identified corrupted state.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7664>
This allows the stream to drive the buffers submitted to the display server.
If the application does not receive frame events for a period of time due to
minimization or tty switch for example, instead of waiting to process and
then catching up when frame events resume, the stream will resume instantly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7691>
There is no requirement for a base DRM format to be supported by libgstvideo
in order to be uploaded to. Don't limite to DRM fourcc that have a libgstvideo
format mapping. This notably enabled AFBC support, which uses an opaque based
format that does not have a linear definition. This also adds R8/RG88 and
simimlar other formats that are not yet mapped in libgstvideo.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7689>
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.
For memory allocation reasons, only allows resolution change
on non keyframe if the driver support remove buffer feature.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7684>
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/7684>
Add helpers function to call VIDIOC_REMOVE_BUFS ioctl.
If the driver support this feature buffers are removed from the queue when:
- the pool when is detached from the decoded.
- the pool is released.
- allocation failed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7684>
Use VIDIOC_CREATE_BUFS ioctl to create buffers instead of VIDIOC_REQBUFS
because it allows to create buffers also while streaming.
To prepare the introduction of VIDIOC_REMOVE_BUFFERS create
the buffers one per one instead of a range of them. This way
it can, in the futur, fill the holes.
gst_v4l2_decoder_request_buffers() is stil used to remove all
the buffers of the queue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7684>
When a datachannel within a session is removed after proper close,
reference to the error_ignore_bin elements of the datachannel
appsrc/appsink were left in webrtcbin.
This caused the bin-objects to be left and not freed until the whole
webrtc session was terminated. Among other things that includes a thread
from the appsrc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7675>
We want to ensure the stream-collection is present on the pad (as a sticky
event) before we expose the pad.
This is more reliable since it will ensure it is present before any other event
is pushed through.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7609>
- Add mtd_meta_clear to allow specific analytics-meta to handle their clear
operation specific to their type.
- Clear mtd's attached when analytic-meta is freed. When the buffer where
analytics-meta is attached is not from a buffer pool
gst_analytics_relation_meta_clear will not be called unless we explicitly call
it in _free. This important otherwise _mtd_clear are not called and lead to
leak if embedded mtd's allocated memory
- Un-ref in transform if it's a copy
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6026>
