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.
This is a followup commit to b95725c37e
* Resetting the decoder should only happen when we get a new initialization
header (0x01) and not on the other headers
* The initialized variable only gets set to TRUE once all headers have
been parsed. Also check if the vorbis_info struct has been properly resetted
also. Failure to do that would cause vorbisdec to error if it got
two initialization header in a row (the first would configure the underlying
library and the second one would error out because it's already initialized)
https://bugzilla.gnome.org/show_bug.cgi?id=779515
This fixes missing audio when we get buffers with zero
duration, denoting unknown duration. When several such
buffers are received in a row, they're all at the same
timestamp, with zero duration.
https://bugzilla.gnome.org/show_bug.cgi?id=771723
Always supply a buffer with max size to the decoder, as we
can't really decide how many samples will be in the lost packet
based on the timestamps we get.
https://bugzilla.gnome.org/show_bug.cgi?id=771723
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
This reverts commit a16cd5d2a5.
Setting the stop time on the segment breaks reconfiguration, as the
encoder signals an EOS, but we reconfigure it an continue to produce
buffers.
This information should not be required via the segment downstream
since we already have the sample count being used to generate buffer
durations.
https://bugzilla.gnome.org/show_bug.cgi?id=768763
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
