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
Buffer is added to the internal cache, and pushed only when accumulated
buffer duration crosses 200 ms. So when the chain ends, the buffer accumulated
is not freed. Freeing the cache when the state changes from PAUSED to READY.
https://bugzilla.gnome.org/show_bug.cgi?id=754212
By not doing this, the muxer is not effectively a rtpmuxer, rather a
funnel, since it should be a single stream that exists the muxer.
If not specified, take the first ssrc seen on a sinkpad, allowing upstream
to decide ssrc in "passthrough" with only one sinkpad.
Also, let downstream ssrc overrule internal configured one
We hence has the following order for determining the ssrc used by
rtpmux:
0. Suggestion from GstRTPCollision event
1. Downstream caps
2. ssrc-Property
3. (First) upstream caps containing ssrc
4. Randomly generated
https://bugzilla.gnome.org/show_bug.cgi?id=752694
If seeking targets an empty segment skip it as there is no media
offset to get from it. Instead look for the next one.
This doesn't make seeking in push-mode work if you seek to an
empty segment but at least won't get you to wrong offsets.
https://bugzilla.gnome.org/show_bug.cgi?id=753484
mux_start_time refers to the running_time of the buffer
that goes first in the output file. Normally this time is
0, so this variable is initialized to 0 during the state
change to PAUSED.
However, when dealing with dynamic pipelines and starting
a recording while the pipeline has already run for a while,
the running_time of the first buffer is > 0 and this causes
a problem with detecting the end of the first file(s) when
splitting by duration, because the code will later compare
the threshold_time with (last buffer running_time - mux_start_time)
and will get it wrong until mux_start_time advances enough
to make this difference < threshold_time, creating empty files
in the meantime.
https://bugzilla.gnome.org/show_bug.cgi?id=753624
During reverse playback, the media should stop playing at segment.start
This does not happen, and avidemux continues to process data even when
current timestamp is less that segment.start.
https://bugzilla.gnome.org/show_bug.cgi?id=755094
Avoid using default accept-caps handler that will query downstream
and is more expensive. Just check if the caps is compatible with
the template and check if the channels are the same.
