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

On Sun, Jul 19, 2015 at 6:19 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
> 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)


Why do we have both a RTCCodec dictionary and a RTCRtpCodecCapability
? Shouldn't the latter reuse the former?

I'd go with consistency - if we do the full parsing, we should do it everywhere.

I just checked the Opus parameters at
https://tools.ietf.org/html/rfc7587 and there indeed seem to be quite
a bunch. If that's common, parsing them out makes sense.

Silvia.

Received on Sunday, 19 July 2015 14:05:23 UTC