GNOME Bugzilla – Bug 588915
audioresample's output offset counter's initialization could maybe be improved
Last modified: 2009-07-28 18:52:23 UTC
audioresample initializes its output sample counter (for populating the output buffer offsets) by scaling the timestamp of the first input buffer by the input stream's sample rate. For streams whose timestamps are derived from some external absolute clock (e.g. security camera feeds, data from scientific instruments) and therefore don't start at 0, this results in the audioresample element generating output buffers with "crazy" offsets. I request that instead of scaling the timestamp of the first buffer by the sample rate, the ->next_offset field be initialized by scaling the offset of the burst buffer by the ratio of output to input sample rates. This reproduces the current behaviour for streams whose timestamps and offsets start at 0 but produces more useful buffer offsets in streams whose timestamps don't start at 0.
Created attachment 138644 [details] [review] initialize output offset counter by scaling first input offset
This only gives useful results if GST_BUFFER_OFFSET is actually set. The best might be to use the old behaviour if it's not set... or some kind of offset tracking to produce meaningful offsets if some/all are not set.
Created attachment 138655 [details] [review] fall back to using timestamp if input offset is invalid This version tries to initialize the output offset counter first by scaling the input buffer's offset, falling back to scaling the input buffer's timestamp if the offset is invalid, falling back to initializing the offset counter to 0 if the timestamp is invalid. Since the audiorate element is available to correct streams with poor timestamp <--> offset relationships, I don't think this element needs to be too fancy with respect to attempting to correct the timestamps and offsets of an input stream. However, one thing I have just noticed is that the output timestamps are computed as a cumulative sum of the output durations. That algorithm is prone to acumulating round-off errors, it would be better to compute the timestamps by scaling the output offset counter. But I think that is probably a separate bug-report.
I assume you wanted GST_CLOCK_TIME_TO_FRAMES() and not the other one ;) I'll commit this after 0.10.24 release. commit 02ce06037575bd090d75d65e643e24d912756317 Author: Kipp Cannon <kcannon@ligo.caltech.edu> Date: Tue Jul 28 20:50:06 2009 +0200 audioresample: Take the output offsets from the input if possible Fixes bug #588915.