From: Bas Vermeulen <Bas.Vermeulen@novero.com>
To: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: [PATCH] Re: Bug in sbc decoder gstreamer plugin
Date: Fri, 4 Dec 2009 12:28:42 +0100 [thread overview]
Message-ID: <4B18F26A.2080501@novero.com> (raw)
In-Reply-To: <4B18E581.6070305@novero.com>
[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]
Bas Vermeulen wrote:
> We've run into a problem with the gstreamer sbcdec plugin, where a
> pipeline would accumulate memory at the rate of data sent into it. This
> is caused by invalid data in a packet (incomplete or wrong data in the
> stream), causing sbc_decode to return -2 (sbc_unpack_frame can't find
> the SBC_SYNCWORD in data[0]).
> The sbcdec plugin handles this by putting away the buffer, and trying
> again when a new buffer comes in. Since the buffer isn't changed (only
> new data tacked on), sbc_decode will continue to send the -2 response
> from sbc_unpack_frame function, and the sbcdec plugin will continue to
> accumulate data into the buffer it is working on.
>
> The fix is to simply drop a buffer when sbc_decode returns -2.
>
I just realised this doesn't do enough, as sbc_decode can return
negative values in the range of -1 to -4 (-1 being need more data, the
rest being can't handle this frame for various reasons).
I've included a new version of the patch, which handles a -1 return
value by keeping the buffer for the next decode, and the other values by
dropping the buffer. This should also fix similar errors in case we get
a bad CRC or a faulty packet.
Regards,
Bas Vermeulen
--
novero gmbh | parsevalstr. 7 a | 40468 düsseldorf | germany |
amtsgericht düsseldorf | hrb 58283 | umsatzsteueridentifikationsnummer:
de 814973142 | geschäftsführender gesellschafter: razvan olosu
[-- Attachment #2: bluez-gstsbcdec-try2.patch --]
[-- Type: text/plain, Size: 810 bytes --]
--- /usr/src/nokia/mms_p2430-mute/mms_p2430/src/plugins/audio/decoder/gstrtpsbc/src/gstsbcdec.c 2009-12-01 11:32:45.000000000 +0100
+++ gstsbcdec.c 2009-12-04 12:23:04.000000000 +0100
@@ -95,7 +95,18 @@
GST_BUFFER_DATA(output), codesize,
NULL);
if (consumed <= 0)
- break;
+ {
+ /*
+ * sbc_decode returns -1 when not enough data is available to process.
+ * If that is the case, we need to tack on another buffer.
+ * In case of other errors (crc failure, SBC_SYNCWORD not found, etc),
+ * keeping the offending data does no good, as we will keep getting the
+ * same error over and over. So just free the buffer by jumping to done.
+ */
+ if (-1 == consumed)
+ break;
+ goto done;
+ }
/* we will reuse the same caps object */
if (dec->outcaps == NULL) {
prev parent reply other threads:[~2009-12-04 11:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-04 10:33 Bug in sbc decoder gstreamer plugin Bas Vermeulen
2009-12-04 11:28 ` Bas Vermeulen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B18F26A.2080501@novero.com \
--to=bas.vermeulen@novero.com \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.