GNOME Bugzilla – Bug 707230
flacparse: disregards container timestamps
Last modified: 2013-11-26 11:41:20 UTC
flacparse seems to always set absolute timestamps from sample number, even if the buffer is already timestamped.
Also could someone explain this code?
GST_BUFFER_OFFSET (buffer) =
gst_util_uint64_scale (GST_BUFFER_OFFSET_END (buffer), GST_SECOND,
GST_BUFFER_DURATION (buffer) =
GST_BUFFER_OFFSET (buffer) - GST_BUFFER_TIMESTAMP (buffer);
Yes that indeed looks wrong. It should only do these calculations if upstream does not provide timestamps (or does not send a segment in TIME format), otherwise it should use the upstream timestamps and optionally interpolate between them.
Want to provide a patch?
The OFFSET/OFFSET_END calculation is there for the Ogg granulepos :) It's unfortunately historically stored in these fields.
It's wrong in wavpackparse too
I have some other things to fix first, after that I can look at this.
I think this might be little more complicated than just a check for upstream timestamps, because if there are only some upstream timestamps the parser should probably fill the empty ones, but relative to provided timestamps, right?
You would think baseparse handles this already..
Does it? If so what does it need, is it enough to set valid duration on buffer?
The code seems to do something like that with the duration, yes.
Following commit should have baseparse enforce some nice behaviour wrt upstream timestamps:
Author: Mark Nauwelaerts <email@example.com>
Date: Sat Nov 16 15:17:57 2013 +0100
baseparse: ensure to preserve upstream timestamps
... rather than have subclass coming up with an internally parsed one.