[gstreamer-bugs] [Bug 628609] The qtwrapperaudiodec_samr decoder doesn't handle buffers containing many AMR frames properly

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=628609
  GStreamer | gst-plugins-bad | 0.10.18

--- Comment #2 from Martin Storsjö <martin at martin.st> 2010-09-02 20:45:27 UTC ---
Created an attachment (id=169394)
 View: https://bugzilla.gnome.org/attachment.cgi?id=169394
 Review: https://bugzilla.gnome.org/review?bug=628609&attachment=169394

Patch solving this issue

The attached patch seems to solve the issue. The process_buffer_cb function is
called whenever SCAudioFillBuffer needs more data to decode, but even if all
input data is returned, SCAudioFillBuffer might  not consume all of it at once.
Once it has consumed all input data, and process_buffer_cb has no more data to
give, process_buffer_cb returns 42, which is returned from SCAudioFillBuffer as
status, indicating that all input data has been consumed.

Alternatively, another solution would be to increase the size of the buffer
allocated around lines 658-663:

  /* Create output bufferlist, big enough for 200ms of audio */
  GST_DEBUG_OBJECT (qtwrapper, "Allocating bufferlist for %d channels",
      channels);
  qtwrapper->bufferlist =
      AllocateAudioBufferList (channels,
      qtwrapper->samplerate / 5 * qtwrapper->channels * 4);

Although this seems to be meant to give a buffer size of 200 ms, I'm only able
to fill it with 100 ms of audio in practice in this test case. Nevertheless,
properly looping until all data has been consumed instead of increasing the
buffer size blindly feels more sensible to me.

-- 
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.