- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Sat, 15 Feb 2014 19:43:51 +0000
- To: "public-orca@w3.org" <public-orca@w3.org>
Comparing this proposal with the latest editor's draft (http://ortc.org/wp-content/uploads/2014/02/ortc.html), I have some questions.
"dictionary RTCRtpCodecParameters {
// The value that goes in the RTP Payload Type field.
unsigned byte payloadType;
// The same value that goes in the RTCRtpCapabilities.
RTCRtpCodec codec;
// Format parameters that are only used for controlling
// what is sent, and shouldn't be signalled.
// For example, with opus, stereo=1
sequence<KeyValueParam> formatParameters;
// Because they are so different,
// RTCP feedback params are separated out.
sequence<RTCRtcpFeedbackParam> rtcpFeedbackParameters;
};"
[BA] Looking at Section 7.2 of the Editor's draft, RTCRtpCodec is defined as follows:
dictionary RTCRtpCodec {
DOMString name;
unsigned byte? payload-id;
unsigned int? clockRate;
unsigned int? numChannels;
sequence<RTCRtpCodecParameter> formatParameters;
};
Given the definition of RTCRtpCodecParameters in the proposal, I'm wondering whether things like payload-id and formatParameters should be removed from RTCRtpCodec since they are included in RTCRtpCodecParameters. Note that in Section 7.1 of the Editor's draft, RTCRtpCapabilities also depends on RTCRtpCodec:
dictionary RTCRtpCapabilities {
sequence<RTCRtpCodec> audioCodecs;
sequence<RTCRtpCodec> videoCodecs;
sequence<DOMString> headerExtensions;
sequence<RTCRtpFeatures> features;
};
However here the payload-id wouldn't be relevant, so removing it would be fine. I'm wondering about formatParameters though, since I'm wondering how else the applicatino
might figure out what formatParameters are supported for a given codec.
Received on Saturday, 15 February 2014 19:44:26 UTC