Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt

[franklin blek <[e-mail]>]

As per my understanding, this API is useful.
I think it is good to be present in webrtc1.0. Instead of processing this
as a seperate draft it will be more good to merge with the
RTPSender/Receiver draft. So that all the consensus will be completed at
one point of time, with out delaying the delivery of WebRTC 1.0.


On Wed, Jul 23, 2014 at 9:20 PM, Makaraju, Maridi Raju (Raju) <
[e-mail]> wrote:

>   Kiran,
>
> Please see my inline comments marked between <Raju2> and </Raju2>.
>
>
>
> >This seems like a pretty big hammer to solve a fairly small problem. This
> proposal adds 6 new API points for the purpose of >changing the order of
> codecs in createOffer, which seems like a high cost-benefit ratio. And
> while the use cases listed here are >helpful, they seem somewhat contrived
> to me, since it seems unlikely that the application can make better choices
> about >bandwidth >or power consumption than the browser.
>
>
>
> [Raju] Per my understanding, the main object of this draft can be achieved with no additional APIs and with just the proposed introduction of preferredAudioCodecs and preferredVideoCodecs options to RTCOfferAnswerOptions constraint of createOffer()/createAnswer().
>
> So, IMO I don’t think getCodecPreferences()/setCodecPreferences() add much value, so can be delayed or dropped.
>
>
>
> The need for getSupportedAudioCodecs()/getSupportedVideoCodecs() in 1.0 can be questionable as the application can specify codecs order per known codecs (or get the list via a dummy createOffer() call).
>
>  [KIRAN] New API is added for this only because, it can be called on Peerconnection irrespective of its state and the order of parsing is also easy when compared to parsing of whole SDP returned through createOffer/Answer.
>
> *<Raju2> I agree that it is easy. But, I also agree with that Justin that given other must have work this may be lower priority; these small things do add up to delay webrtc 1.0 delivery.*
>
> *</Raju2>*
>
>
>
> The draft talks about fulfilling A5 in [I-D.ietf-rtcweb-use-cases-and-requirements], but I do not see any explicit mention of how codecs can be removed? preferredAudio/VideoCodecs constraint only specifies the order of preference. Don’t you need another constraint to exclude specified codecs? It’s probably a bad design to have codecs not in the preferred list be removed automatically.
>
>
>
>  [KIRAN] The removal of codecs is explained in section 6.
>
>   "*The offer / answer*
>
> *   SHOULD NOT contain audio codecs other than those specified by*
>
> *   JavaScript application and the order of preference SHOULD be with*
>
> *   high priority for the codecs first in the sequence."*
>
>   Perhaps this is in indirect way. I will modify the statement to directly point this. I don't want to increase the constraints just for removal, which can be achieved with this constraint. So I followed this design.
>
> *<Raju2> Sorry I missed that. But, the name “preferredCodecs” does not convey the “removal” part clearly as preference generally indicates reordering priority, but not removal. Such semantics may put additional burden on app to list all the codecs in preferredCodecs list where as user may just prefer a particular codec to be the 1st one and does not care about other codecs order, so they can keep their relative order but they are needed in the list. IMO, removal of codecs requires another separate constraint and not be mixed with preferredCodecs constraint. I am not wedded to having separate constraint for removal though, but I seek input from other members.*
>
>
>
> *</Raju2>*
>
>
>
> *BR*
>
> *Raju*
>
>
>
>
>
> BR
>
> Raju
>
>
>
>
>
>
>
>
>
>