If mpegtsmux receives the same caps again, it wrongly claims the stream
type changed:
error: Stream type change from 06 to 8f not supported
This adds a unit test that demonstrate the issue in the very hacky way.
I have seen this happening with the below pipeline when upstream caps
changes. Since the caps filter fixates the caps received by opusenc and
mpegtsmux, the stream type cannot change.
...
! audioconvert
! audio/x-raw,format=S16LE,channels=2,rate=48000
! opusenc bitrate=128000
! mpegtsmux
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9430>
Make it work a little more like RTP. Have the source interact with the
clock and set the capture time on each packet. Then the other elements
can use that to do adjustments. Since AVTP is always very low latency,
it can be assumed that the gPTP clock at the packet reception is very
close to the sending time, never more than 2 seconds off, so the
timestamps can be compared directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9412>
Change so that the handling of NAL unit that can't be parsed when using
AU alignment is the same as when using NAL alignment, ie drop the data
if it can't be parsed.
If the AU contains more than one NAL unit any correctly parsed NAL unit
in the AU is kept.
Fixes#4436
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8976>
By design, unixfd is meant to be used for zero-copy and failing when the data is
not FD based memory is wanted to help debug pipelines. Though, there exists
cases, notably with RTP payloader and demuxers, where its not possible
to get all the data into FD memory through allocation queries.
To allow using unixfd for these cases, introduce a property on the unixfdsink
that enable copying the non FD data into freshly allocated memfd.
Co-authored-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8861>
Depending on the system load the test 'video_capture_with_tags' may
fail or not. Reason is that 'videotestsrc' may emit a buffer before
the final caps negotiation on the recording pipeline has happened
after dynamic linking.
In that case there would be a caps change and because videorate does
no longer drop old buffers and caps on change but pushes duplicates if
required qtmux will notice a caps change and fail to link.
The problem is a synchronization problem in 'camerabin' which became
obvious with the changed behaviour of 'videorate'.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8579>
Before this patch, there could be duplicate payload types in offers that
have, within a media section, multiple codecs and RTX enabled:
```
m=video 9 UDP/TLS/RTP/SAVPF 96 97 97 <-- HAS DUPLICATES
a=sendrecv
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 transport-cc
a=rtpmap:97 H264/90000
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 transport-cc
a=rtpmap:97 rtx/90000 <--------- PT IS DUPLICATE
a=fmtp:97 apt=96
```
Fix this by populating the media_mapping array with all media formats
rather than only the first one. The added test case reproduces the issue,
which fails without this patch.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8259>
We get loads of warnings when parsing videos from users:
gsth264parser.c:1115:gst_h264_parser_parse_user_data_unregistered: No more remaining payload data to store
gsth264parse.c:646:gst_h264_parse_process_sei:<h264parse0> failed to parse one or more SEI message
Those are raised because of unregistered SEI without user data.
The spec does not explicitly state that unregistered SEI needs to have
data and I suppose the UUID by itself can carry valuable information.
FFmpeg also parses and exposes such SEI so there is no reason for us no
too as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7931>
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>
If the pending remote description has an invalid BUNDLE group _parse_bundle()
triggers early return from _create_answer_task(), before ret has been
initialized, so it needs to be checked before attempting to call
gst_sdp_message_copy().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7423>
