Fix various issues with reverse playback by clearing tracking
vars when working in reverse, and where possible using the
timestamp interpolation code to generate timestamps for
outgoing buffers. Make sure to mark things as discontinuous
only when looping backward to a new position and fix seeking
to the next page when starting.
In gst_ogg_demux_do_seek() when calculating the
keyframe time, account for a non-zero start-time
Handle a discontinuous first packet in
gst_ogg_demux_setup_first_granule() because that's pretty
normal after a seek. Also differentiate between a genuinely
truncated first packet and just bailing out early, by not using
granule = -1 as an error code.
Make the debug output logs clearer about which timestamps
are stream times (PTS) and which are ogg timestamps.
If we can't find a valid granule near the end of the file, we
disable seeking. This guards against the whole file being then
read and never going to PLAYING.
https://bugzilla.gnome.org/show_bug.cgi?id=770314
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
This workaround tried to avoid an EOS event when seeking to the
end of an Ogg stream in order to find its duration. At some point,
an EOS event there would cause any queue2 upstream to pause and
not restart on a seek back to the beginning. This now appears to
not be the case anymore, and so the workaround can be removed.
https://bugzilla.gnome.org/show_bug.cgi?id=767689
If the duration is not known from the chain, it might be known
by the startup seek.
This fixes failure to seek.
Merged with a patch from Tim-Philipp Müller <tim@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=768991
Dropping a buffer because we have a seek pending is normal,
and will now happen when we trigger a seek while going through
the packets in a page. So this should not be an error.
A low bitrate stream which can pack more than 2 seconds of audio
in a page would cause the stream's position to be updated not
often enough, and would trigger a spurious "jump" via a GAP
event. Instead, we update the stream position after calculating
the new overall segment position.
https://bugzilla.gnome.org/show_bug.cgi?id=764966
... instead of relying on the segment. For the clipping at the start we assume
a proper value in the OpusHead, as generated by opusparse or opusenc.
Transmuxing in general is not guaranteed to produce the correct values, or
even have a OpusHead (e.g. when having RTP input).
https://bugzilla.gnome.org/show_bug.cgi?id=757153
The granulepos does not have the pre-skip subtracted while timestamps do,
and the last granulepos will be shorter by the number of samples that should
be dropped because of padding in the end.
As such, extrapolating the granule of the beginning of the first frame will
lead to a negative value, which is not a problem but intentional.
https://bugzilla.gnome.org/show_bug.cgi?id=757153
This reverts commit 76647f2710.
Avoiding pull mode activation is a feature regression, and
demuxers should always use pull mode where that is possible,
e.g. if there's an upstream queue2 with a ring buffer or
a download buffer.
This patch made reverse playback no longer possible over http.
If the goal is to minimise seeks, then that can still be done
by making the demuxer behave differently in pull mode if
the SEQUENTIAL flag is set. If there are bugs, like the demuxer
needlessly scanning the entire file on start-up in pull mode,
then those should be fixed instead.
https://bugzilla.gnome.org/show_bug.cgi?id=746010
gst_event_replace() takes its own reference on the event so we should drop
ours after creating and storing an event using it.
This fix leaks which can be reproduced using the
validate.http.media_check.vorbis_theora_1_ogg scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=748247
When a stream has a skeleton index, the stream time is taken from that
index. However, when part of the stream is captured, the index is
invalid as its offsets are now wrong. To avoid this, we ignore the index
when the last offset points beyond the end of the stream (when its
byte length is known).
https://bugzilla.gnome.org/show_bug.cgi?id=744070
oggmux keeps a cached buffer per pad, and pulls buffers from
collectpads to this cached buffer for all pads before processing
the best pad. In some cases, the move from collectpads buffer
to cached buffer is delayed till next call. However, when there
is only one pad, this can't be delayed till next call as there
will be a deadlock since collectpads has no other pad to push to.
https://bugzilla.gnome.org/show_bug.cgi?id=740565
gstoggdemux.c:1233:11: error: format specifies type 'long' but the argument has type 'ogg_int64_t' (aka 'long long') [-Werror,-Wformat]
granule);
^~~~~~~
https://bugzilla.gnome.org/show_bug.cgi?id=746512
The code that was calculating the start granule from packet durations
was interpreting a negative value as an error, but this is actually a
valid case, to indicate clipping of data at start.
https://bugzilla.gnome.org/show_bug.cgi?id=743900
If we get EOS when we're trying to build a chain, we disable seeking
and continue instead of posting an error. This can happen for corner
cases such as a stream with a video that stops before the end, for
instance.
https://bugzilla.gnome.org/show_bug.cgi?id=745980
When looking for pages when seeking, we stop looking for non sparse
streams if we don't find one within a given threshold. This fixes
seeking filling up queues and blocking in corner cases such as an
audio file with a pathological 1 frame video stream (yes, I saw one).
https://bugzilla.gnome.org/show_bug.cgi?id=745980
This will usually deadlock, despite this patch being in master for
quite some time and working fine. Nevertheless, we deem it to be
not working, disregarding facts.
As such, we fix it by keeping track of seek events, and sending
them upstream from a separate thread. Buffers are then discarded
till we get a new segment with the expected seqnum.
