Skip to content
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

Closed
na-g opened this issue Feb 2, 2018 · 9 comments
Closed

RTCRtpSynchronizationSource.audioLevel algorithmic equality #1760

na-g opened this issue Feb 2, 2018 · 9 comments
Assignees

Comments

@na-g
Copy link

na-g commented Feb 2, 2018

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.

@alvestrand
Copy link
Contributor

that is an excellent basis for writing a test - if we can get anyone to generate the RTP extension in test.
see web-platform-tests/wpt#9213 for a discussion.

@alvestrand
Copy link
Contributor

@fluffy do you have an opinion here?

@fluffy
Copy link
Contributor

fluffy commented Feb 27, 2018

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.

@jan-ivar
Copy link
Member

jan-ivar commented Mar 8, 2018

Given @fluffy's comments, I'm inclined to close this issue. With this context, the existing prose seems clear.

@na-g
Copy link
Author

na-g commented Mar 8, 2018

@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.

@jan-ivar
Copy link
Member

jan-ivar commented Mar 8, 2018

I'd imagine JS typically knows the server is sending these packets.

@na-g
Copy link
Author

na-g commented Mar 8, 2018

@jan-ivar, there is no server required for synchronization sources. Assuming no MCU, it is impossible to tell which client produced the audiolevel.

@jan-ivar
Copy link
Member

jan-ivar commented Mar 8, 2018

Right, even more so then, I imagine JS typically knows whether the other side will be sending these.

@na-g
Copy link
Author

na-g commented Mar 8, 2018

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.

@na-g na-g closed this as completed Mar 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants