Re: Issue 141: Mandatory "kind" in RTCRtpReceiver constructor

Peter Thatcher said: 

"In fact, if we had the JS pass down  the kind explicitly, it would still need
to do so anyway, because if the JS passes down kind=audio, and then
passes down video codecs, the implementation should complain.   So, it
needs to check either way, and I'd prefer not having duplicate,
possibly contradictory parameters."

[BA] Right.  In order to be able to return RTCRtpCapabilities when RTCRtpReceiver.getCapabilities(kind) is called, an implementation needs to be able to filter codecs based on "kind" as well as to fill in RTCRtpCodecCapabilities.name and RTCRtpCodecCapabilities.kind.  It therefore has the information needed to map "name" to "kind", allowing it to determine the "kind" of each codec based on parameters.codecs[i].name.  So if we require that "name" always be filled in, then "kind" can always be determined. 

Peter Thatcher said: 

" The time at which the kind is known, the codecs will probably be known
also.  If we can think of a use case where the receiver knows the kind
and wants a track but doesn't know the codecs yet, then I could see a
reason for the JS to pass down the kind explicitly.  But I don't know
of such a use case."

[BA] When receive(parameters) is called, the codecs are known, so it should be possible to determine "kind".  How about adding the following explanation to the "receive" method text? 

"After receive returns, track is set, and the value of track.kind is determined based on the kind of the codecs provided in parameters.RTCRtpCodecParameters. If all the codecs are of a single kind then track.kind is set to that kind; if the kind differs between codecs, then track.kind is set to "all".

Received on Wednesday, 6 August 2014 17:22:02 UTC