In rtpbin we already systematically check for all property names
except latency, correct that.
In webrtcbin we need to check before trying to use the do-retransmission
property.
This is useful for the case where an element like identity gets passed
to rtpbin's request-jitterbuffer property, when the application wants
to use webrtcbin in an SFU situation, with no reordering and no added
latency
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6112>
Today when using the `splitmuxsrc` on a collection of files named as:
```
item0.mkv
item1.mkv
item2.mkv
[...]
item10.mkv
item11.mkv
[...]
```
You will get a continuous stream made in the order of:
```
item0.mkv -> item1.mkv -> item10.mkv -> item11.mkv -> [...]
```
You can fix this by having smarter names of the items:
```
item000.mkv
item001.mkv
item002.mkv
[...]
item010.mkv
item011.mkv
[...]
```
Will get you:
```
item000.mkv -> item001.mkv -> item003.mkv -> item004.mkv -> [...]
```
But, we could also "fix" the former case by using natural ordering when
comparing the files in gstsplitutils.c.
Fixes#2523
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4491>
When level value is greater than 127, it was being clamped but this clamped
value was not the one being actually used. For level values greater than 127
this resulted in an incorrect value being used. As an example, a level value
of 187, after and'ed with 0x7F, it would result in 0x3B being reported as the
level value.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5893>
The `GstFlowCombiner` is responsible for tracking the flow of each
stream and handle the overal flow return value. Without that, we
can end up with the following scenario:
- Audio+video stream
- Only the video stream is linked downstream
- The audio stream goes EOS, video doesn't yet
-> We update the Flow in the combiner with OK as all streams are not EOS
- Video goes EOS because downstream returned EOS
-> `qtdemux` returns `FLOW_OK` forever because the unlinked audio pad
has `last_flowret==FLOW_OK`
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5724>
If this property is enabled then the jitterbuffer will do the normal PTS
calculations according to the configured mode instead of making use of
the RFC7273 media clock.
The timestamp calculated from the RFC7273 media clock will only be
stored in the reference timestamp meta, if addition of that meta is enabled.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5512>
When this property is used, it is assumed that the system clock is
synced close enough to the media clock used by an RFC7273 stream.
As long as both clocks are at most a few seconds from each other this
will give the correct results and avoids having to create an actual
network clock that has to sync first.
If the system clock is actually synchronized to the media clock then
everything will behave exactly the same, otherwise the reference
timestamp meta will be correct but the buffer timestamps will be off by
the difference between the two clocks.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5512>
Do more checks for clock equality than just checking pointers. The same
NTP/PTP clock might be used as pipeline clock but a new instance, so
instead also check what clock they are synced to.
Also handling setting / resetting of the media clock and pipeline clock
correctly by resetting the media clock's state accordingly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5512>
Because we treat raw audio chunks/samples as keyframes, they were interfering
with seek time adjustment.
Became apparent when the accompanying video stream was I-frame only,
for example ProRes.
Since raw audio streams can be seeked freely, it's fine to just ignore them here,
giving priority to the real keyframes in the video stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4946>
With one regular image file path provided (without %05d),
the element was stuck in a dead loop counting the frames:
gst_image_sequence_src_count_frames
This allows to display any image file out of the element
for a given number of buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5471>
We were already converting the pad last timestamp to running time but
not the segment position.
This segment position is used by gst_aggregator_simple_get_next_time()
to compute the waiting time when aggregating.
Those waiting times were wrong in my live pipeline using the system
clock, resulting in the aggregator to never wait at all.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5460>
scanlines->m1 = same line of the previous field
scanlines->t0 = line above of the current field
scanlines->b0 = line below of the current field
scanlines->mp = same line of the next field
Deinterlacing a field weaved frame:
When deinterlacing the top field, the next bottom field is available
(part of the same frame). but when deinterlacing the bottom field,
the next top field (part of the next frame) is not available and
scanlines->mp equals NULL.
In this case it's better to use greedy algorithm using the prevous field
(twice) rather then linear interpolation of the current field.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5331>
If we end up with GST_CLOCK_TIME_NONE as running time for an RTP packet
then this can't be used for bitrate estimation, and also not for
constructing the next RTCP SR. Both would end up with completely wrong
values, and an RTCP SR with wrong values can easily break
synchronization in receivers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5329>
The timestamp offset can be negative, and it can be a bigger negative
number than the latency introduced by the rtpjitterbuffer so the overall
timeout offset can be negative.
Using the negative offset for calculating how many packets can still
arrive in time when encountering a lost packet in an equidistant stream
would then overflow and instead of considering fewer packets lost a lot
more packets are considered lost.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5296>
This elements pass RTP packets along unchanged and appear as a RTP
payloader element.
This is useful, for example when using the gstreamer-rtsp-server
library, in the case where you are receiving RTP packets from a
different source and want to serve them over RTSP. Since the
gst-rtsp-server library expect the element marked as payX to be a RTP
payloader element and assumes certain properties are available.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5204>
