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

On 07/19/2015 09:41 AM, Silvia Pfeiffer wrote:
> 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?

In http://w3c.github.io/webrtc-stats/#codec-dict* I broke out
"channels", "clockRate, "codec" and "parameters" - because those are
encoded differently in SDP from how they are encoded in a pure MIME
type, so any app that wanted to match what's in SDP to what's in stats
would have to break them up anyway - which limited the benefits to using
the single-string form of the MIME type.

ie Opus stereo at 48 kbits/sec with inband FEC

m=audio
a=rtpmap:101 opus/48000/2
a=fmtp:101 stereo=1; useinbandfec=1

while in a pure MIME type string it would be

audio/opus; rate=48000; channels=2; stereo=1; useinbandfec=1

(with apologies for possible errors)
>
> S.
>


-- 
Surveillance is pervasive. Go Dark.