Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call

From: Xavier Marjou <[email-masked]>
Date: Thu, 21 Feb 2013 18:28:02 +0100

As suggested by the chairs, here is a draft indicating the motivations, as
well as a proposed way-forward, regarding "additional relevant audio
codecs" :
http://tools.ietf.org/html/draft-marjou-rtcweb-audio-codecs-for-interop-00

I would like to present it during the IETF-86.

Cheers,
Xavier

On Mon, Jan 28, 2013 at 9:12 AM, Magnus Westerlund <
[email-masked]> wrote:

> Hi,
>
> We chairs was considering inclusion in draft-ietf-webrtc-audio, but we
> didn't have any strong opinions on this. Based on that several WG
> participants thinks this should be an independent document, I thus
> decided that we will start out with an independent document. If the WG
> feels differently later we can always fold the text into the audio codec
> and processing requirements document.
>
> I would recommend that the individuals interested in contributing a
> codec writes an independent submission with focus on the codec
> considerations around the codec(s) they are interested in. Then we can
> merge this into a common WG document.
>
> Cheers
>
> Magnus
>
>
> On 2013-01-27 10:14, Romascanu, Dan (Dan) wrote:
> > Hi WG chairs,
> >
> > Clarification question:
> >
> >> In lieu of additional normative text, we believe the WG discussion
> >> supports the inclusion of a new section on "Additional Relevant Codecs".
> >
> > Inclusion where?
> >
> > Thanks and Regards,
> >
> > Dan
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of Cullen Jennings (fluffy)
> >> Sent: Thursday, January 24, 2013 6:47 PM
> >> To: [email-masked]
> >> Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs
> >> call
> >>
> >>
> >> We have been running a call for consensus regarding Selecting
> >> Recommended Audio Codecs.
> >>
> >> At this point the chairs are calling this as "no WG consensus".
> >>
> >> We can however note a strong interest in a non-normative listing of
> >> potentially important codecs including a description why they should be
> >> considered to be supported in WebRTC implementations.
> >>
> >> In lieu of additional normative text, we believe the WG discussion
> >> supports the inclusion of a new section on "Additional Relevant Codecs".
> >> That can contain a list of codecs which are relevant in specific
> >> contexts, along with a short description of the context for each.
> >> Specifically there seems to be interest in understanding the advantages
> >> and costs of G.722, AMR, and AMR-WB. We hope that text would broaden
> >> understanding of the WebRTC use case contexts.
> >>
> >> The WG chairs
> >> Magnus, Ted and Cullen
> >>
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> > _______________________________________________
> > rtcweb mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 21 Feb 2013 12:45:33 -0500

If we follow the logic in this document, I would suggest that G.722 MUST be
implemented in all cases. For all practical purposes G.722 is always
available. It might not be provided by the platform, but the complexity of
implementing it is extremely low, and there is no IPR cost. G.722 is
already part of the current WebRTC code base in both Chromium and Firefox,
but it is disabled during compilation from being included in the web
browser build. Adding support for G.722 in two current major
implementations would require one change in defines.
_____________
Roman Shpount

---

From: Andrew Allen <[email-masked]>
Date: Thu, 21 Feb 2013 18:13:04 +0000

Roman

It seems you are re-visiting an already decided question of which are the mandatory to implement audio codecs and the concensus call already was made months ago that they are OPUS and G.711.

In my view these achieve the minimum necessary level of basic audio communications interoperability with other systems.
I think this low cost argument has already been dismissed - there is no free lunch - development and testing have considerable costs associated with them as do the consequential delays in implementation and deployment and the IPR situation is not usually 100% certain.

The market will decide what other codecs are useful to be deployed for superior quality interoperability with other high quality audio systems and what codecs make commercial sense to implement today will not make sense 5 years from now.

I do not agree that we should add any additional mandatory to implement audio codecs for RTCweb or make recommendations on additional codecs either.

Andrew

From: Roman Shpount [mailto:[email-masked]]
Sent: Thursday, February 21, 2013 11:45 AM Central Standard Time
To: Xavier Marjou <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call

If we follow the logic in this document, I would suggest that G.722 MUST be implemented in all cases. For all practical purposes G.722 is always available. It might not be provided by the platform, but the complexity of implementing it is extremely low, and there is no IPR cost. G.722 is already part of the current WebRTC code base in both Chromium and Firefox, but it is disabled during compilation from being included in the web browser build. Adding support for G.722 in two current major implementations would require one change in defines.
_____________
Roman Shpount

On Thu, Feb 21, 2013 at 12:28 PM, Xavier Marjou <[email-masked]<mailto:[email-masked]>> wrote:
As suggested by the chairs, here is a draft indicating the motivations, as well as a proposed way-forward, regarding "additional relevant audio codecs" : http://tools.ietf.org/html/draft-marjou-rtcweb-audio-codecs-for-interop-00

Cheers,
Xavier

On Mon, Jan 28, 2013 at 9:12 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Cheers

Magnus

On 2013-01-27 10:14, Romascanu, Dan (Dan) wrote:
>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
>> To: [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287<tel:%2B46%2010%207148287>
Färögatan 6                | Mobile +46 73 0949079<tel:%2B46%2073%200949079>
SE-164 80 Stockholm, Sweden| mailto: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 21 Feb 2013 13:22:38 -0500

On Thu, Feb 21, 2013 at 1:13 PM, Andrew Allen <[email-masked]> wrote:

> It seems you are re-visiting an already decided question of which are the
> mandatory to implement audio codecs and the concensus call already was made
> months ago that they are OPUS and G.711.
>

I know there is a consensus regarding this issue. What I was saying that in
the proposed document, the hurdle that a codec MUST be supported if
provided by the platform should not apply to G.722. It does not matter if
G.722 is provided by the platform since complete implementation of G.722
would probably take less effort then integration with platform provided AMR
or AMR-WB codec.
______________
Roman Shpount

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 21 Feb 2013 18:59:08 +0000

This conversation shouldn’t have been an IETF issue either, any more than making a list of mandatory SIP codecs would be.

Matthew Kaufman

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: Thursday, February 21, 2013 10:13 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call

Roman

Andrew

From: Roman Shpount [mailto:[email-masked]]
Sent: Thursday, February 21, 2013 11:45 AM Central Standard Time
To: Xavier Marjou <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Conclusion statement for Recommended Audio Codecs call

Cheers,
Xavier

Cheers

Magnus

--

Magnus Westerlund

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 22 Feb 2013 01:29:06 +0000

I've never understood why G.722 was disabled in the builds. Does anyone have any insight into that? 

On Feb 21, 2013, at 10:45 AM, Roman Shpount <[email-masked]> wrote:

> On Thu, Feb 21, 2013 at 12:28 PM, Xavier Marjou <[email-masked]> wrote:
> On Mon, Jan 28, 2013 at 9:12 AM, Magnus Westerlund <[email-masked]> wrote:
> Hi,
> 
> >> From: [email-masked] [mailto:[email-masked]] On Behalf

---

From: Ralph Giles <[email-masked]>
Date: Thu, 21 Feb 2013 19:20:50 -0800

> I've never understood why G.722 was disabled in the builds. Does anyone have any insight into that?

As discussed at IETF 84, we believe the pair of G.711 and Opus are the
appropriate MTI choice to ensure interoperability.

Experience with the web's long-lived historical content has made me
conservative about data formats proliferation, since historical
formats must often be supported indefinitely. I am therefore in no
hurry to support additional codecs in our webrtc implementation.

 -r

---

From: Roman Shpount <[email-masked]>
Date: Fri, 22 Feb 2013 13:38:06 -0500

> appropriate MTI choice to ensure interoperability.

Can you explain why iSAC is included? It is a much more complex codec then
G.722. It is not standardized or reviewed by any standards body. Its IPR
situation is unclear, since there is no mechanism to claim IPR against it.
It would also require a substantial amount of maintenance. I would even
say, that in presence of Opus it has no value, except  to connect to one of
a couple instant messenger networks.

> hurry to support additional codecs in our webrtc implementation.

I understand why this argument makes sense for MTI codec, but as far as
additional codecs implemented in the browser it does not hold water. There
is a big difference between image or audio formats and codec support. If
image format is not supported some portion of the web page will not be
displayed. If optional codec is no longer supported, end points will
negotiate one of the MTI codecs, and in the worst case we will end up with
G.711 call. It will not sound as good but it will still work. Right now
there is a good reason to support G.722 taking into account number of end
points for which it is the only wide band codec supported. In the future,
when this situation changes, browsers can drop this codec, and whoever is
still left over using G.722 will have to switch or use G.711.Not
implementing it now and thus not giving the time for the market to catch up
is unreasonable.

BTW, during the time when MTI codecs were discussed, one of the arguments
not to include G.722 (or other codecs in MTI list) was that WebRTC
implementers would do a reasonable thing and support a comprehensive list
of codecs to insure widest possible interoperability. Currently this is not
the case.

Finally,even though supporting codecs is not free, amount of effort spent
arguing about G.722 on this list probably exceeds resources necessary to
maintain G.722 for the next few years.
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 22 Feb 2013 21:21:39 +0100

On 02/22/2013 07:38 PM, Roman Shpount wrote:
>
> On Thu, Feb 21, 2013 at 10:20 PM, Ralph Giles <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 21 February 2013 17:29, Cullen Jennings (fluffy)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
> Can you explain why iSAC is included? It is a much more complex codec 
> then G.722. It is not standardized or reviewed by any standards body. 
> Its IPR situation is unclear, since there is no mechanism to claim IPR 
> against it. It would also require a substantial amount of maintenance. 
> I would even say, that in presence of Opus it has no value, except  to 
> connect to one of a couple instant messenger networks.

Note that iSAC is not present in the Firefox build.

It was present in the Chrome builds before we gathered sufficient 
confidence in the OPUS IPR situation to build in that option, in order 
to have at least one codec of higher quality than G.711; we haven't seen 
a reason to turn it off yet.

At no time has Google argued for it being a mandatory-to-implement codec.

If you want to assert IPR against it, I'm sure you can find a way to do 
so. Email kind of works.

> I understand why this argument makes sense for MTI codec, but as far 
> as additional codecs implemented in the browser it does not hold 
> water. There is a big difference between image or audio formats and 
> codec support. If image format is not supported some portion of the 
> web page will not be displayed. If optional codec is no longer 
> supported, end points will negotiate one of the MTI codecs, and in the 
> worst case we will end up with G.711 call. It will not sound as good 
> but it will still work. Right now there is a good reason to support 
> G.722 taking into account number of end points for which it is the 
> only wide band codec supported. In the future, when this situation 
> changes, browsers can drop this codec, and whoever is still left over 
> using G.722 will have to switch or use G.711.Not implementing it now 
> and thus not giving the time for the market to catch up is unreasonable.
>
> BTW, during the time when MTI codecs were discussed, one of the 
> arguments not to include G.722 (or other codecs in MTI list) was that 
> WebRTC implementers would do a reasonable thing and support a 
> comprehensive list of codecs to insure widest possible 
> interoperability. Currently this is not the case.
>
> Finally,even though supporting codecs is not free, amount of effort 
> spent arguing about G.722 on this list probably exceeds resources 
> necessary to maintain G.722 for the next few years.
> _____________
> Roman Shpount
>
>
>
>