[Bug 732908] audioresample skips samples unless input buffers have correct size

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Jul 10 09:21:19 PDT 2014


https://bugzilla.gnome.org/show_bug.cgi?id=732908
  GStreamer | gst-plugins-base | unspecified

--- Comment #7 from Kipp <kcannon at cita.utoronto.ca> 2014-07-10 16:21:16 UTC ---
(In reply to comment #6)
> Created an attachment (id=280192)
 View: https://bugzilla.gnome.org/attachment.cgi?id=280192
 Review: https://bugzilla.gnome.org/review?bug=732908&attachment=280192

> add sample count check
> 
> I don't know how to define a unit test to detect the problem fixed in this bug
> report, but this patch here at least adds a safety check that detects a
> mismatch between the input and output sample counts (accounting for latency and
> sample rate conversion).  there's no check that the contents of the samples are
> correct, but any dropping of input samples or double-counting of input samples
> will be detected by this.

So ... thinking about this some more, I'd be concerned that this check will
fail if the quality is changed mid stream.  Increasing the quality will
increase the latency and, eventually, this test will pass again but there might
be an intermediate period when the output appears to have generated more
samples than there should have been (because they were generated using the
earlier, shorter, kernel).

The problem with a unit test approach is that special buffer sizes are needed
to trigger the failure, so the test would have to involve "all" (however that
gets defined) buffer sizes.  Leaving an assert in the code to be tripped in the
wild is a more certain way to detect problems like this --- crowd-source the
unit test --- but it seems that even getting that right is difficult.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list