GNOME Bugzilla – Bug 665004
audioresample emits spurious disconts
Last modified: 2011-11-28 17:16:11 UTC
Created attachment 202270 [details] [review] patch audioresample is derived from GstBaseTransform, and one of GstBaseTransform's traits is that if the derived element does not produce an output buffer from some input buffer then the first output buffer after that gets flaged as a discontinuity, whether or not the buffer actually is discontinuous from the output buffer that preceded it. When downsampling, the audioresample element requires more than one input sample for each output sample, and if the ratio of input to output sample rates is high enough and the input buffers short enough it can come to pass that the resampler does not receive enough samples on its input to produce any output. Currently the resampler returns GST_BASE_TRANSFORM_FLOW_DROPPED from the transform() method in this case, causing the next buffer to be flagged as a discontinuity. If subsequent elements in the pipeline reset themselves on disconts, this can cause clicks and other undesireable behaviour. The attached patch causes the resampler to return 0-length buffers from transform() method in this situation, instead of returning GST_BASE_TRANSFORM_FLOW_DROPPED. This "tricks" the parent class into believing the output stream is continuous, fixing the spurrious discont flags. git says the lines this patch removes were added in an earlier patch from me that fixed a timestamp drift ... so, I haven't checked to see what the element did originally, but there's a good chance I'm responsible for introducing the bug. Sorry about that. PS --- it would be great if this could make it into the upcoming release.
Please attach patches in "git format-patch" format in the future :) commit 4c52f4e625f910d6fba34d49fe06cfd1220c9c93 Author: Kipp Cannon <kcannon@cita.utoronto.ca> Date: Mon Nov 28 17:59:32 2011 +0100 audioresample: Don't emit DISCONT buffers if no discontinuity happened audioresample is derived from GstBaseTransform, and one of GstBaseTransform's traits is that if the derived element does not produce an output buffer from some input buffer then the first output buffer after that gets flaged as a discontinuity, whether or not the buffer actually is discontinuous from the output buffer that preceded it. When downsampling, the audioresample element requires more than one input sample for each output sample, and if the ratio of input to output sample rates is high enough and the input buffers short enough it can come to pass that the resampler does not receive enough samples on its input to produce any output. Currently the resampler returns GST_BASE_TRANSFORM_FLOW_DROPPED from the transform() method in this case, causing the next buffer to be flagged as a discontinuity. If subsequent elements in the pipeline reset themselves on disconts, this can cause clicks and other undesireable behaviour. Fixes bug #665004.