Subject: Re: [codec] Broadcom submits BroadVoice codecs and offers its patent rights and C source codes of BV16/BV32 royalty free

From: "Raymond (Juin-Hwey) Chen" <[email-masked]>
Date: Tue, 10 Nov 2009 19:09:30 -0800

All,

As a follow-up of my previous email below, I would like to bring to everyone's attention that Broadcom today issued a news release that formally announced that Broadcom is offering open source BroadVoice C code royalty-free and without licensing fees. See, for example,
http://finance.yahoo.com/news/Broadcom-Offers-RoyaltyFree-prnews-2935046185.html?x=0&.v=1 . 
The open source BroadVoice C code is licensed under the GNU Lesser General Public License (LGPL), version 2.1, as published by the Free Software Foundation.

As of now, the open source floating-point and fixed-point C code for both BroadVoice16 and BroadVoice32 can be freely downloaded from 
http://www.broadcom.com/broadvoice .

This fulfills our previous promise in the email below to make BroadVoice16/BroadVoice32 C code "open source" (since "open source" is a desirable feature of candidate codecs for the Internet Wideband Audio Codec).

Thanks.

Raymond 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Raymond (Juin-Hwey) Chen
Sent: Wednesday, July 29, 2009 2:12 PM
To: [email-masked]
Subject: [codec] Broadcom submits BroadVoice codecs and offers its patent rights and C source codes of BV16/BV32 royalty free

All,

If the IETF codec WG is formed, Broadcom Corporation would like to submit its family of BroadVoice®16 (BV16) and BroadVoice32 (BV32) standard codecs to the IETF codec WG for consideration as a candidate codec or a candidate building block for the proposed Internet Wideband Audio Codec (IWAC) standard.  Currently Broadcom is already offering its patent rights, floating-point C source codes, and fixed-point C source codes of BV16/BV32 on a royalty-free basis, and Broadcom is even willing to make BV16/BV32 open source.

A little background on BV16/BV32.

BV16 and BV32 have been standardized by multiple standard organizations for VoIP applications in cable telephony.  BV16 is a 16 kb/s codec for 8 kHz narrowband signals; it is a standard codec in the following standards: PacketCableT 1.5, PacketCable 2.0, ANSI/SCTE 24-21 2006, and ITU-T Recommendation J.161.   Similarly, BV32 is a 32 kb/s codec for 16 kHz wideband signals, and it is a standard codec in PacketCable 2.0, ANSI/SCTE 24-23 2007, and ITU-T Recommendation J.361.  The RTP payload formats for BV16 and BV32 are specified in RFC4298.  BV16 and BV32 belong to the same family of codecs.  They have very similar codec structures and share most of the algorithm modules, so if the two are implemented together, substantial code sharing and memory reduction can be achieved.

Broadcom developed BV16 and BV32 from the ground up with a goal of avoiding known third-party intellectual property rights (IPR).  Although it was correctly pointed out earlier in the IETF codec WG email discussion that no one can be absolutely sure that a given codec is completely free of third-party IPR, we took two steps to help increase our confidence.  First, to help avoid the codec IPR minefield, we purposely avoided the popular and heavily-patented CELP coding paradigm, and instead took an "ancient art" (circa. 1954) technique of noise feedback coding (NFC) that nobody seemed to be interested in (i.e., it was the subject of very few recent publications) and improved it to get BV16/BV32.  Any patent on the fundamental NFC presumably expired long ago.  Second, several extensive patent searches were performed during the development of BV16/BV32 to help avoid third-party IPR.  To the best of our knowledge, BV16 and BV32 do not infringe on any valid unexpired third-party patent claim.  

BV16 and BV32 were also designed from the ground up to be optimized for voice transmission over IP networks, with high speech quality, low latency, low complexity, and high robustness to packet loss as primary design goals.  Thus, BV16 and BV32 are ideally suited for low-latency, high-quality voice transmission over the Internet.  The following summarizes the attributes of BV16 and BV32:

.	Low Delay (Latency): algorithmic buffering delay of merely 5 ms (compared with 15 to 40 ms of competing codecs)
.	Low Complexity: much lower MIPS requirements than most competing codecs (typically ½ to 1/3 of comparable ITU-T G.72x codecs), also lower memory requirement than most other competing codecs
.	High Quality: equivalent or better speech quality than competing codecs in extensive formal subjective MOS listening tests conducted by AT&T Labs, COMSAT Labs, and Dynastat, Inc.
.	Availability: Broadcom is offering its patent rights, floating-point and fixed-point C source codes of BV16/BV32 on a royalty-free basis; BV16/BV32 to become open source soon.

For comprehensive comparisons between BV16/BV32 and other codecs, please see the codec comparison tables in Annexes C and D (pages 73 - 81) of the PacketCable 2.0 Codec and Media Specification, available at:

http://www.packetcable.com/downloads/specs/PKT-SP-CODEC-MEDIA-I02-061013.pdf

Broadcom believes that as compared to the other nearly two dozen dominant codecs listed there, BV16 and BV32 offer the most compelling combinations of low delay, low complexity, high quality, moderate bit-rate, and royalty-free patent rights and C source codes.  The algorithm descriptions of BV16 and BV32 can be found in the two ANSI/SCTE standard documents below:
http://www.scte.org/documents/pdf/Standards/ANSISCTE24212006.pdf
http://www.scte.org/documents/pdf/Standards/ANSI_SCTE24-232007.pdf

It seems clear from the previous email discussion in the IETF codec WG reflector that voice transmission over the Internet is the primary application of the proposed IWAC, although transmitting general audio (music, etc.) at high fidelity is also desirable/necessary. It is also clear from the emails that royalty-free, low latency, and high quality are all highly desirable.  Given what was described above about BV16/BV32, it would seem that BV16/BV32 is an ideal candidate and is sufficient to cover the narrowband (8 kHz) and wideband (16 kHz) voice transmission aspects of the applications of IWAC.  To get higher sampling rates and higher audio bandwidths, it is possible to use BV16 and BV32 as the base layers and add additional bits on top of the BV16/BV32 bit-streams to encode an appropriately formulated difference signal to get a scalable, embedded codec that goes from 8 kHz sampling at 16 kb/s all the way to 48 kHz sampling at a much higher bit-rate.  One advantage of doing so is that the resulting IWAC will be interoperable with the BV16/BV32 in the PacketCable, ANSI/SCTE, and ITU-T J.161/J.361 standards. This is similar to the relationship between ITU-T G.729.1 and G.729.

Juin-Hwey (Raymond) Chen
Broadcom Corporation

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

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Tue, 10 Nov 2009 22:41:08 -0500

Raymond (Juin-Hwey) Chen wrote:
> Broadcom today issued a news release that formally announced that Broadcom is offering open source BroadVoice C code royalty-free and without licensing fees.

Thank you, and congratulations!  This will make the rest of our codec
development process even more exciting.  Today, Broadcom is leading by
example.

- --Ben Schwartz

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 11 Nov 2009 14:30:58 +0900

> development process even more exciting.  Today, Broadcom is leading by

Well, not to diminish Broadcom's very welcome efforts, they are actually
second to the party, since CELT was already open source quite some time
ago :-)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Eric Burger <[email-masked]>
Date: Wed, 11 Nov 2009 15:33:46 +0900

When you submit your Internet Draft, when the time comes, please do  
not forget to submit the IPR declaration, indicating Royalty Free, too.

This is a note for everyone that wishes to submit their IPR.

BTW, you can tell your lawyers not to fret - most declarations are of  
the form, "If accepted and incorporated into a standards track RFC."  
That means that you can retain your rights up to the point of  
publication. At that point we welcome your gift of IPR and change  
control.

On Nov 11, 2009, at 12:09 PM, Raymond (Juin-Hwey) Chen wrote:

> All,
>
> As a follow-up of my previous email below, I would like to bring to  
> everyone's attention that Broadcom today issued a news release that  
> formally announced that Broadcom is offering open source BroadVoice  
> C code royalty-free and without licensing fees. See, for example,
> The open source BroadVoice C code is licensed under the GNU Lesser  
> General Public License (LGPL), version 2.1, as published by the Free  
> Software Foundation.
>
> As of now, the open source floating-point and fixed-point C code for  
> both BroadVoice16 and BroadVoice32 can be freely downloaded from
> This fulfills our previous promise in the email below to make  
> BroadVoice16/BroadVoice32 C code "open source" (since "open source"  
> is a desirable feature of candidate codecs for the Internet Wideband  
> Audio Codec).
>
> Thanks.
>
> Raymond
>
> Subject: [codec] Broadcom submits BroadVoice codecs and offers its  
> patent rights and C source codes of BV16/BV32 royalty free
>
> All,
>
> If the IETF codec WG is formed, Broadcom Corporation would like to  
> submit its family of BroadVoice®16 (BV16) and BroadVoice32 (BV32)  
> standard codecs to the IETF codec WG for consideration as a  
> candidate codec or a candidate building block for the proposed  
> Internet Wideband Audio Codec (IWAC) standard.  Currently Broadcom  
> is already offering its patent rights, floating-point C source  
> codes, and fixed-point C source codes of BV16/BV32 on a royalty-free  
> basis, and Broadcom is even willing to make BV16/BV32 open source.
>
> BV16 and BV32 have been standardized by multiple standard  
> organizations for VoIP applications in cable telephony.  BV16 is a  
> 16 kb/s codec for 8 kHz narrowband signals; it is a standard codec  
> in the following standards: PacketCableT 1.5, PacketCable 2.0, ANSI/ 
> SCTE 24-21 2006, and ITU-T Recommendation J.161.   Similarly, BV32  
> is a 32 kb/s codec for 16 kHz wideband signals, and it is a standard  
> codec in PacketCable 2.0, ANSI/SCTE 24-23 2007, and ITU-T  
> Recommendation J.361.  The RTP payload formats for BV16 and BV32 are  
> specified in RFC4298.  BV16 and BV32 belong to the same family of  
> codecs.  They have very similar codec structures and share most of  
> the algorithm modules, so if the two are implemented together,  
> substantial code sharing and memory reduction can be achieved.
>
> Broadcom developed BV16 and BV32 from the ground up with a goal of  
> avoiding known third-party intellectual property rights (IPR).   
> Although it was correctly pointed out earlier in the IETF codec WG  
> email discussion that no one can be absolutely sure that a given  
> codec is completely free of third-party IPR, we took two steps to  
> help increase our confidence.  First, to help avoid the codec IPR  
> minefield, we purposely avoided the popular and heavily-patented  
> CELP coding paradigm, and instead took an "ancient art" (circa.  
> 1954) technique of noise feedback coding (NFC) that nobody seemed to  
> be interested in (i.e., it was the subject of very few recent  
> publications) and improved it to get BV16/BV32.  Any patent on the  
> fundamental NFC presumably expired long ago.  Second, several  
> extensive patent searches were performed during the development of  
> BV16/BV32 to help avoid third-party IPR.  To the best of our  
> knowledge, BV16 and BV32 do not infringe on any valid unexpired  
> third-party patent claim.
>
> BV16 and BV32 were also designed from the ground up to be optimized  
> for voice transmission over IP networks, with high speech quality,  
> low latency, low complexity, and high robustness to packet loss as  
> primary design goals.  Thus, BV16 and BV32 are ideally suited for  
> low-latency, high-quality voice transmission over the Internet.  The  
> following summarizes the attributes of BV16 and BV32:
>
> .	Low Delay (Latency): algorithmic buffering delay of merely 5 ms  
> (compared with 15 to 40 ms of competing codecs)
> .	Low Complexity: much lower MIPS requirements than most competing  
> codecs (typically ½ to 1/3 of comparable ITU-T G.72x codecs), also  
> lower memory requirement than most other competing codecs
> .	High Quality: equivalent or better speech quality than competing  
> codecs in extensive formal subjective MOS listening tests conducted  
> by AT&T Labs, COMSAT Labs, and Dynastat, Inc.
> .	Availability: Broadcom is offering its patent rights, floating- 
> point and fixed-point C source codes of BV16/BV32 on a royalty-free  
> basis; BV16/BV32 to become open source soon.
>
> For comprehensive comparisons between BV16/BV32 and other codecs,  
> please see the codec comparison tables in Annexes C and D (pages 73  
> - 81) of the PacketCable 2.0 Codec and Media Specification,  
> available at:
>
> Broadcom believes that as compared to the other nearly two dozen  
> dominant codecs listed there, BV16 and BV32 offer the most  
> compelling combinations of low delay, low complexity, high quality,  
> moderate bit-rate, and royalty-free patent rights and C source  
> codes.  The algorithm descriptions of BV16 and BV32 can be found in  
> the two ANSI/SCTE standard documents below:
> It seems clear from the previous email discussion in the IETF codec  
> WG reflector that voice transmission over the Internet is the  
> primary application of the proposed IWAC, although transmitting  
> general audio (music, etc.) at high fidelity is also desirable/ 
> necessary. It is also clear from the emails that royalty-free, low  
> latency, and high quality are all highly desirable.  Given what was  
> described above about BV16/BV32, it would seem that BV16/BV32 is an  
> ideal candidate and is sufficient to cover the narrowband (8 kHz)  
> and wideband (16 kHz) voice transmission aspects of the applications  
> of IWAC.  To get higher sampling rates and higher audio bandwidths,  
> it is possible to use BV16 and BV32 as the base layers and add  
> additional bits on top of the BV16/BV32 bit-streams to encode an  
> appropriately formulated difference signal to get a scalable,  
> embedded codec that goes from 8 kHz sampling at 16 kb/s all the way  
> to 48 kHz sampling at a much higher bit-rate.  One advantage of  
> doing so is that the resulting IWAC will be interoperable with the  
> BV16/BV32 in the PacketCable, ANSI/SCTE, and ITU-T J.161/J.361  
> standards. This is similar to the relationship between ITU-T G.729.1  
> and G.729.
>
> Juin-Hwey (Raymond) Chen
> Broadcom Corporation
>
>
>

---

From: Brian West <[email-masked]>
Date: Fri, 13 Nov 2009 16:17:35 -0600

Raymond,
	I would like to thank Broadcom for their commitment to Open Source/ 
Royalty Free codecs.  Following up on this trend we have now commited  
mod_bv16 and mod_bv32 to the FreeSWITCH SVN Tree.  We have working  
autotooled/libtoolized floating point implementations which are  
downloaded and built static for these modules in FreeSWITCH.  If  
Broadcom would setup an SVN I would be happy to provide build systems  
for mac/linux for both floating and fixed point codecs.

On a sidenote.. x-lite's bv32 is busted and not workable so anyone  
doing any implementations please be warned it will NOT WORK.   
Hopefully someone from counterpath is paying attention.

Thanks,
Brian West
FreeSWITCH.org
PS: http://fisheye.freeswitch.org/changelog/FreeSWITCH/?cs=15464

---

From: Tzafrir Cohen <[email-masked]>
Date: Sat, 14 Nov 2009 11:08:13 +0200

On Fri, Nov 13, 2009 at 04:17:35PM -0600, Brian West wrote:
> On a sidenote.. x-lite's bv32 is busted and not workable so anyone doing 
> any implementations please be warned it will NOT WORK.  Hopefully someone 
> from counterpath is paying attention.
>
> Thanks,
> Brian West
> FreeSWITCH.org

That changeset is only the FreeSWITCH modules. 
You also ommited from there the test data and test driver (bv16/bv.c) .

After adding it, I see that the test fails:

+ cmp -s tv.bv16 ./tv.bv16.ref
+ checksum=1
+ cmp -s tv.bv16.raw ./tv.bv16.ref.raw
+ cmp -s tv.bv16.bfe10.raw ./tv.bv16.bfe10.ref.raw
+ checksum=2

This means that the first encoding test fails, and likewise is the last
encoding test. However encoding and decoding give the same reference
data (the second test that passed).

-- 
               Tzafrir Cohen
icq#16849755              jabber:[email-masked]
+972-50-7952406           mailto:[email-masked]
http://www.xorcom.com  iax:[email-masked]/tzafrir

---

From: Brian West <[email-masked]>
Date: Sat, 14 Nov 2009 05:10:43 -0600

I didn't include bv.c as its not needed to build a library nor did I  
include any test programs.  Mike Jerris is going to rework my build  
system and include fixed/float in addition to a few more things and we  
will push that back to broadcom once its complete.  I have compiled  
the two libs on linux and my mac without any errors.  In addition  
their seems to be some implementation confusion I'm working out with  
Broadcom right now.  From what I can tell everyone has done G.192  
bitpacking on the wire but thats not to RFC and the API for g.192 is  
for offline simulation purposes so seems everyone currently running  
BV16/BV32 might to be doing it wrong.... Feels a little like G726  
RFC3551 vs AAL2 coding snafu.  For offline testing you must define  
G192BITSTREAM=1 which is only referenced in bv.c and used for offline  
testing.  I suspect your tests would pass if you compiled the test  
program with that flag.

Broadcom says this "The G.192 bit-stream format is only for offline  
simulation purposes.  For something real you want the bit-stream  
packed according to RFC4298."

/b

On Nov 14, 2009, at 3:08 AM, Tzafrir Cohen wrote:

>> doing

---

From: Brian West <[email-masked]>
Date: Sat, 14 Nov 2009 05:22:23 -0600

Just a small update it seems its a 32bit vs 64bit issue... unsigned  
long bitword32; <-- LONG IS EVIL.

/b