Subject: [rtcweb] Video Codec - Possible to use.

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 19 Oct 2012 13:58:48 +0000

Hi,

The question of whether it will be possible for a webrtc application to make us of video codec's (or audio codec) which are not implemented in the browser itself has been raised before but I don't think there has been a clear answer.

Some clarity on this might help some of us to come to a conclusion on where we stand in the MTI debate.

I looked through the archives and found some statements that indicate this should be possible but I not sure we have a definitive statement on this. For example:

On 06 September 2012 00:29 Randall Gellens
> 
> One of the goals of rtcweb is to encourage greater use of native
> codecs, and greater access to such codecs by applications such as
> those running in browsers.  These are worthy goals, since native
> codecs often have better performance within the environment.
> (Examples include AMR and EVRC on handsets.)  These codecs also can
> be supported out-of-the-box, no separate downloads, no signed forms.
>

Is this really a goal we have agreement on? There does not seem to specific requirements in the requirements draft.

Also I think there are SDP implications relating to this. How would the browser and/or application be able to build the correct SDP to offer additional codecs?

Regards
Andy

---

From: Stefan Hakansson LK <[email-masked]>
Date: Fri, 19 Oct 2012 16:22:32 +0200

On 10/19/2012 03:58 PM, Hutton, Andrew wrote:

>
> Also I think there are SDP implications relating to this. How would
> the browser and/or application be able to build the correct SDP to
> offer additional codecs?

To me this is a "must". Regardless of what codecs are made MTI now, they 
are likely to not be state-of-art in a few years time.

I had the impression this was one of the main advantages with using SDP: 
it offers a well established way to negotiate what codec(s) to use 
between end-points.

Br,
Stefan

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Oct 2012 07:57:46 -0700

I don't really understand the question.

Obviously, it should be possible for WebRTC implementations (e.g., browsers)
to derive codecs from the underlying platform (just as some browsers get
their libc or their crypto libraries from the underlying platform). Similarly,
it should be possible for browsers to allow pluggable additional codecs.
In both cases these seem like features browser implementors might
choose to provide at their discretion and which wouldn't be visible to
Web content.

Did you have something else in mind?

-Ekr

On Fri, Oct 19, 2012 at 6:58 AM, Hutton, Andrew
<[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 19 Oct 2012 15:08:37 +0000

> are likely to not be state-of-art in a few years time.

That is not really the issue. Of course the browser can add support for new codec's in years to come the question is whether the browser implementation will be able to make use of codec's provided by the underlying platform or plugin.

> it offers a well established way to negotiate what codec(s) to use

SDP of course is flexible on this but will the browsers SDP implementation be able to handle this?

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 19 Oct 2012 15:20:49 +0000

> Did you have something else in mind?

Sorry if it is a silly question I am not so familiar with the mechanism here.

What concerns me is that I hear it stated that using additional codec's from the underlying platform is possible but can someone tell me how the correct SDP would be generated? Would the browser have the information to build the SDP for codec's it did not natively support or would the application need to craft the SDP and then if the application did it would the browser be able to do the right thing when the app calls setLocalDescription() etc.  

Andy

> > The question of whether it will be possible for a webrtc application
> to make us of video codec's (or audio codec) which are not implemented
> in the browser itself has been raised before but I don't think there
> has been a clear answer.
> >
> > I looked through the archives and found some statements that indicate
> this should be possible but I not sure we have a definitive statement
> on this. For example:
> >
> > Is this really a goal we have agreement on? There does not seem to
> specific requirements in the requirements draft.
> >

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Oct 2012 08:28:58 -0700

> What concerns me is that I hear it stated that using additional codec's from the underlying platform is possible but can someone tell me how the correct SDP would be generated? Would the browser ha…

So, obviously it depends on *exactly* what one means by the codec being
available on the underlying platform. There seem to be at least two cases:

1. This is some feature provided by the OS or platform vendor. In this
case presumably it comes with documentation and the browser implementor
reads the documentation and the associated RFCS and generates the
right SDP. In this case, the situation is not much different from that when
the codec implementation is part of the browser. (Note that in many cases
these codecs come from third party libraries in any case).

2. The browser supports some kind of plugin scheme which allows
people to download their own codecs and install them. This would require
the browser vendor to implement some interface for each codec to
get a crack at the SDP and is therefore a lot more work.

Which case are you concerned about?
-Ekr

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 19 Oct 2012 15:49:39 +0000

On 19 October 2012 16:29 Eric Rescorla wrote:
> To: Hutton, Andrew

Both and thanks your answer really helps my understanding and it seems it is really up to the browser vendors and nothing the IETF or W3C can do to influence this.

So would I be correct in thinking that at least for the immediate future webrtc applications will be limited to the codec(s) that the browsers natively support or do browser vendors intend to at least implement option 1 above for at least some commonly used video codec's?

Andy

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 19 Oct 2012 13:24:46 -0400 (EDT)

Clearly, the API that the application uses must have some feature that
allows the application to determine the codecs that are provided by
the platform on which the application executes.  This information must
be provided in a format that plugs into the SDP, that is, the
<encoding name> field value in the a=rtpmap line.

Exactly how the API determines this information is unspecified, but of
course, it is coordinated with the mechanism by which the incoming RTP
is sent to the codec and ultimately displayed.

And there should be a "mandatory to implement" video codec to ensure
interoperation.  The tricky question is which one should it be?  It
should be believed to be universally royalty-free.  Certainly it
should not require a negotiated licensing agreement, as that would
suppress development by non-equipment-vendors.  It does *not* have to
be state of the art.  It can't be too difficult to find *one* codec
with these properties.

Dale

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Oct 2012 10:36:29 -0700

On 19 October 2012 10:24, Dale R. Worley <[email-masked]> wrote:
> It can't be too difficult to find *one* codec with these properties.

RFC 2435 was not considered adequate for the described use cases.