- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Apr 2017 10:07:32 +0000
- To: public-webrtc-logs@w3.org
For simplicity I guess we should decide how to uniquely identify a codec for all cases instead of worrying about the number of stats objects. Another complexity is what if the |implementation| is different. You could have one implementation for encode and another for decode, and a third that works for both (having one or two objects as necessary assuming payloadType is the same). I want to avoid the "what if it changes, do we split?" complexity. So far all codecId references are from RTCRTPStreamStats, so the encode/decode is implied in the reference, all you would need to know to correctly identify the codec in this case is (payloadType, implementation). The codec.codecType could be kept up-to-date about if its currently only for encode, only decode or (perhaps) both, but when you're referencing a codec for encoding you don't care if it's encode-only or both and don't need that to be part of its id or care if that changes. If an encode-decode splits it would split up into two different payloadTypes would it not, so that would require two codec objects anyway? (payloadType, implementation) are necessary identifiers. Is codecType also necessary for identifying a codec? It sounds simpler, but I don't know if it matters in practice. I don't have a strong opinion on this. Am I missing anything? -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-stats/pull/195#issuecomment-297671772 using your GitHub account
Received on Thursday, 27 April 2017 10:07:38 UTC