GNOME Bugzilla – Bug 580470
[audioresample] causes pipelines to go out of sync and becomes noticable after 10 minutes
Last modified: 2009-05-01 16:11:23 UTC
legacyresample is fine audioresample is fine if in passthrough This should be relatively easy to detect by comparing total audio duration of a long file say without audioresample in pipeline and with audioresample in file.
s/in file/in pipeline/
I'm running this pipeline: gst-launch audiotestsrc ! audio/x-raw-int,rate=48449 ! identity ! audioresample ! audio/x-raw-int,rate=44101 ! fakesink -v 2>&1 | grep offset After 10 minutes, they still look pretty in synch to me: /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 3728 bytes, timestamp: 10:24:47.818020364, duration: 0:00:00.021133307, offset: 1653250263, offset_end: 1653251195, flags: 0) 0xb7304298" /GstPipeline:pipeline0/GstIdentity:identity0: last-message = "chain ******* (identity0:sink)i (4096 bytes, timestamp: 10:24:47.839171087, duration: 0:00:00.021135627, offset: 1816248320, offset_end: 1816249344, flags: 0) 0xb73041a8" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 3728 bytes, timestamp: 10:24:47.839153671, duration: 0:00:00.021133307, offset: 1653251195, offset_end: 1653252127, flags: 0) 0xb73041f8" /GstPipeline:pipeline0/GstIdentity:identity0: last-message = "chain ******* (identity0:sink)i (4096 bytes, timestamp: 10:24:47.860306714, duration: 0:00:00.021135627, offset: 1816249344, offset_end: 1816250368, flags: 0) 0xb7304108" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 3728 bytes, timestamp: 10:24:47.860286978, duration: 0:00:00.021133307, offset: 1653252127, offset_end: 1653253059, flags: 0) 0xb7304158" /GstPipeline:pipeline0/GstIdentity:identity0: last-message = "chain ******* (identity0:sink)i (4096 bytes, timestamp: 10:24:47.881442341, duration: 0:00:00.021135627, offset: 1816250368, offset_end: 1816251392, flags: 0) 0xb7304068" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 3728 bytes, timestamp: 10:24:47.881420285, duration: 0:00:00.021133307, offset: 1653253059, offset_end: 1653253991, flags: 0) 0xb73040b8"
I get the same result with 0.10.22 and 0.10.22.1, and both audioresample and legacyresample, btw.
gst-launch -v filesrc location=~/videodemo-mpegts-disker.20090428-093332.ts ! mpegtsdemux ! mad ! audiorate ! identity ! audioresample ! audio/x-raw-int,rate=44100 ! fakesink 2>&1 | grep offset gave me after 10 or so mins: /GstPipeline:pipeline0/GstIdentity:identity0: last-message = "chain ******* (identity0:sink)i (9216 bytes, timestamp: 13:01:11.383000000, duration: 0:00:00.024000000, offset: 2249826384, offset_end: 2249827536, flags: 0) 0x9d7fe98" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 8464 bytes, timestamp: 13:01:11.129080933, duration: 0:00:00.023990929, offset: 2067016793, offset_end: 2067017851, flags: 0) 0x9d81a30" /GstPipeline:pipeline0/GstIdentity:identity0: last-message = "chain ******* (identity0:sink)i (9216 bytes, timestamp: 13:01:11.407000000, duration: 0:00:00.024000000, offset: 2249827536, offset_end: 2249828688, flags: 0) 0x9d92c58" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 8464 bytes, timestamp: 13:01:11.153071862, duration: 0:00:00.023990929, offset: 2067017851, offset_end: 2067018909, flags: 0) 0x9d818f0" /GstPipeline:pipeline0/GstIdentity:identity0: last-message = "chain ******* (identity0:sink)i (9216 bytes, timestamp: 13:01:11.431000000, duration: 0:00:00.024000000, offset: 2249828688, offset_end: 2249829840, flags: 0) 0x9d92000" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 8464 bytes, timestamp: 13:01:11.177062791, duration: 0:00:00.023990929, offset: 2067018909, offset_end: 2067019967, flags: 0) 0x9d7ff88" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 248 bytes, timestamp: 13:01:11.201053720, duration: 0:00:00.000702947, offset: 2067019967, offset_end: 2067019998, flags: 0) 0x9d91c70" input is an mpeg ts file with mpeg 1 layer 2 audio of 48000
with legacyresample: /GstPipeline:pipeline0/GstIdentity:identity0: last-message = "chain ******* (identity0:sink)i (9216 bytes, timestamp: 13:01:12.319000000, duration: 0:00:00.024000000, offset: 2249871312, offset_end: 2249872464, flags: 0) 0x8f3d378" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 8472 bytes, timestamp: 13:01:12.318820861, duration: 0:00:00.024013606, offset: 813501443249060, offset_end: 813501443250119, flags: 0) 0x8f21068" /GstPipeline:pipeline0/GstIdentity:identity0: last-message = "chain ******* (identity0:sink)i (9216 bytes, timestamp: 13:01:12.343000000, duration: 0:00:00.024000000, offset: 2249872464, offset_end: 2249873616, flags: 0) 0x8f1fb80" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 8464 bytes, timestamp: 13:01:12.342834467, duration: 0:00:00.023990929, offset: 813501443250119, offset_end: 813501443251177, flags: 0) 0x8f31338" /GstPipeline:pipeline0/GstIdentity:identity0: last-message = "chain ******* (identity0:sink)i (9216 bytes, timestamp: 13:01:12.367000000, duration: 0:00:00.024000000, offset: 2249873616, offset_end: 2249874768, flags: 0) 0x8f3d328" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < ( 8472 bytes, timestamp: 13:01:12.366825396, duration: 0:00:00.024013606, offset: 813501443251177, offset_end: 813501443252236, flags: 0) 0x8f21470"
Perhaps there are some discontinuities in your file from lost packets? Just trying to narrow down what we should be looking for in audioresample. I also note that the output from legacyresample has a completely different offset range calculated.
Ah, of course - I missed the audiorate, which ought to be compensating for any discontinuities.
The file I used in the pipeline is at: http://zaheer.merali.org/videodemo-mpegts-disker.20090428-093332.ts
Created attachment 133729 [details] [review] patch for audioresample drift Thanks for the test file. It looks like the problem is from losing samples when doing non-integral resample ratios - in this case 44100/48000. Attaching a patch that fixes this the same way legacyresample did - by always allocating the output buffer with space for an extra sample, and shrinking the GST_BUFFER_SIZE when it isn't used. I haven't been able to find any problems with this patch - and the rest of audioresample seems already set up to support it.
Er, the patch should not have that g_print in it, obviously
Created attachment 133732 [details] [review] better patch for audioresample drift Attaching a better patch, which doesn't have stray g_prints, but fixes the bug more nicely - the actual problem was that the existing rounding code for in transform_size could calculate buffer sizes that don't contain a complete frame of samples because it didn't include the channel count in its calculations. For example, when going 48khz->44.1khz with stereo 32bit samples, it would calculate that 9216 input bytes yields 8468 output bytes, which is 1058.5 output samples.
Fixed in git: commit 02a7b31f0e7a9e6630efe925696a9229423314aa Author: Jan Schmidt <thaytan@noraisin.net> Date: Fri May 1 16:47:53 2009 +0100 audioresample: Fix buffer size transformations When calculating the input/output buffer sizes in the transform_size functio take the number of channels into account, so we don't end up calculating a buffer size that only contains a partial number of audio frames. Also, when going from output size to input size, round down rather than up, so as to calculate the minimum number of samples that *might* yield a buffer of the intended destination size. Fixes: #580470 and #580952