- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 25 Nov 2014 05:47:38 +0100
- 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. 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: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