Subject: [codec] FW: New Version Notification for draft-hoene-avt-rtp-sbc-03

From: "Christian Hoene" <[email-masked]>
Date: Tue, 16 Jun 2009 11:08:40 +0200

Dear all,

we have uploaded a new version of the RTP payload format for the Bluetooth SBC audio codec. SBC support mono and stereo audio coding supporting variable frame- and bit rates and having a very low complexity. It is part of the open-source BlueZ protocol stack for supporting Bluetooth device in Linux. To the best of our knowledge, its IPRs will expire in one year and then its usage will be license-free even for non-Bluetooth systems. 

Having these features, the SBC is can be considered as a candidate for the Internet Wideband Audio Codecs working group (CODEC BOF). While its audio quality does not reach the efficiency of CELT, its much complexity is lower.

Best regards,

 Christian Hoene

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Tuesday, June 16, 2009 10:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: New Version Notification for draft-hoene-avt-rtp-sbc-03 

A new version of I-D, draft-hoene-avt-rtp-sbc-03.txt has been successfuly submitted by Christian Hoene and posted to the IETF repository.

Filename:	 draft-hoene-avt-rtp-sbc
Revision:	 03
Title:		 RTP Payload Format for Bluetooth's SBC audio codec
Creation_date:	 2009-06-15
WG ID:		 Independent Submission
Number_of_pages: 23

Abstract:
This document specifies a Real-time Transport Protocol (RTP) payload 
format to be used for the low complexity subband codec (SBC), which 
is the mandatory audio codec of the Advanced Audio Distribution 
Profile (A2DP) Specification written by the Bluetooth(r) Special 
Interest Group (SIG). The payload format is designed to be able to 
interoperate with existing Bluetooth A2DP devices, to provide high 
streaming audio quality, interactive audio transmission over the 
internet, and ultra-low delay coding for jam sessions on the 
internet. This document contains also a media type registration which 
specifies the use of the RTP payload format.

The IETF Secretariat.

---

From: "Slava Borilin" <[email-masked]>
Date: Tue, 16 Jun 2009 22:28:09 +0400

Christian, 

Thanks, but the most important probably for IWAC (internet..codec) is
robustness for packet loss and similar techniques, which is not the
strong point afaik for SBC.

regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Christian Hoene
Sent: Tuesday, June 16, 2009 1:09 PM
To: [email-masked]; [email-masked]
Subject: [codec] FW: New Version Notification for
draft-hoene-avt-rtp-sbc-03

Dear all,

we have uploaded a new version of the RTP payload format for the
Bluetooth SBC audio codec. SBC support mono and stereo audio coding
supporting variable frame- and bit rates and having a very low
complexity. It is part of the open-source BlueZ protocol stack for
supporting Bluetooth device in Linux. To the best of our knowledge, its
IPRs will expire in one year and then its usage will be license-free
even for non-Bluetooth systems. 

Having these features, the SBC is can be considered as a candidate for
the Internet Wideband Audio Codecs working group (CODEC BOF). While its
audio quality does not reach the efficiency of CELT, its much complexity
is lower.

Best regards,

 Christian Hoene

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Tuesday, June 16, 2009 10:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: New Version Notification for draft-hoene-avt-rtp-sbc-03 

A new version of I-D, draft-hoene-avt-rtp-sbc-03.txt has been
successfuly submitted by Christian Hoene and posted to the IETF
repository.

Abstract:

The IETF Secretariat.

_______________________________________________
codec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/codec

---

From: "Dr. Christian Hoene" <[email-masked]>
Date: Tue, 16 Jun 2009 22:44:46 +0200

Hi Slava Borilin,

> strong point afaik for SBC.

We usually use SBC together with a PLC concealment based on G.711a1  
(extended to 48000). This combination works quite fine in case of  
packet losses because the SBC decoder does not de-synchronise.

Regards,

  Christian

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 16 Jun 2009 17:04:15 -0400

Hi Christian,

> packet losses because the SBC decoder does not de-synchronise.

If we look at CELT vs SBC specifically, CELT has the possibility to 
encode frames independently to increase loss robustness at a small cost 
in bit-rate. Even with independent frames, CELT still needs only half 
the bitrate to achieve the same quality as SBC, according to the results 
that you presented at the ITU workshop: 
http://net.cs.uni-tuebingen.de/html/ristore2net/publications/papers/hoene2008_itu.pdf 
. I would say that SBC's lower complexity isn't worth the 
quality/robustness cost, especially considering that CELT can do 
encoding+decoding with about 30 MHz on a Core2 and easily runs in 
real-time on just about any DSP.

Cheers,

    Jean-Marc