Added decoder mix "slots" concept, so that the desired wav channel ca… #1857
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
…n be controlled when producing a mixed audio file When a mixed wav file is created, the channels in the wav container are currently allocated in the same order as each SSRC is received, meaning it is impossible to know which channels have been allocated to the offer or answer side of the call. Furthermore if there is a reinvite or media file played, these are also allocated in the order that SSRC is received - so an "answer" could end up sharing a channel with an "offer" with no way of knowing this. This patch allows you to specify how many channel slots should be allocated within the mixer, and allows you to then specify which slot is assigned to each media in the call (this will usually be 2 slots in total, slot 1 for answer, slot 2 for offer or vice versa). Ported from sipwise#1852
petekelly
added a commit
to petekelly/rtpengine
that referenced
this pull request
Sep 8, 2024
... so that the desired wav channel can be controlled when producing a mixed audio file When a mixed wav file is created, the channels in the wav container are currently allocated in the same order as each SSRC is received, meaning it is impossible to know which channels have been allocated to the offer or answer side of the call. Furthermore if there is a reinvite or media file played, these are also allocated in the order that SSRC is received - so an "answer" could end up sharing a channel with an "offer" with no way of knowing this. This patch allows you to specify how many channel slots should be allocated within the mixer, and allows you to then specify which slot is assigned to each media in the call (this will usually be 2 slots in total, slot 1 for answer, slot 2 for offer or vice versa). Ported from sipwise#1852 Closes sipwise#1857 Closes sipwise#1852 Change-Id: I010208427cabc3a48d6ef7bd3a84e9a5bdcfd492
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.
…n be controlled when producing a mixed audio file
When a mixed wav file is created, the channels in the wav container are currently allocated in the same order as each SSRC is received, meaning it is impossible to know which channels have been allocated to the offer or answer side of the call. Furthermore if there is a reinvite or media file played, these are also allocated in the order that SSRC is received - so an "answer" could end up sharing a channel with an "offer" with no way of knowing this.
This patch allows you to specify how many channel slots should be allocated within the mixer, and allows you to then specify which slot is assigned to each media in the call (this will usually be 2 slots in total, slot 1 for answer, slot 2 for offer or vice versa).
Ported from #1852