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

On Sat, Jul 18, 2015 at 8: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.

I'd suggest just going with a single mime type field to avoid having
to deal with all these issues. Mime type is defined as a single string
that a lot of things already understand and parse - ripping the bits
of the mime type field apart just means that for some things you have
to put them back together again and that seems more effort than it's
worth. For example, most mime types won't have a rater and a channel -
how are you going to fill these fields sensibly then? If you fill them
from some other information, how are you going to put the original
mime type field back together again?

S.

Received on Sunday, 19 July 2015 07:42:13 UTC