After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 742446 - sbcparse: Frame coalescing broken for joint stereo
sbcparse: Frame coalescing broken for joint stereo
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.6.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-01-06 10:42 UTC by Tim Sheridan
Modified: 2016-01-16 22:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to fix the issue. (1.35 KB, patch)
2015-01-06 10:43 UTC, Tim Sheridan
reviewed Details | Review
Test vector (4 subbands) (128.18 KB, audio/x-sbc)
2015-01-06 15:24 UTC, Tim Sheridan
  Details
gst-plugins-good sbc frame length patch v2 (1.77 KB, patch)
2016-01-12 15:36 UTC, Tim Sheridan
committed Details | Review
gst-plugins-bad sbc frame length patch v2 (1.64 KB, patch)
2016-01-12 15:37 UTC, Tim Sheridan
committed Details | Review
SBC frame length comparison (for all configs) (4.20 KB, text/x-python)
2016-01-12 15:40 UTC, Tim Sheridan
  Details

Description Tim Sheridan 2015-01-06 10:42:37 UTC
sbcparse's frame coalescing is broken for joint stereo SBC streams. We only ever get frames from these streams out of sbcparse with one frame to a buffer.

There's a mistake in the SBC frame header size calculation (see the attached patch for a full explanation) that was introduced in the rewrite of the bluez code. Because of this, the frame coalescing code can't find the next frame where it expects it to be, and it gives up on coalescing the frame with any subsequent ones.
Comment 1 Tim Sheridan 2015-01-06 10:43:54 UTC
Created attachment 293911 [details] [review]
Patch to fix the issue.
Comment 2 Tim-Philipp Müller 2015-01-06 12:40:06 UTC
Thanks for the patch. Could you also make a few kB of such a stream available? You can run ... ! gdppay ! filesink location=sbc.gdp instead of feeding it into sbcparse.
Comment 3 Tim Sheridan 2015-01-06 15:24:00 UTC
Created attachment 293947 [details]
Test vector (4 subbands)
Comment 4 Tim Sheridan 2015-11-05 11:54:33 UTC
Any further details needed on this?
Comment 5 Tim-Philipp Müller 2015-11-19 10:36:03 UTC
Thanks for the patch, just one quick question: your new formula doesn't align with the formula given in the spec (12.9 Calculation of Bit Rate and Frame Length).

I would like to understand why this is the case, and I think it would be good to keep the code aligned with that formula.

Perhaps we should be doing the calculation in floating point and simply round up to the nearest byte, I guess we're truncating/rounding down now when there are extra bits, and that's why you're just adding another byte here?
Comment 6 Tim-Philipp Müller 2015-11-19 10:38:33 UTC
or just ROUND_UP_8 (blah) / 8
Comment 7 Tim Sheridan 2016-01-12 15:35:32 UTC
Thanks for reviewing the patch. You're right, the formula in the spec is correct, and rounding up corrects the problem. Patches to follow.
Comment 8 Tim Sheridan 2016-01-12 15:36:28 UTC
Created attachment 318887 [details] [review]
gst-plugins-good sbc frame length patch v2
Comment 9 Tim Sheridan 2016-01-12 15:37:00 UTC
Created attachment 318888 [details] [review]
gst-plugins-bad sbc frame length patch v2
Comment 10 Tim Sheridan 2016-01-12 15:40:28 UTC
Created attachment 318890 [details]
SBC frame length comparison (for all configs)

Here's a python script comparing the v2 patch's calculation against bluez's for all valid SBC parameters (it should give no output meaning they both agree on frame length).

If you uncomment the line with the XXX, then you'll get output for the SBC parameters for which gstreamer's current implementation and bluez disagree (affects both STEREO and JOINT configs).
Comment 11 Tim-Philipp Müller 2016-01-12 21:54:27 UTC
Thanks, pushed to master:

commit 95a14fd470e7b89a9a5e7476c03e710066ce2b46
Author: Tim Sheridan <tim.sheridan@imgtec.com>
Date:   Tue Jan 12 14:54:23 2016 +0000

    sbc: sbcdec: Fix frame length calculation
    
    SBC frame length calculation wasn't being rounded up to the nearest byte
    (as specified in the A2DP 1.0 specification, section 12.9). This could
    cause 'stereo' and 'joint stereo' mode SBC streams to have incorrectly
    calculated frame lengths.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=742446
commit 205565ccd9f93968265e76019426d9b048e2d3eb
Author: Tim Sheridan <tim.sheridan@imgtec.com>
Date:   Mon Jan 11 16:29:55 2016 +0000

    sbcparse: Fix frame length calculation
    
    SBC frame length calculation wasn't being rounded up to the nearest byte
    (as specified in the A2DP 1.0 specification, section 12.9). This could
    cause 'stereo' and 'joint stereo' mode SBC streams to have incorrectly
    calculated frame lengths.
    
    Incorrect frame length calculation causes frame coalescing to fail, as
    subsequent frames in the stream aren't found in the expected locations.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=742446
Comment 12 Tim-Philipp Müller 2016-01-16 22:22:20 UTC
Also cherry-picked into 1.6 branch (for 1.6.3)