- From: Cullen Jennings <fluffy@cisco.com>
- Date: Sat, 18 Jul 2015 15:23:47 +0200
- To: Roman Shpount <roman@telurix.com>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, public-webrtc <public-webrtc@w3.org>, Peter Thatcher <pthatcher@google.com>
I don't get the need to pass in the kind at all. Why not just return all the capabilities? Or pass in just the video or audio and get all the codecs of that type. > On Jul 18, 2015, at 12:17 PM, Roman Shpount <roman@telurix.com> wrote: > > On Fri, Jul 17, 2015 at 7:33 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > > > 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 13:24:18 UTC