Subject: [rtcweb] On video codec for rtcweb

From: Stefan Hakansson LK <[email-masked]>
Date: Fri, 23 Mar 2012 12:11:26 +0100

I think most agrees to that it would be advantageous if there could be 
an agreement on mandatory to implement codecs (at least one for audio 
and at least one for video), for interoperability between 
implementations (among other things).

I would like to discuss a bit on mandatory to implement video codec 
support. There are many factors to consider, three of them are:

1. Coding efficiency: As more and more of the available capacity on the 
Internet is consumed by video, I think that codecs that are clearly 
inferior to the state of art regarding compression efficiency should not 
be considered.

2. Implementation status: Another factor to consider is the 
implementation status in end user equipment, and, especially for battery 
powered devices, to what extend platforms have (optimized/HW 
accelerated) implementations.

3. Interoperability with existing services (it can be argued that webrtc 
is a green field, but on the other hand there seems to be a lot of 
people wanting interoperability).

To me, h.264 is a good candidate considering the factors above. It is 
competitive regarding compression efficiency, it is widely implemented 
(in all kinds of devices and platforms) and is the by far mostly used 
video codec currently. Notably, a recent study ([1]) says that h.264 is 
the leading format also for the html video element.

In addition, licensing for h.264 seems straightforward, and the large 
number of implementations in commercial use indicates that vendors do 
not perceive the risk for licensing/patent issues down the road as being 
unacceptable big (this is an observation from the outside; I'm not a 
lawyer and I don't deal with licensing).

So, I propose that h.264 should be mandatory to implement.

Stefan

[1] http://blog.mefeedia.com/html5-dec-2011

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 23 Mar 2012 04:40:40 -0700

> So, I propose that h.264 should be mandatory to implement.

Mozilla strongly opposes such a proposal. Many will be familiar with our 
announcements regarding our use of platform codecs on B2G and possibly 
Android last week. The primary reasoning behind that decision, i.e. the 
one factor that was not in our power to change, was the availability of 
content on websites. This is not a problem for WebRTC, as browsers 
control both ends of the communication.

What _is_ a problem is licensing and distributing encoders in an 
open-source project. This is quite a bit different than using system 
decoders, as outside of mobile, encoders are usually not available, and 
even if they were, they might not have particularly good quality, nor 
the features to control latency, loss robustness, and other aspects 
necessary for real-time communication.

If you thought that a concession in one place would make Mozilla more 
likely to compromise in others, I assure you the opposite is true. 
Maintaining the use of RF codecs in WebRTC is now even more important 
than it was before. See the words directly from Mozilla's CTO: 
http://groups.google.com/group/mozilla.dev.platform/msg/53892ad3ea9eeb98

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 23 Mar 2012 12:47:44 +0100

+1,

L.

Il giorno Fri, 23 Mar 2012 04:40:40 -0700
"Timothy B. Terriberry" <[email-masked]> ha scritto:

> Mozilla strongly opposes such a proposal. Many will be familiar with
> our announcements regarding our use of platform codecs on B2G and
> possibly Android last week. The primary reasoning behind that
> decision, i.e. the one factor that was not in our power to change,
> was the availability of content on websites. This is not a problem
> for WebRTC, as browsers control both ends of the communication.
> 
> decoders, as outside of mobile, encoders are usually not available,
> and even if they were, they might not have particularly good quality,
> nor the features to control latency, loss robustness, and other
> aspects necessary for real-time communication.
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: <[email-masked]>
Date: Fri, 23 Mar 2012 12:14:59 +0000

Hi,

Timothy B. Terriberry wrote:
>
>The primary reasoning behind that decision, i.e. the one
>factor that was not in our power to change, was the availability of content on
>websites. This is not a problem for WebRTC, as browsers control both ends of
>the communication.
>

In WebRTC context what is somewhat analogous is the interconnect to existing non-web video systems. What codecs are used in them is not under browser control. I believe those mostly use H.264. It's probably possible to use transcoders but so it is between browsers too. I'd say that even if couldn't mandate a single video codec (as it has seemed to me since the beginning), in practice H.264 support would be highly RECOMMENDED (a SHOULD). There might be good reasons not to follow that SHOULD, as it seems to be the case for Mozilla.  

Markus

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of ext Timothy B. Terriberry
>Sent: 23 March, 2012 13:41
>To: Stefan Hakansson LK
>Cc: [email-masked]
>Subject: Re: [rtcweb] On video codec for rtcweb
>
>Android last week. The primary reasoning behind that decision, i.e. the one
>factor that was not in our power to change, was the availability of content on
>websites. This is not a problem for WebRTC, as browsers control both ends of
>the communication.
>
>What _is_ a problem is licensing and distributing encoders in an open-source
>project. This is quite a bit different than using system decoders, as outside of
>mobile, encoders are usually not available, and even if they were, they might
>not have particularly good quality, nor the features to control latency, loss
>robustness, and other aspects necessary for real-time communication.
>
>If you thought that a concession in one place would make Mozilla more likely
>to compromise in others, I assure you the opposite is true.
>Maintaining the use of RF codecs in WebRTC is now even more important than
>it was before. See the words directly from Mozilla's CTO:

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 23 Mar 2012 05:34:09 -0700

[email-masked] wrote:
> control. I believe those mostly use H.264. It's probably possible to use
> transcoders but so it is between browsers too. I'd say that even if couldn't

With a direct browser-to-browser connection, there is nothing sitting 
between them to do the transcoding. In the DTLS-SRTP case with identity 
verification, which I think a number of people here view as highly 
important, you are in fact _guaranteeing_ that nothing but the browser 
can encode or decode the video.

As for existing non-web video systems, I am happy to send them G.711, 
and no more, if all they wish to support is H.264. To me, interoperation 
beyond that is no more than a "nice to have". WebRTC was meant to be 
much more expansive than traditional telephony. If all WebRTC turns out 
to be is another vehicle for old-world video conferencing style systems, 
then we will have failed.

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Fri, 23 Mar 2012 12:34:59 +0000

Let's be clear on profiles.  If we seek widest mobile hardware footprint:
- ITU-T H.264 Constrained Baseline Profile is probably the most ubiquitous hardware video codec today with reasonable power/performance ratio
- ITU-T G.711, both u_law (North America) and A_law (Europe) formats, can be supported by everyone with very trivial software burden
-chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 23, 2012 5:15 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [rtcweb] On video codec for rtcweb

Hi,

Markus

---

From: <[email-masked]>
Date: Fri, 23 Mar 2012 13:05:35 +0000

Hi

Timothy B. Terriberry wrote:
>> control. I believe those mostly use H.264. It's probably possible to
>> use transcoders but so it is between browsers too. I'd say that even
>> if couldn't
>
>verification, which I think a number of people here view as highly important,
>you are in fact _guaranteeing_ that nothing but the browser can encode or
>decode the video.
>

Understood. So it would be important to agree on a common codec. However, I'm just wondering if forcing the decision would be wise for the IETF. I have heard many people say that if X was chosen, they wouldn't still suport it. My opinion is that a codec should only be mandated if there is clear consensus about it. Exaggerating a bit but not much that would probably leave us with G.711.

>As for existing non-web video systems, I am happy to send them G.711, and
>no more, if all they wish to support is H.264. 

Indeed :-) That's fine, but for some other people video support in that scenario could be more important. 

>To me, interoperation beyond
>that is no more than a "nice to have". WebRTC was meant to be much more
>expansive than traditional telephony. If all WebRTC turns out to be is another
>vehicle for old-world video conferencing style systems, then we will have
>failed.
>

Here we are in full agreement. I don't think either that the "legacy" interconnect is the highest priority. I don't find the current video call market that impressive that we should somehow limit ourselves to serve it.

Markus

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Fri, 23 Mar 2012 09:24:39 -0400

> - ITU-T G.711, both u_law (North America) and A_law (Europe) formats, can be supported by everyone with very trivial software burden
Seeking the widest mobile hardware footprint is a very narrow view
considering the scope of WebRTC.  WebRTC is a technology with browsers
as the main endpoints.  While mobile devices make up a significant
portion of that population, they are by no means the only one, and there
are no guarantees that this will be the major use case of WebRTC in the
future.

Time and again, success and adoption of standards across all markets,
devices, and platforms has been rooted in the usage of a open,
royalty-free formats.  Mandating H.264 for this or any other purpose
while it remains unlicensable for usage in free/open source software
projects invalidates the universality of WebRTC.  This would setup the
protocol to be yet another proprietary system that claims to be open but
in practice will be limited to usage solely by existing MPEG-LA
licensors/licensees and other existing players in the telecommunications
market.  This makes the project, and the standard, dead in the water as
far as a lot of the players interested in this project are concerned.

Having said that, WebRTC at this point remains open and free, and to
ensure that, the only technologies that should be included are those
that are royalty free and licensed for use within free/open-source
software project.  This is the *only* way for WebRTC to be successful
and to achieve the goals of its (intended) open nature.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 23 Mar 2012 06:28:09 -0700

[email-masked] wrote:
 > My opinion is that a codec should only be mandated if there is clear
 > consensus about it. Exaggerating a bit but not much that would 
probably leave
 > us with G.711.

We've had this conversation on this list before. See
http://www.ietf.org/mail-archive/web/rtcweb/current/msg03047.html
wherein you find that even Stephan _Wenger_ and I managed to agree that 
your standard is too strong. Such consensus is a rare thing indeed.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 23 Mar 2012 07:24:53 -0700

> then we will have failed.

[BA]  While "old-world video conferencing" systems (H.323) are still widely used,
I think it is fair to say that there is a strong trend towards adoption of SIP in a 
wide range of markets, including government, educational, medical, financials, etc. 

I have talked to customers in many of those markets, and one of the consistently
repeated requests is for interoperability between mobile video and video
conferencing platforms, *without the need for transcoding*.   The reason why
transcoding is unacceptable is that the cost of transcoding gateways is high
on a per user basis, and for organizations where high use of video is anticipated,
the cost of transcoding (as opposed to a signaling gateway) is a major problem.   
Another frequently cited issue is the ability to use hardware encode/decode on mobile devices, so
as to save power.  In scenarios such as emergency services, this can literally be a
matter of life and death. 

Given that mobile devices and video conferencing systems overwhelmingly support 
H.264 encode/decode in hardware, and that we do not yet have general hardware support
for encode/decode operations, the answer to customer requests can only be provided by
H.264 at this time, or perhaps by H.265 (which is likely to be rapidly adopted once it is
ratified in early 2013).  

While I understand the reasons why browser vendors might not want to
include software implementations of encumbered codecs, so they can remain free to users, 
that logic does not extend to a refusal to rely on operating system or hardware
support, which would presumably come without cost to the browser vendors. 

My discussions with customers indicate that support for underlying encode/decode
capabilities is considered an important enough feature that it will cause those customers to
switch to browsers that support it.

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 23 Mar 2012 14:35:34 +0000

Timothy B. Terriberry:

"Mozilla strongly opposes such a proposal. Many will be familiar with our announcements regarding our use of platform codecs on B2G and possibly Android last week. The primary reasoning behind that decision, i.e. the one factor that was not in our power to change, was the availability of content on websites. This is not a problem for WebRTC, as browsers control both ends of the communication."

While I understand the reasons for disliking a codec that isn't available royalty-free, I have to say that the above argument is exactly backwards.

While a website that wished to offer content to two different browsers with different codecs could simply transcode and store the video in two formats (albeit at some cost in storage, which is getting cheaper all the time), a website that wishes to offer RTC capabilities to users with differing browsers would be forced to stand up servers, in-path, transcoding in real time... a much more onerous requirement in order to achieve interoperability.

While browsers "control both ends of the communication" in RTCWEB, the sites offering RTC services don't necessarily "control both ends of the communication" insofar as choosing what browsers their users use to visit... or rather, in order to achieve interoperable communication without the cost (and security concerns) of transcoding sites will in fact start to deny service to particular users based on their choice of browser.

Matthew Kaufman

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 23 Mar 2012 07:47:11 -0700

> support, which would presumably come without cost to the browser vendors.

Oh, but it does. My understanding is that even Windows 7 does not ship 
with a licensed encoder. Even if it did, nearly a plurality of Mozilla's 
users still run Windows XP. I would like those users to be able to talk 
to each other, and with mobile devices, and I view not supporting an 
encumbered codec as the best route to ensuring that support for a free 
one is deployed and working on all of these systems.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 23 Mar 2012 07:51:30 -0700

Matthew Kaufman wrote:
 > or rather, in order to achieve interoperable communication without 
the cost
 > (and security concerns) of transcoding sites will in fact start to deny
 > service to particular users based on their choice of browser.

I agree this is an excellent argument for having _a_ mandatory to 
implement codec. But it's an argument against having that codec be an 
encumbered codec. Much better to have it be a free one that everyone is 
able to deploy. Even Microsoft (via Skype) now deploys VP8.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 23 Mar 2012 07:51:11 -0700

the cost

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Mar 2012 08:21:58 -0700

On 23 March 2012 05:34, Timothy B. Terriberry <[email-masked]> wrote:
> important, you are in fact _guaranteeing_ that nothing but the browser can
> encode or decode the video.

This is incorrect.  The browser can implement the DTLS handshake and
crypto renegotiation, plus the SRTP shim.  It is possible for the
browser to perform the crypto without performing encode or decode if
the source is capable of providing RTP.  From RFC 3711:

   [...]  Conceptually, we consider SRTP to be a "bump in the stack"
   implementation which resides between the RTP application and the
   transport layer.  SRTP intercepts RTP packets and then forwards an
   equivalent SRTP packet on the sending side, and intercepts SRTP
   packets and passes an equivalent RTP packet up the stack on the
   receiving side.

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 23 Mar 2012 15:24:22 +0000

Timothy B. Terriberry:

> Matthew Kaufman wrote:
 > > or rather, in order to achieve interoperable communication without the cost  > (and security concerns) of transcoding sites will in fact start to deny  > service to particular users based on their choice of browser.

> I agree this is an excellent argument for having _a_ mandatory to implement codec. But it's an argument against having that codec be an encumbered codec. Much better to have it be a free one that everyone is able to deploy. Even Microsoft (via Skype) now deploys VP8.

I wasn't commenting on that part, just that if Mozilla is going to soften up on H.264 you'd think it'd happen to RTCWEB first, VOD second... not the reverse.

As for VP8, we don't actually know if it falls into the set "a free one that everyone is able to deploy", do we?

Matthew Kaufman

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Fri, 23 Mar 2012 11:52:38 -0400

> As for VP8, we don't actually know if it falls into the set "a free one that everyone is able to deploy", do we?
With all due respect, this is FUD that is baseless.  A blog post[1], an
abandoned patent pool[2], and vague comments by Steve Jobs[3] are all
that really stand as doubt as to the royalty-free basis on VP8.  What we
do know is that On2 had some patents on VP8, and these have been
licensed for royalty-free usage after their acquisition by Google. 
Google themselves have deployed VP8 widely on YouTube via the WebM
format and implemented and distributed it on Android, which is quite a
large surface area to expose if they had doubts about its safety. 
Patent licensing targets don't get much more juicy than Google.

As for implementation, any choice of format will come with challenges,
and the licensing on H.264 vs. VP8 make it clear that VP8 can receive a
much wider adoption in the long run, especially one that does not
unnecessarily restrict this forthcoming standard only to existing
players in the telecommunications market.  There are already plenty of
hardware chips that natively support VP8 decoding and encoding[4], and
that will grow over time, as well, because many parties are strongly
interested in a royalty-free alternative to H.264.  Let alone there are
ARM implementations of VP8 as well[5].

Where is the legitimate doubt, then, that VP8 is not an acceptable,
royalty-free format that can be used for the purposes of WebRTC?  We're
talking initial deployment.  Technology is always changed, and WebRTC 2
is free to adopt Daala[6] when it is released.  Believe me, the
developers would love to ensure it is suitable for WebRTC, amongst other
things.

[1] http://x264dev.multimedia.cx/archives/377#more-377
[2] http://www.mpegla.org/main/pages/CurrentPools_LightBox.aspx (note,
it's not listed there!)
[3] http://www.theregister.co.uk/2010/05/20/jobs_on_vp8/
[4] http://wiki.webmproject.org/hardware/arm-socs
[5] http://www.webmproject.org/tools/vp8-sdk/changelog.html
[6] https://www.xiph.org/daala/

---

From: Roman Shpount <[email-masked]>
Date: Fri, 23 Mar 2012 12:48:30 -0400

> encode or decode the video.

This is not technically correct. You can still build a system that
implements a media proxy that does nothing but handling ICE, encryption,
and identity verification without ever transcoding the content. The cost of
re-encrypting the media is low (ie single E5 Xeon CPU can probably do about
10GB/s), but the cost of transcoding video, or even audio is huge in
comparison. Because of this, supporting a comprehensive set of codecs is
highly desirable.
_____________
Roman Shpount

---

From: Serge Lachapelle <[email-masked]>
Date: Fri, 23 Mar 2012 19:22:52 +0100

Chrome's WebRTC stack will only include the VP8 codec.

Best Regards,

/Serge

On Fri, Mar 23, 2012 at 12:40, Timothy B. Terriberry <
[email-masked]> wrote:

> factor that was not in our power to change, was the availability of content
> on websites. This is not a problem for WebRTC, as browsers control both
> ends of the communication.
>
> even if they were, they might not have particularly good quality, nor the
> features to control latency, loss robustness, and other aspects necessary
> for real-time communication.
>
> http://groups.google.com/**group/mozilla.dev.platform/**
> msg/53892ad3ea9eeb98<http://groups.google.com/group/mozilla.dev.platform/msg/53892ad3ea9eeb98>
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
> Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880
>
> Apparently, this footer is required in Europe. Apologies. This email may
> be confidential or privileged.  If you received this communication by
> mistake, please don't forward it to anyone else,please erase all copies and
> attachments, and please let me know that it went to the wrong person.
>  Thanks.
>  <https://www.ietf.org/mailman/listinfo/rtcweb>

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Fri, 23 Mar 2012 15:00:58 -0400

On 03/23/2012 12:48 PM, Roman Shpount wrote:
> On Fri, Mar 23, 2012 at 8:34 AM, Timothy B. Terriberry
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     With a direct browser-to-browser connection, there is nothing
>     sitting between them to do the transcoding. In the DTLS-SRTP case
>     with identity verification, which I think a number of people here
>     view as highly important, you are in fact _guaranteeing_ that
>     nothing but the browser can encode or decode the video.
>
>
> implements a media proxy that does nothing but handling ICE,
> encryption, and identity verification without ever transcoding the
> content. The cost of re-encrypting the media is low (ie single E5 Xeon
> CPU can probably do about 10GB/s), but the cost of transcoding video,
> or even audio is huge in comparison. Because of this, supporting a
> comprehensive set of codecs is highly desirable.
While perhaps technically desirable for those already knee-deep in the
existing telecommunications, it will serve to lock-out any WebRTC
implementations that either choose to or cannot implement an encumbered
format, such as free/open source software developers and companies.  As
of right now, there *are* no official complete WebRTC implementations to
inconvenience by choosing a mandatory-to-implement codec.  It would be
only an inconvenience to existing infrastructure, but because of the
free and open nature of the proposed format, adding support for it in
software would be a minimal effort, especially as it would standardized.

The reference implementation of VP8 (libvpx) is also licensed in such as
a way as to be equally available to all types of software.

---

From: "Schleef, David" <[email-masked]>
Date: Fri, 23 Mar 2012 22:38:46 +0000

There are several key factors about mobile devices that make your
conclusion on H.264 Baseline a lot less strong than one might think.

Power consumption for a VC application in current generation mobile
devices is mostly due to running the camera, the display, and the 4G or
wifi radio.  Encoding/decoding, while obviously making *some*
contribution, is not really significant at VC sizes and bitrates.  And
encoding/decoding in software doesn't contribute much more.

Secondly, "hardware codec" can mean a lot of different things.  It's
almost always some form of DSP or microcontroller doing the sequencing
of tightly-coupled hardware blocks that offload some of the heavy
lifting.  Software codecs on CPUs are just one end of this.  Some
vendors on the DSP end already support VP8 encoding/decoding in existing
products.  As it has for H.264, VP8 will inevitably progress toward more
hardware/less processor in upcoming generations, and thus lower power.

Also, not related to mobile, the primary (only?) goal of a baseline
codec is to provide 100% coverage.  To get to 100%, _someone_ will have
to use a software codec.  There are no barriers to an implementor using
VP8 in software; that's sort of the entire point of free codecs.  There
are business barriers that will never change for companies like Red Hat
to use H.264 in software.  Thus, you will never get 100% coverage from
H.264.  Ever.  Adding VP8 is, as you say, a "very trivial software
burden".

From my vantage point, your suggestion of H.264 as a baseline codec
comes down to "want to save a few percent of power usage only for the
current generation (which will barely see WebRTC anyway), willing to
sacrifice actually attaining the goal of a baseline codec".

David

---

From: Roman Shpount <[email-masked]>
Date: Fri, 23 Mar 2012 19:22:19 -0400

> a way as to be equally available to all types of software.
I am not arguing for making H.264 a base codec. I would actually prefer
VP8. All I was saying that despite lack of interoperability on encryption,
ICE, and identity, there are still significant benefits of supporting the
same codecs when communicating with legacy equipment, since re-encryption
and media proxy can be handled separately and using much less resources
then transcoding.
_____________
Roman Shpount

---

From: Gregory Maxwell <[email-masked]>
Date: Fri, 23 Mar 2012 17:48:38 -0700

Roman Shpount wrote:
> VP8. All I was saying that despite lack of interoperability on 
> encryption, ICE, and identity, there are still significant benefits of 
> supporting the same codecs when communicating with legacy equipment, 

This is all true, but there won't always be a gateway or SBC in the media
path and users may not want one even if all it did was transcode. The case
with no media gateway can _only_ work reliably by virtue of compatibility
being baked into the specification— in the other cases interoperability
is 'simply' a matter of different tradeoffs.

An interesting observation on the cost of transcoding: a number of
mobile providers are now transparently transcoding their users' http
video downloads on the fly, not for the purposes of changing the codec,
but solely to make them smaller. This can do terrible things to the video
quality (beyond just the reduction in bitrate: MP4 wasn't designed to
stream from a live source). Perhaps this is an argument for more pervasive
end-to-end encryption— but the point remains that CPU power, especially
CPU power in high density data-centers, is still relatively cheap.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 23 Mar 2012 18:10:24 -0700

> end-to-end encryption— but the point remains that CPU power, especially

Excellent points both about encryption and codec. This carrier transcoding
mess is a real challenge and should be architecturally thwarted.

Cb

---

From: Tim Panton <[email-masked]>
Date: Sat, 24 Mar 2012 09:15:09 +0000

Sent from my iPhone

On 23 Mar 2012, at 12:34, "Cavigioli, Chris" <[email-masked]> wrote:

> ITU-T G.711, both u_law (North America) and A_law (Europe) formats, can be supported by everyone with very trivial software burden

I hope that doesn't mean we forget the plan to support Opus. 

We need an adaptive codec with fec in order to get decent audio out of real world networks, like 3G, cafe wifi, vsat etc. 

G711 is ok for perfect networks with legacy interop needs, but pretty much useless anywhere else. 

Tim.

---

From: Roman Shpount <[email-masked]>
Date: Sat, 24 Mar 2012 19:56:39 -0400

> G711 is ok for perfect networks with legacy interop needs, but pretty much
Not that I have anything against OPUS (except that it is not a standard
yet), but G711 works just fine for calls within local LAN or over a
wireline network. If you have the bandwidth, you can run it with 16 or 32
KHz sampling rate and it will sound considerably better then any compressed
codec. Since we are getting more and more bandwidth between end points, in
the future we might not need to compress audio at all. It is not just for
interop.
_____________
Roman Shpount

---

From: Jean-Marc Valin <[email-masked]>
Date: Sat, 24 Mar 2012 20:34:32 -0400

On 24/03/12 07:56 PM, Roman Shpount wrote:
> wireline network. If you have the bandwidth, you can run it with 16 or
> 32 KHz sampling rate and it will sound considerably better then any
> compressed codec. 

Have you ever listened to G.711 at 16 kHz? Certainly not "better then
any compressed codec". In fact, the white quantization noise will
usually be louder than the higher frequencies of the signal. And 32 kHz
will just be even worse.

	Jean-Marc