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

["Hutton, Andrew" <[e-mail]>]

On 19 October 2012 15:58 Eric Rescorla wrote:
> 
> 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?

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


> 
> -Ekr
> 
> 
> On Fri, Oct 19, 2012 at 6:58 AM, Hutton, Andrew
> <[e-mail]> wrote:
> > 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
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb