-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RTCRtpSynchronizationSource.audioLevel algorithmic equality #1760
Comments
that is an excellent basis for writing a test - if we can get anyone to generate the RTP extension in test. |
@fluffy do you have an opinion here? |
Yes, I think we need to report what is present in the header if the headers is there - I would be fine if there was a separate API that always reported a computed value. The problem is, that the MCU might report the level in the original audio but being doing noise suppression that would make the computed value no match. We would also have the problem that we would have to agree on an algorithm to compute the level so that different browsers did not compute different levels. It's not easy to agree on an algorithm because things like how long a time period the level is averaged over. |
Given @fluffy's comments, I'm inclined to close this issue. With this context, the existing prose seems clear. |
@jan-ivar I find it a bit confusing. I read @fluffy's comment as disagreeing with the prose in the case of synchronization sources (@fluffy please feel free to correct me). Currently, if the audiolevel is missing on the receiver side, it is computed. There is no way to tell if the audio level is computed or if it comes from the header. So if they aren't allegorically equivalent, what assumptions can one make about the quality of the value? I guess my confusion stems from the dual life of this Dictionary, which looks like an RTP construct, but quacks like a media construct. The timestamp is play out time, and the without the header you have to decode the media. |
I'd imagine JS typically knows the server is sending these packets. |
@jan-ivar, there is no server required for synchronization sources. Assuming no MCU, it is impossible to tell which client produced the audiolevel. |
Right, even more so then, I imagine JS typically knows whether the other side will be sending these. |
Ok, it sounds like the answer to my original question is, no, they are not equivalent. The computed value can differ from the value in the header, and that it is desirable to keep the header value. |
Would it fall into the realm of algorithmic equality if a implementation computed the audio level of a packet and ignored the RTP header extension if it was present? The values should be the same, and if they are different I would rather trust the implementation that is feeding playback.
The text was updated successfully, but these errors were encountered: