After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 684538 - baseparse: no timestamps after seeking in mp3 or aac
baseparse: no timestamps after seeking in mp3 or aac
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal major
: 1.0.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 685524 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-09-21 10:42 UTC by Tim-Philipp Müller
Modified: 2012-10-05 09:18 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
gzipped log file (79.06 KB, application/octet-stream)
2012-09-21 10:42 UTC, Tim-Philipp Müller 		Details
684538.mp3 (800.00 KB, application/octet-stream)
2012-09-25 22:08 UTC, Tim-Philipp Müller 		Details

Description Tim-Philipp Müller 2012-09-21 10:42:55 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.

Log attached.
Comment 1 Tim-Philipp Müller 2012-09-21 10:50:05 UTC 
I should add that it only happens with some files (vbr?). I can make a file available on request if needed.
Comment 2 Tim-Philipp Müller 2012-09-21 19:04:42 UTC 
Also observed with aac, so probably a baseparse issue then.
Comment 3 Jan Schmidt 2012-09-25 20:56:40 UTC 
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?
Comment 4 Germán Poo-Caamaño 2012-09-25 21:25:53 UTC 
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:
https://www.gitorious.org/wasteland/small-transcript

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.
Comment 5 Tim-Philipp Müller 2012-09-25 22:07:03 UTC 
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.
Comment 6 Tim-Philipp Müller 2012-09-25 22:08:07 UTC 
Created attachment 225182 [details]
684538.mp3
Comment 7 Jan Schmidt 2012-09-26 08:20:56 UTC 
Fixed:

commit a663a4b9a0d29d58059601f0dfa7e08d9ae488f4
Author: Jan Schmidt <thaytan@noraisin.net>
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.
    
    Fixes: #684538
Comment 8 Tim-Philipp Müller 2012-10-05 09:18:42 UTC 
*** Bug 685524 has been marked as a duplicate of this bug. ***