GNOME Bugzilla – Bug 684538
baseparse: no timestamps after seeking in mp3 or aac
Last modified: 2012-10-05 09:18:42 UTC
Created attachment 224916 [details]
gzipped log file
When seeking in mp3s in totem I often get
GStreamer-CRITICAL **: gst_object_sync_values: assertion `GST_CLOCK_TIME_IS_VALID (timestamp)' failed
from the pitch element in totem. The underlying cause seems to be that the parser or decoder doesn't put timestamps on the first few buffers it pushes after a seek. Not sure where exactly the problem is, but seems to be barseparse or mpegaudioparse at first glance.
I should add that it only happens with some files (vbr?). I can make a file available on request if needed.
Also observed with aac, so probably a baseparse issue then.
I tried a few files I have with the playback test (VBR, non-VBR mp3 & AAC) and wasn't able to get the error. I don't have Totem for 1.0 built yet. Does it happen for you with the playback test?
I can reproduce the error with my own program. It is written in Python, so there is no need to compile it and it is small. You can grab it from:
Steps to reproduce it:
1. $ ./transcribe path/to/mp3
2. Press Play or 'p' or 'space'
3. Move the position slider
I can reproduce it with 1.0, but it works fine with 0.11.93.
Yes, I can reproduce it with the playback test as well:
-base/tests/examples/playback $ ./playback-test 1 'filesrc location=hzt.mp3 ! decodebin ! audioconvert ! pitch ! pulsesink'
I believe the pitch element here just makes the issue visible by posting warnings. Sometimes there's just silence after a seek, and then it only outputs sounds a few seconds later again, but I can only reproduce that with pitch in the pipeline, doesn't seem to happen if I remove it.
Will attach a sample.
Created attachment 225182 [details]
Author: Jan Schmidt <firstname.lastname@example.org>
Date: Wed Sep 26 14:23:52 2012 +1000
baseparse: Output timestamps after a seek.
Reinitialise the DTS after a seek so as to continue
generating timestamps when baseparse is not downstream
of a demuxer.
*** Bug 685524 has been marked as a duplicate of this bug. ***