W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2014

Re: Proposal and discussion for RtpSender.getCapabilities

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 25 Nov 2014 05:47:38 +0100
Message-ID: <547409EA.1030801@alvestrand.no>
To: public-webrtc@w3.org
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/experiments/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.


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
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:pthatcher@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?
Received on Tuesday, 25 November 2014 04:48:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:42 UTC