- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 20 Jul 2015 00:04:36 +1000
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc <public-webrtc@w3.org>
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