Make sure that the sync_src pad has caps before the segment event.
Otherwise we might get a segment event before caps from the receive
RTCP pad, and then later when receiving RTCP packets will set caps.
This will results in a sticky event misordering warning
This fixes warnings in the rtpaux unit test but also in the
rtpaux and rtx examples in tests/examples/rtp
https://bugzilla.gnome.org/show_bug.cgi?id=746445
Before we only started it when either:
- there is no send RTP stream
or
- we received an RTP packet for sending
This could mean that if the send RTP pads are connected but never receive any
RTP data, and the same session is also used for receiving RTP/RTCP, we would
never start the RTCP thread and would never send RTCP for the receiving part
of the session.
This can be reproduced with a pipeline like:
gst-launch-1.0 rtpbin name=rtpbin \
udpsrc port=5000 ! "application/x-rtp, media=video, clock-rate=90000, encoding-name=H264" ! rtpbin.recv_rtp_sink_0 \
udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
rtpbin.send_rtcp_src_0 ! fakesink name=rtcp_fakesink silent=false async=false sync=false \
rtpbin.recv_rtp_src_0_2553225531_96 ! decodebin ! xvimagesink \
fakesrc ! valve drop=true ! rtpbin.send_rtp_sink_0 \
rtpbin.send_rtp_src_0 ! fakesink name=rtp_fakesink silent=false async=false sync=false -v
Before this change the rtcp_fakesink would never send RTCP for the receiving
part of the session (i.e. no receiver reports!), after the change it does.
And before and after this change it would send RTCP for the receiving part of
the session if the sender part was omitted (the last two lines).
* Fix critical when new tags are found after segment event has already
been sent.
* Send global tags before stream tags.
* Split sending of tags out of gst_matroska_demux_send_event() into its
own function.
https://bugzilla.gnome.org/show_bug.cgi?id=745973
Allow renegotiation to happen when buffers have returned after an allocation
query. As the allocation query is serialized, all buffers from the pool
should have returned and we can stop it to create a new one for the
new format
https://bugzilla.gnome.org/show_bug.cgi?id=682770
Previously we advanced the in_data pointer by bps for every channel, and then
later again for block_size*bps. This caused us to be one sample further than
expected if an input buffer covered two analysis frames. And in the end lead
to completely bogus values reported by level.
https://bugzilla.gnome.org/show_bug.cgi?id=746065
These are outside the expected range of sequence numbers and should be
clipped, especially for RTSP they might belong to packets from before a seek
or a previous stream in general.
For output device, we should not update the buffer with flags and
timestamp when we dequeue. The information in the v4l2_buffer is not
meaningful and it breaks the case where the buffer is rendered at
multiple places.
https://bugzilla.gnome.org/show_bug.cgi?id=745438
We need to set up the transport in any case, not just if we have a container
stream or a non-interleaved stream. Only if we have an interleaved stream and
are retrying, we should not set up the stream again.
https://bugzilla.gnome.org/show_bug.cgi?id=745599
Otherwise we will get not-negotiated later from rtpbin, and will never be able
to send RTCP packets back to the server. Note that error flow returns from the
RTCP pads are ignored, that's why it didn't fail more visible before.
