Prevent cluttering up the rtpsession, and keeping things localized.
Also write TWCC-seqnums for *all* streams in the session if configured by
caps.
A while back WebRTC was not doing TWCC for audio, basically breaking the
whole idea of a "transport-wide seqnuencenumber" applying for all bundled
streams. However, they have since fixed this, and now it no longers
makes sense to be able to single out certain payloadtypes for
use with TWCC, rather just including them all.
This also makes using RTX, RED, FEC etc much simpler, as it will apply
to them all as they enter the rtpsession.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/927>
e.g. when exporting an opaque image, yet with alpha channel.
Apple ProRes certification requires that, when a ProRes-writing
application *knows* that the entire frame is opaque, the application
writes only RGB without alpha even when the clip is RGBA. For that,
this tiny change allows the app to override pixel depth when writing ProRes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1061>
When a buffer is pushed downstream, we should try not to hold the
buffer mapped with write access. Doing so would often lead to
an unneccesary memcpy later.
For instance, gst_buffer_make_writable() in
gst_video_decoder_finish_frame() will cause a memcpy because of
_memory_get_exclusive_reference().
We know that we can perform a two-step remap when using system
memory, as this will not cause the location of the memory to
change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/812>
When outputting fragmented mp4, with a seekable downstream, we rewrite
the moov to maybe add a duration to the mvex. If we start by not
writing the initial moov->mvex->mhed duration and then overwrite with a
moov containing mhed atom, the moov's will have different sizes and
could overwrite subsequent data and result in an unplayable file.
e.g. The initial moov would be of size 842 and the final moov would have
a size of 862.
Fix by always pushing out the mhed duration in the moov when
fragmenting.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/898
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1060>
The matroska codec specs is unfortunately vague on the subject,
stating for H264:
AVC/H.264 stored as described in [@!ISO.14496-15]
and for H265:
HEVC/H.265 stored as described in [@!ISO.14496-15]
This spec however specifies multiple stream formats, our
implementation has opted for interpreting this as avc1 / hvc1,
both of which disallow in-band SPS.
Most decoders however will support in-band SPS / PPS, and
this commit gives the option to explicitly mux in avc3 / hev1,
which allows changing stream parameters on the fly, that is
useful for smart encoding for example.
When either of these stream formats are picked as the input,
changes in codec_data / tier / level / profile do not cause
renegotiation failure, a warning is logged however as it isn't
clear how compliant such a stream is.
The stream-format field is correctly ordered in the template
caps to avoid selecting potentially non-compliant options on
automatic negotiation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1047>
Adds a user-controllable timestamp offset to clusters and blocks. This
should be useful if we want to have timestamps that have significance
outside of the current file (for example, we might set the offset to the
wallclock when the file is being created, or some other common base, if
we want to correlate streams across multiple files).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1051>
Internally videcrop can call gst_video_crop_set_info() with NULL as in
caps. Then critical messages are raised when the in caps are
processed.
To fix this the in caps are checked, and if they are present, its
capsfeature is extracted, otherwise, the previous raw caps detection
remains as before.
Also the videocrop-test removes the format field in the structure
because now its always passed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1056>
Some v4l2 drivers don't have the capacity to change framerate. There is
chance to make decoder capture fps to be 0/0 if numerator and denominator
returned by G_PARM ioctl are both 0. It causes critical warning
"passed '0' as denominator for `GstFraction'".
In order to fix this, add protection when set decoder capture fps according
to output fps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1048>
When connecting to an RTSP server in tunnled mode (HTTP) the server
usually replies with a x-server header. This contains the address
of the intended streaming server. However some servers return an
"invalid" address. Here follows two examples when it might happen.
1. A server use Apache combined with a separate RTSP process to handle
Https request on port 443. In this case Apache handle TLS and
connects to the local RTSP server, which results in a local
address 127.0.0.1 or ::1 in the x-server reply. This address is
returned to the actual RTSP client in the x-server header.
The client will receive this address and try to connect to it
and fail.
2. The client use a ipv6 link local address with a specified scope id
fe80::aaaa:bbbb:cccc:dddd%eth0 and connects via Http on port 80.
The RTSP server receives the connection and returns the address
in the x-server header. The client will receive this address and
try to connect to it "as is" without the scope id and fail.
In the case of streaming data from RTSP servers like 1. and 2. it's
useful to have the option to simply ignore the x-server header reply
and continue using the original address.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1007>
