After a CAPS event, in theory a new stream can start and it might start
with the FLAC headers again. We can't detect FLAC headers in the middle
of the stream, so we drain the parser to be able to detect either FLAC
headers after the CAPS event or the continuation of the previous stream.
This fixes for example
gst-launch-1.0 audiotestsrc num-buffers=200 ! flacenc ! c. \
audiotestsrc num-buffers=200 freq=880 ! flacenc ! c. \
concat name=c ! rtpgstpay ! udpsink host=127.0.0.1 port=5000
gst-launch-1.0 udpsrc multicast-group=127.0.0.1 port=5000 \
caps=application/x-rtp,media=application,clock-rate=90000,encoding-name=X-GST ! \
rtpgstdepay ! flacparse ! flacdec ! audioconvert ! pulsesin
gst_qt_mux_can_renegotiate () gets called everywhere following
that pattern:
return gst_qt_mux_can_renegotiate (ref(self));
This means the reference must be released both in the success
and failure cases, it was only done in the success case.
It can happen during teardown that the reference context becomes NULL.
In that case, trying to send the fragment-opened-closed message would
lead to a crash.
Corrupted files could potentially have multiple cdat/cdt2 atoms in
a sample entry, which is unclear how to handle.
Ignore repeated ones.
CID #1434162
CID #1434159
The code responsible for creating retransmitted buffers
assumed the stored buffer had been created with
rtp_buffer_new_allocate when copying the extension data,
which isn't necessarily the case, for example when
the rtp buffers come from a udpsrc.
https://bugzilla.gnome.org/show_bug.cgi?id=794958
Similar to the get-session and get-internal-session signals,
we expose a get-storage signal in addition to the
get-internal-storage signal to give access to the actual
element for applications that need to set properties on the
element, in particular "size-time"
https://bugzilla.gnome.org/show_bug.cgi?id=794910
With this the muxer is not set to NULL after each segment but instead
only flush events are sent to it to reset the EOS state.
As a result, the muxer will keep stream state and e.g. mpegtsmux will
keep the packet continuity counter continuous between segments as needed
by hlssink2.
https://bugzilla.gnome.org/show_bug.cgi?id=794816
The value stored in cenc_aux_sample_count wasn't in sync with the
parsing code that followed which checks whether all entries are
valid and present.
Only write the actual sample count when we know for sure.
CID #1427087
This exposes a new property, mtu, which is used to determine the
initial size of buffers from the buffer pool. If received data
exceeds this, the element gracefully handles that in a manner similar
to what we had previously: a large memory gets filled and reallocated
at the next call to "fill".
The default size is set to 1500, which should cover most use cases.
With contributions from Mathieu Duponchelle <mathieu@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772841
Optimize GstUdpSrc for cache performance.
Move the hot properties, which are used by the read function, to the top:
@used_socket, @addr, @cancellable, @skip_first_bytes, @timeout,
@retrieve_sender_address.
Remove the unused property @ttl.
Where needed reorder so that holes are avoided (the 64-bit @timeout)
https://bugzilla.gnome.org/show_bug.cgi?id=772841
The samples table is sorted by DTS, not PTS. As such we can only get the
correct result when using a binary search on it, if we search for the
DTS.
Also if we only ever search for the frame, where the following frame is
the first one with a PTS after the search position, we will generally
stop searching too early if frames are reordered.
In forwards playback this is not really a problem (after the decoder
reordered the frames, clipping is happening), in reverse playback
it means that we can output one or more frames too few as we stop too
early and the decoder would never receive it.
https://bugzilla.gnome.org/show_bug.cgi?id=782118
76e458a119 changed the conditions from
"queued > threshold" to "queued >= threshold", which broke hlssink2 and
resulting in too small fragments being created although keyframes would
be at *exactly* the configured threshold.
https://bugzilla.gnome.org/show_bug.cgi?id=794440
Fix compilation with MSVC. We still assume that attribute
is supported by all other relevant compilers, which seems
to be the case since we haven't had any complaints about
similar code in rtpsbcpay.
This works around a bug in various ONVIF cameras that implement the
attributes the wrong way around. They still won't work with a
backchannel but at least normal playback will work for the time being.
It restores pre-1.14 behaviour where we would fail to preroll on any SDP
that lists a recvonly stream. For 1.16 a better solution should be
found.
The problem here is that the ONVIF spec has the meaning of the two
attributes the wrong way around in the examples, compared to RFC4566.
https://bugzilla.gnome.org/show_bug.cgi?id=793715
Only up to timescale * G_MAXINT16 is possible as cluster duration, which
is already higher than our default value. Using higher values would
cause overflows and broken files.
Based on the investigation by Nicola Murino <nicola.murino@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792775
Matroska does not support changing the stream type and stream properties
after the headers were started to be written, and for example H264
codec_data changes can't be supported.
https://bugzilla.gnome.org/show_bug.cgi?id=782949
rtpulpfeccommon.c:432:27: error: format ‘%lx’ expects argument of type
‘long unsigned int’, but argument 10 has type ‘guint64 {aka long long unsigned int}’
https://bugzilla.gnome.org/show_bug.cgi?id=793732
The ulpfecenc "mux-seq" and "ssrc" properties were initially added
because the element did more than implement ULPFEC. As it was
decided that FLEXFEC would be implemented in a separate element,
both properties are now unneeded and confusing.
Change the default for the ulpfecenc multi-packet property,
as it is expected that most users of this element will be protecting video
streams.
Change the default property for the rtpredenc allow-no-red-blocks
property, as it should also be its default mode of operation.
https://bugzilla.gnome.org/show_bug.cgi?id=793843
It is expected that when connecting to a stream that has
already started, the caps will only arrive at the interval
specified on rtpgstpay, we shouldn't be warning as this is
a normal mode of operation.
https://bugzilla.gnome.org/show_bug.cgi?id=793798
We expose a set of new elements:
* ULPFEC encoder / decoder
* A storage element, which should be placed before jitterbuffers,
and is used to store packets in order to attempt reconstruction
after the jitterbuffer has sent PacketLost events
* RED encoder / decoder (RFC 2198), these are necessary to
use FEC in webrtc, as browsers will propose and expect ulpfec
packets to be wrapped in red packets
With contributions from:
Mathieu Duponchelle <mathieu@centricular.com>
Sebastian Dröge <sebastian@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792696
Packets with these payload types will be dropped. A use case
for this is FEC, where we want FEC packets to go through the
jitterbuffer, but not be output by rtpbin.
https://bugzilla.gnome.org/show_bug.cgi?id=792696
