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
All received configurations are parsed and added to a list, this lead
to an unbounded memory usage. As the configuration is resent every
second this quickly lead to a large memory usage.
Add a check to only add the config if it is not already available in
the list. This fix only handle the typical case of a well behaved
stream, a malicious server could still send many useless
configurations to raise the client memory usage.
The smallest possible is 24 (and not 25) bytes.
The last "name" field can according to QTFF specifications not be present
at all. The parser will handle this fine and so will the rest of
the qtdemux code.
If codec_data is changed, the stream is no longer valid.
Rather than keeping running when refusing new caps,
this patch send a warning to the bus.
Also fix up splitmuxsink to ignore this warning while changing caps.
https://bugzilla.gnome.org/show_bug.cgi?id=790000
We would accidentally pass through the duration value from the
demuxer from a single fragment, which causes problems when
feeding the stream from splitmuxsrc to rtsp-server. Streaming
would stop after one fragment due to that.
https://bugzilla.gnome.org/show_bug.cgi?id=792861
total_duration is initialised to CLOCK_TIME_NONE, not 0, so check
for that as well in order not to return an invalid duration to
a duration query. Doesn't fix anything particular observed in
practice, just seemed inconsistent.
With this patch we can now provide a set of files
created by multifilesink as a source for uri elements.
e.g. gst-launch-1.0 playbin uri=multifile://img%25d.ppm
Note that for the %d pattern you need to replace % with %25.
This is to be compliant with URL naming standards.
https://bugzilla.gnome.org/show_bug.cgi?id=783581
It generally makes not much sense to configure it for all pads/traks at
once as this value is usually different for each of them. As such, add a
new property on the pads in addition to the existing property on the
whole muxer.
https://bugzilla.gnome.org/show_bug.cgi?id=792649
We can't handle recvonly streams, sendonly streams are perfectly fine.
The direction is the one from the point of view of the SDP offerer
(i.e. the RTSP server), and a recvonly stream would be one where the
server expects us to send media.
RFC 3264, section 5.1:
If the offerer wishes to only send media on a stream to its peer, it
MUST mark the stream as sendonly with the "a=sendonly" attribute.
This is mixed up in the ONVIF streaming specification examples, but
actual implementations and conformance tools seem to not care at all
about the attributes.
https://bugzilla.gnome.org/show_bug.cgi?id=792376
Raw AAC streams might have very small frames, e.g. 6 byte frames
when encoding silence. These frames are then smaller than aacparse's
default min_frame_size of 10 bytes (ADTS_MAX_SIZE).
When passthrough is disabled or aacparse has to output ADTS, GstBaseParse
will concatenate these short frames to the following frame before
handling them to aacparse, which processes each input buffer as a single
frame, producing bad output.
To avoid this problem, set the min_frame_size to 1 when receiving a raw
stream.
https://bugzilla.gnome.org/show_bug.cgi?id=792644
When the signal returns a floating reference, as its return type
is transfer full, we need to sink it ourselves before passing
it to gst_bin_add (which is transfer floating).
This allows us to unref it in bin_remove_element later on, and
thus to also release the reference we now own if the signal
returns a non-floating reference as well.
As we now still hold a reference to the element when removing it,
we also need to lock its state and setting it to NULL before
unreffing it
Also update the request_aux_sender test.
https://bugzilla.gnome.org/show_bug.cgi?id=792543
