GNOME Bugzilla – Bug 548913
vorbisenc being picky about rounding errors in timestamps
Last modified: 2008-08-22 09:11:18 UTC
here you go slomo :) josch: if you want file a bug and assign it to me... it's vorbisenc that is too picky about rounding errors in timestamps, i'll fix that tomorrow but a bug as reminder is always good ;)
steps to reproduce: wget http://www.matroska.org/samples/mewmew/downloads/mewmew-vorbis-ssa.mkv this pipeline http://phpfi.com/345897 will produce audio errors
Ok the timestamps of the vorbis audio in this particular matroska file are far too inaccurate. The duration you can calculate from them for every vorbis frame is about 16.5ms while in reality every vorbis frame has a duration of about 21.3ms. The audiosink fixes this somehow but vorbisenc just drops every second buffer because it arrives with a timestamp before the previous timestamp+duration. Also the Matroska guys said that this file was created by a broken tool long ago ;) The best thing that can be done about this without breaking other things is: 2008-08-22 Sebastian Dröge <sebastian.droege@collabora.co.uk> * ext/vorbis/vorbisenc.c: (gst_vorbis_enc_chain): If a buffer arrives with a timestamp before the timestamp+duration of the previous buffer clip it instead of dropping it completely. Slight improvement for the unfixable bug #548913.
I'm beginning to think that we should try to generate sensible timestamps in the decoders (demuxers for raw audio) instead of having all the patchup logic in the audiosink, where it's only useful for playback but not transcoding. I don't really want to implement this in every decoder but it's something to remember for our decoder base class. Also we need some idea about what kind of rounding errors we want to allow and correct for, it's currently a bit arbitrary in the audiosinks (0.5 seconds of drift is allowed).