- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Mon, 05 Aug 2019 07:36:05 +0000
- To: public-webrtc-logs@w3.org
Yeah the original definition was even more undefined, and all the problems discussed here would certainly have applied to a vague "playout" (what is playout if you have multiple sinks? when you have none?). I think the one we got now is good ("when delivered to the track") and is pretty well-defined.
The question is "when is decoding mandatory?". It could have been asked earlier, but due to previous implementation choices (not in-line with either the old or the new definition) the problem of not always decoding did not show its face until now.
The getStats side-issue is just another way to observe whether or not decoding is happening (both before or after these changes), and is not impacted by any getSSRCs changes, the point was that if we aren't clear about when decoding is mandatory then that is another way to observer it in JS even if the getSSRCs() API didn't exist.
Firefox didn't strictly speaking implement either definition since it was doing estimates and not actual measurements. The estimate is probably "good enough" to be used for the new implementation as well, even though it's not exactly what the spec says (either definition).
> Importantly: I don't think this change was meant to introduce dependencies on having sinks, nor to impact getStats in any way, whose mentions of audio AFAIK predates this change.
What increased the dependency on the sinks was trying to implement something closer to either version of the spec rather than estimating it. If we say that the browser MAY estimate the value, or specify whether or not decoding is mandatory, we're OK. I think we need to do this independently of which definition of getSSRC we use.
--
GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2240#issuecomment-518121745 using your GitHub account
Received on Monday, 5 August 2019 07:36:06 UTC