Limit max Redundant Audio Encoding packet size to 1000 bytes. #2763
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dinmin-amzn
force-pushed
the
limit-red-size
branch
3 times, most recently
from
4ea3b51
to
4409c02
Compare
ltrung
reviewed
Sep 26, 2023
| @@ -236,12 +237,12 @@ export default class RedundantAudioEncoder { | |||
| frame: RTCEncodedAudioFrame, | |||
| controller: TransformStreamDefaultController | |||
| ): void { | |||
| // const frameMetadata = frame.getMetadata(); | |||
There was a problem hiding this comment.
Is this a miss from previous PR? Does not seem related with the issue this PR tries to fix.
There was a problem hiding this comment.
Yeah this was missed from the previous CR
There was a problem hiding this comment.
@dinmin-amzn Curious why a unit test did not catch this. Maybe we can add one?
There was a problem hiding this comment.
Yes, let me add a unit test for this
There was a problem hiding this comment.
Updated the existing unit tests to better capture this case.
pracheth
previously approved these changes
Sep 26, 2023
mklingb
previously approved these changes
Sep 26, 2023
In Chromium-based browsers, writing audio frames larger than 1000 bytes will cause an error to be thrown, so we limit the max Redundant Audio Encoding packet size to 1000 bytes. See https://crbug.com/1248479.
dinmin-amzn
force-pushed
the
limit-red-size
branch
from
4409c02
to
c46c8e2
Compare
dinmin-amzn
commented
Sep 26, 2023
| }); | ||
|
|
||
| it('forwards frames when the primary payload cannot be determined', () => { | ||
| const header = createRedHeader( |
There was a problem hiding this comment.
I went ahead and made this test case more effective as well since it is similar in nature to the previous test case.
ltrung
approved these changes
Sep 26, 2023
dinmin-amzn
added a commit
that referenced
this pull request
Sep 26, 2023
In Chromium-based browsers, writing audio frames larger than 1000 bytes will cause an error to be thrown, so we limit the max Redundant Audio Encoding packet size to 1000 bytes. See https://crbug.com/1248479.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue #:
Description of changes:
In Chromium-based browsers, writing audio frames larger than 1000 bytes will cause an error to be thrown, so we limit the max Redundant Audio Encoding packet size to 1000 bytes. See https://crbug.com/1248479.
Testing:
Previously, starting a call with WebAudio, Redundant Audio Encoding, and fullband music stereo quality all enabled and introducing high uplink packet loss (>20%) would cause the Redundant Audio Encoding payloads to exceed the Chromium-imposed limit and audio sending would stop working for the rest of the meeting. This issue is fixed by this PR.
Can these be tested using a demo application? Please provide reproducible step-by-step instructions.
Checklist:
Have you successfully run
npm run build:releaselocally?y
Do you add, modify, or delete public API definitions? If yes, has that been reviewed and approved?
n
Do you change the wire protocol, e.g. the request method? If yes, has that been reviewed and approved?
n
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.