Re: Proposal and discussion for RtpSender.getCapabilities

If a header extension can be used for both audio and video, I think that
would be two different capabilities, and could be represented as two
different RTCRtpHdrExtCapability objects:  one for each kind.


On Mon Nov 24 2014 at 6:49:51 PM Harald Alvestrand <harald@alvestrand.no>
wrote:

> Den 24. nov. 2014 18:38, skrev Bernard Aboba:
> > RtpSender.getCapabilities(kind) would be used to return the
> capabilities for a given kind.  So if kind === "audio" then this would
> return the audio capabilities.  Having RTCRtpHdrExtCapability.kind would
> enable getCapabilities(kind) to filter the header extensions.
> > There are some header extensions that have a clear kind (e.g. "audio"
> for client-mixer and mixer-client extensions) and some that may not (e.g.
> abs-send-time, described at http://www.webrtc.org/experime
> nts/rtp-hdrext/abs-send-time).  In the latter case, it is necessary to
> define what RTCRtpHdrExtCapability.kind would be (e.g. return the value of
> kind passed as an argument in getCapabilities(kind)).
> >
>
> FWIW, if "kind" is part of the information returned, I don't see an
> advantage in cluttering up the interfce with a "kind" selection
> parameter. It's one line of Javascript to do the filtering client-side.
>
> But.....
>
> What should the "kind" value be for extensions that apply to all kinds?
> Empty string, misssing, or something else? (I like "missing", and would
> rename the field "appliesToKind").
>
> What should the "kind" value be for extensions that apply to video and
> depth, but not to audio?
>
> Both things need to be specified both for the argument case and the
> return-value case, if both exist.
>
> But I don't think it actually adds much value - if my JS has no idea
> what
> "http://www.webrtc.org/experiments/rtp-hdrext/froobnitz-the-doodads"
> means, it doesn't help me much that I know it applies to "audio". The
> implementation will be simpler if we just don't bother with "kind" for
> header extensions.
>
>
>
> >
> > ======================================
> > From: Singh Varun [varun.singh@aalto.fi]
> > Sent: Monday, November 24, 2014 6:19 AM
> > To: Peter Thatcher
> > Cc: public-webrtc@w3.org
> > Subject: Re: Proposal and discussion for RtpSender.getCapabilities
> >
> > Hi Peter
> >
> > On 03 Nov 2014, at 22:59, Peter Thatcher <pthatcher@google.com<mailto:p
> thatcher@google.com>> wrote:
> >
> > At TPAC (2014), we reached consensus that we want some form or
> RtpSender.getCapabilities.  But we wanted to make sure we have the right
> "minimal starting set".    Additionally, there was an idea of having audio-
> and video-specific types for audio and video codecs.
> >
> >
> > dictionary RTCRtpHdrExtCapability {
> >     DOMString kind;
> >     DOMString uri;
> > };
> >
> >
> > URIs are based on http://www.iana.org/assignments/rtp-parameters/rtp-
> parameters.xml and may apply to particular stream or to all the media
> streams?
> > What does the “kind" correspond to in the case of hdr extensions? Is it
> supposed to point to the codec.kind?
> >
>
>
>