W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2015

Re: I have created a PR for RtpSender.getCapabilities and RtpReceiver.getCapabilities

From: Roman Shpount <roman@telurix.com>
Date: Sat, 18 Jul 2015 06:17:42 -0400
Message-ID: <CAD5OKxumdsd0CEJswqJXAFnNEkEkppBrXHGgrSNWnMqY-v-MZA@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: public-webrtc <public-webrtc@w3.org>, Peter Thatcher <pthatcher@google.com>
On Fri, Jul 17, 2015 at 7:33 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>

> > I would think that having separate codec.name and codec.mimeType would
> be the best option. Based on
> http://www.iana.org/assignments/media-types/media-types.xhtml there are
> cases when there is a mismatch between the name and the mime type, such
> as "vnd.vivo" and "video/vnd-vivo". I hope no will ever need any of those
> codecs, but theoretically it is possible.
> One piece of warning: duplicate information like this can lead to
> conflicting information orifices in the two fields. I would prefer to just
> use mime types as defined by IANA:
> http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml. note
> that these are the rtp mime types, not the file mime types, which is more
> appropriate for WebRTC imho.
I agree, redundant data can be dangerous, so only one field should be
specified. I generally prefer to have the data parsed, so I would like to
see separate codec.name, set just to name, and codec.kind set to "audio" or
"video". Which brings the question, what about the extra encoding
parameters, such as clock rates, channels, or bit rates supported? If mime
types are used, these can be specified as mime type parameters such as
"audio/L16;rate=16000", but analyzing them becomes even more difficult. I
would like to see at least explicit codec.rate and codec.channel as well.
Roman Shpount
Received on Saturday, 18 July 2015 10:18:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:08 UTC