We would queue 5 consective packets before considering a reset and a proper
discont here. Instead of expecting the next output packet to have the current
seqnum (i.e. the fifth), expect it to have the first seqnum. Otherwise we're
going to drop all queued up packets.
When working in push-mode, we attempt to push out everything currently
buffered in the adapter.
This has two pitfalls:
* We could stop earlier (the moment we get a non-ok or non-not-linked)
* We return the last combined flow return, which might be completely
different from the previous combined flow return
There might be multiple LOAS config in a row in a full frame. The first
one might be a multi-layer config (which we can't properly parse yet)...
but then followed by a valid (single-layer) one.
The code was previously skipping whole frames (instead of just the LOAS
config we failed to read) resulting in multiple frames (seen up to 6s in
some situation) being dropped before finally getting the configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=758826
auds.blockalign is set once the first caps arrive. If
gst_avi_mux_stop_file() is called before this happens then auds.blockalign
is zero and gst_avi_mux_audsink_set_fields() cause a crash:
[...]
avipad->parent.hdr.rate = avipad->auds.av_bps / avipad->auds.blockalign;
[...]
https://bugzilla.gnome.org/show_bug.cgi?id=758912
It's not enough to have timeout or event based SPS/PPS information sent
in RTP packets. There are some scenarios when key frames may appear
more frequently than once a second, in which case the minimum timeout
for "config-interval" of 1 second for sending SPS/PPS is not sufficient.
It might also be desirable in general to make sure the SPS/PPS is
available with every keyframe (packet loss aside), so receivers can
actually pick up decoding immediately from the first keyframe if
SPS/PPS is not signaled out of band.
This patch adds the possibility to send SPS/PPS with every key frame. This
mode can be enabled by setting "config-interval" property to -1. In this
case the payloader will add SPS and PPS before every key (IDR) frame.
https://bugzilla.gnome.org/show_bug.cgi?id=757892
This way we can use -1 as special value, which is nicer than MAXUINT.
This is backwards compatible even with the GValue API, as shown by
a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=757892
generate_rtcp can produce empty packets when reduced size RTCP is turned on.
Skip them since it doesn't make sense to push them and they cause errors with
elements that expect RTCP packets to contain data (like srtpenc).
When seeking back to restore the mdat position a flush is pushed
through and it resets downstream segment information. Make sure
that after the flush (that does a soft reset) a segment will
be pushed again
Fixes regressions spotted at
https://ci.gstreamer.net/job/GStreamer-master-validate/2100/
10 FourCCs generated with GST_MAKE_FOURCC() in gstqtmux.c and atoms.c
already exist in fourcc.h. Don't duplicate these and use them directly.
Plus moving 6 to fourcc.h, to centralize them all.
This fixes seeking if the first entries in the samples table are negative. The
binary search would always fail on this as the array would not be sorted if
interpreting the negative numbers as huge positive numbers. This caused us to
always output buffers from the beginning after a seek instead of close to the
seek position.
Also add a case to the comparison function for equality.
Actual code is checking for a NULL terminator and a ';' terminator,
for backward compat, in a chained way that cause all events being rejected.
The proper condition is to reject the events when terminator isn't
in ['\0', ';'] set.
https://bugzilla.gnome.org/show_bug.cgi?id=758151
It would be unusual to have the header segment with an 'edts' atom
indicating gaps at the beginning when handling fragmented streams.
The header usually doesn't contain any timestamping information, this
should come from the playlist/manifest and the segments with media
in those scenarios.
https://bugzilla.gnome.org/show_bug.cgi?id=758171
On POSIX, IP_MULTICAST_LOOP is a setting for the sender socket. On Windows it
is a setting for the receiver socket. As such we will need it on udpsrc too to
allow filtering out our own multicast packets.
In push-mode it is hard to support qt segments overall but it is
possible to support when the file isn't heavily edited but just contain
a segment to indicate a gap at the beginning. This also allows properly
timestamping data that has negative DTS in push-mode.
It is relevant to support those for 2 scenarios:
1) fragmented streaming
2) HTTP playback of 'regular' mp4
https://bugzilla.gnome.org/show_bug.cgi?id=753484
No need to use G_GINT64_FORMAT for potentially negative values of
GstClockTimeDiff. Since 1.6 these can be handled with GST_STIME_ARGS.
Plus it creates more readable values in the logs.
https://bugzilla.gnome.org/show_bug.cgi?id=757480
For the MS/VfW codec ids, we want to write DTS timestamps instead
of PTS because that's what everyone else seems to do (and it's also
how it is in AVI). So for those input formats we use the buffer DTS
instead of the PTS. However, if there's no DTS set but only the PTS
then just take the PTS instead of dropping the input buffer. This
is useful especially for I-frame only codecs like JPEG and huffyuv,
but should also be fine as fallback in general.
Fixes regression with input JPEG frames that only have PTS set on them.
https://bugzilla.gnome.org/show_bug.cgi?id=756967
Instead, delay it until all request pads have been released. This is
because the release_pad() vfunc requires the multiqueue and muxer to
be there in order to release their request pads as well. If those
elements are destroyed earlier, release_pad() does not work, no
pads are released and some resources are leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=753622
We have to reverse all samples in a buffer before processing them to properly
have continuous data from one buffer to another. As a result we will have a
negative applied rate and a rate of 1.0.
Also make sure that input buffers are correctly clipped to the segment,
otherwise our calculations are going to go wrong.
Also copy over the segment event's sequence number to the output segment while
we're at it.
https://bugzilla.gnome.org/show_bug.cgi?id=757033
Implement accept-caps handler to avoid doing a full caps query
downstream to handle it.
This commit implements accept-caps as a simplification of the _getcaps
function, so it exposes the same limitations that getcaps would.
For example, not accepting renegotiation to caps with capsfeatures when
it was last configured to a caps that it has to deinterlace.
If the QtDemuxStream are re-used they may already have caps which used
to be leaked.
Reproduced using the
validate.dash.playback.seek_forward.dash_exMPD_BIP_TC1 validate
scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=756561
Negotiation to audio/x-raw,format=S8 was not possible because S8 does
not have a bit order so we ended up doing `if (!entry.fourcc) goto refuse_caps;`
https://bugzilla.gnome.org/show_bug.cgi?id=756387
They now use the new GstAudioVisualizer base class
from gst-plugins-base/gst-libs/gst/pbutils
Also fixed undefined reference to gst_audio_visualizer_get_type
Added GST_PLUGINS_BASE_LIBS to Makefile.am and re-order LIBADD.
https://bugzilla.gnome.org/show_bug.cgi?id=742875
Add statitics from each rtp source to the rtp session property.
'source-stats' is a GValueArray where each element is a GstStructure of
stats for one rtp source.
The availability of new stats is signaled via g_object_notify.
https://bugzilla.gnome.org/show_bug.cgi?id=752669
