* Add support for H265
* Don't overwrite original codec_data / streamheader in the output
caps, but instead allow them to change and send them to the
combiner at the right moment: encoder caps, reencoded GOP,
original caps, original GOP(s), and potentially encoder caps
and rencoded last GOP.
* For H264 / H265, force usage of a format with inband SPS / PPS
(avc3 / hev1), this is cleaner than misadvertising avc1, hvc1 and
some muxers like mp4mux will actually advertise both differently.
Unfortunately, while mp4 supports updating the codec_data and using
avc1 with no in-band SPS / PPS updates, it turns out some decoders
(eg chrome / firefox) don't handle this particularly well and stop
decoding after the reencoded GOP. We could expose a switch to
force usage of avc1 / hvc1 nevertheless, but for now stick to
requiring that the parser output SPS / PPS in-band with
config-interval=-1 (that has not changed)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1249>
Adding new property for user to be able to set expected the maximum
number of blend task threads. This can be useful in case that user
wants to restrict the number of parallel task runners for system
resource management or debugging/development purpose.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1242>
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>
This new tracer will list loaded elements and plugins. This should
make it easier to generate minimal builds of GStreamer.
This also traces other features such as typefind functions, device
providers and dynamic types.
The format of the output of gst-stats should match the parameters
expected by the meson based gst-build system.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/782>
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>
Originally, if a buffer arrives with crop meta but downstream doesn't
handle crop allocation meta, vapostproc tried to reconfigure itself to
non pass-through mode automatically. Sadly, this behavior was based on
the wrong assumption that propose_allocation() vmethod would bring
downstream allocation query, but it is not.
Now, if vapostproc is in pass-through mode, the cropping is passed to
downstream. Pass-through mode can be disabled via a parameter.
Finally, if pass-through mode isn't enabled, it's assumed the buffer
is going to be processed and, if cropping, downstream already
negotiated the cropped frame size, thus it's required to do the
cropping inside vapostproc to avoid artifacts because of the size of
downstream allocated buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2443>
There are three framerate conversion algorithms described in
<https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md>,
interpolation is not implemented so far and thus distributed timestamp algorihtm
is considered to be more practical which evenly distributes output timestamps
according to output framerate. In this case, newly generated frames are inserted
between current frame and previous one, timestamp is calculated by msdk API.
This implementation first pushes newly generated buffers(outbuf_new) forward and
the current buffer(outbuf) is handled at last round by base transform automatically.
A flag "create_new_surface" is used to indicate if new surfaces have been generated
and then push new outbuf forward accordingly.
Considering the upstream element may not be the msdk element, it is necessary to
always set the input surface timestamp as same as input buffer's timestamp and
convert it to msdk timestamp.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2418>
Below fallback paths were introduced in
9759810d82
if setting period time after buffer time failed :
1) Set period time and then buffer time if it doesn't work
2) Set only buffer time
3) Set only period time
These all were not functioning properly since they were using old
copy of snd_pcm_hw_params_t which already had some fields set
as per previous try and this was causing issues as driver was
referring to that old value while trying to set them again in
fallback paths.
So now we always use the initial copy of snd_pcm_hw_params_t
for every fallback and same is also being done at
557c429510
Also we change the sequence to set period time earlier than
buffer time since period bytes being the smaller unit, most of the times
if underlying alsa device has a dependency then it is of period bytes
to be a multiple of some value (as per underlying DMA constraint)
and rest of the parameters like buffer bytes need to be adjusted
as per period bytes.
The same sequence is also followed in alsa-utils at
9b621eeac4
Fix 2) and 3) scenarios by returning success if the exclusive setting is passed
and not doing any further setting for buffer time or period time.
Add new fallback path of not setting any buffer time and period time
if all above fallback paths fail. The same is also being
followed at aforementioned pulseaudio commit.
In case of alsasink, remove the retry goto label, since it is not
required anymore as fallback paths take care of setting default
values if driver is not accepting any of the fallback paths.
Use separate label for exit to free params structs and return err
code. This also fixes leak in no_rate goto path in alsasink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1212>
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>
The mapping between an RTP session and the SDP m= line is not always the
same, especially when BUNDLEing is used.
This causes a failure in a specific case where if when bundling,
if mline 0 is a data channel, and mline 1 an audio/video section,
then retrieving the transceiver at mline 0 (rtp session used) will fail
and cause an assertion.
This fix is actually potentially a regression for cases where the remote
part does not provide the a=ssrc: media level SDP attributes as is now
becoming common, especially when simulcast is involved.
The correct fix actually requires reading out header extensions as used
with bundle for signalling in the actual data, what media and therefore
transceiver is being used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2467>
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-base/-/merge_requests/1192>
