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

read contents of .opus files (no decoding) #24

Open
dragos-oancea opened this issue Feb 25, 2021 · 2 comments
Open

read contents of .opus files (no decoding) #24

dragos-oancea opened this issue Feb 25, 2021 · 2 comments

Comments

@dragos-oancea
Copy link

I always wondered why there is no support in the lib for getting individual opus packets from the ".opus" file itself. It would be very helpful for VOIP/webrtc - eg: reading an opus file and send it contents packet by packet on the wire (without decoding the file and then re-encoding to put the packet on the wire).

@rillian
Copy link
Contributor

rillian commented Feb 25, 2021

Do you need seeking support? If not it's fairly straightforward to use the underlying libogg api to extract the packets. See this code from opus-tools package for an example.

If you do need seeking support that's a better use-case for opusfile, although RTP can't be made sample-accurate. The API would be complicated by RTP's narrower specification: an opus file can switch between mono/stereo and mutli-channel within the same stream, but RTP doesn't allow this, so there would need to be some way to signal the caller when parameters changed at a particular link boundary.

@dragos-oancea
Copy link
Author

Thank you for your answer and for pointing out the code.
No seeking support needed for the scenarios I have in mind: playing opus files for IVRs (when the caller has opus negotiated in SDP) and doing RTP->websocket streaming (for ASR for example). Switching middle-call between mono/stereo is fairly uncommon in VOIP.

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

2 participants