Re: RTCRtpCapabilities

Peter said: 

"This is a lot like the existing RTCCodec, with the following notable
differences:
- There are two lists of codecs: one audio and one video.  I suppose
we could mix them together, but I think it's more convenient this way.
- The RTCCodec doesn't have a specific payload type, because that's
not part of a "capability".
- There are header extensions in the capabilities.
- There are "rtp features" in the capabilities, with a list we can
expand on later."

[BA] Could we perhaps utilize the same RTCRtpCodec dictionary for both RTCRtpCapabilities and RTCRtpParameters?
Similarly, could the RTCRtpCodecParameter dictionary be reused? 

Or is the meaning of the elements different enough between the two uses that this would be inadvisable? 

For example: 

dictionary RTCRtpCapabilities {
    sequence<RTCRtpCodec>    audioCodecs;
    sequence<RTCRtpCodec>    videoCodecs;
    sequence<DOMString>      headerExtensions;
    sequence<RTCRtpFeatures> features;
};


dictionary RTCRtpCodec {
    DOMString                      name;
    unsigned byte?                 payload-id;   //now nullable
    unsigned int?                  clockRate;
    unsigned int?                  numChannels;
    sequence<RTCRtpCodecParameter> formatParameters;
};


dictionary RTCRtpCodecParameter {
    DOMString  name;
    DOMString? value;
};


enum RTCRtpFeatures
WebIDLenum RTCRtpFeatures {
    "nack"
};

dictionary RTCRtpParameters {
    sequence<RTCRtpCodec>                     codecs;
    sequence<RTCRtpEncodingParameters>        encodings;
    sequence<RTCRtpHeaderExtensionParameters> headerExtensions;
};

dictionary RTCRtpEncodingParameters {
    unsigned int ssrc;
    int          TODO;
};

dictionary RTCRtpHeaderExtensionParameters {
    DOMString      uri;
    unsigned short id;
    boolean        encrypt;
};

Received on Wednesday, 5 February 2014 20:59:56 UTC