lostromb
libopus 1.2.1
New versions of the opus library contains many important improvements, however the users of this port is left behind now. Upgrading to libopus 1.2.1 would be nice.
As far as I know the main feature that is lacking at this point is FEC / PLC on the CELT layer, which provides better packet loss resilience above 40kbit/s. Apart from that the "improvements" are either very minor or very niche things:
- Slight quality improvements at low bitrates
- Ambisonics encoding support
- ARM intrinsics not applicable here
- Some kind of new channel mapping scheme for 9+ channels
Since I don't actually know how the Opus sourcecode works, my main quality measure is bit-parity with the C code's output. I could port some of the improvements over, sure, the difficulty is mainly that I'd have to manually do it by looking over the diff for every commit to opus-master, convert it to C#, ensure that it contains the proper fixes that I want, apply it as a patch, and then ensure parity with that specific build of the C code. In short, possible, but I don't want to bother with the risk of losing parity for what appears to me to be very tiny reward.
(And that's just for C#; you'd have to do the same for Java as well...)
The new version might have an impact also for VoIP calls, due to the followings (from the libopus changelog):
- Speech quality improvements especially in the 12-20 kbit/s range
- More aggressive use of wider speech bandwidth, including fullband speech starting at 14 kbit/s
- SILK CBR improvements
I just added the Java library to a VoIP project and it works fine, however with the native library (via JNI) it seems that I can achieve better/same quality with the same bitrate (it is very difficult to test this, but after doing a lot's of test calls, it seems that there is some audible difference). From these it seems to me that porting the changes would worth the effort.
I have several VoIP endpoint with opus support (using different implementations and opus versions) and I would retest your library with these if you will port the changes.
Like I said, the work would involve replaying the last 8 months or so of opus-master commits while also converting it from C, which even for one changelist like this is not trivial.
Sure, there are potential quality gains, but I simply don't have the time right now.
I understand and thank you for all this effort creating these wonderful ports. I imagine that this could be a very valuable library for Java and C# developers going for cross-platform. Maybe 1-2 years later you will find some time to improve it by porting the latest libopus changes. (Or maybe somebody else will do it although i would not count on this). Thank you again for the great work!
@lostromb Just curious, would you like to try to make conversion of latest opus (lets say 1.3 when it will be released) using some automated tools, like Sichem (https://github.com/rds1983/Sichem) ? Author of this utility successfully used it to translate C libraries like stb (https://github.com/rds1983/StbSharp) & Nuklear (https://github.com/rds1983/NuklearSharp) to C#, besides some others. May be you can at least take a look on it? P.S. Also, do you accept donations? Any way how can I say you thanks for your work?
At a glance it looks like Sichem preserves the unsafe nature of pointers to keep the C# as close as possible. While that should theoretically work fine (in fact I'm curious to see how well it would work - Opus is highly portable as it is so I'd expect great success), one of my goals for this project was to provide an option that does not require --unsafe, the reasoning being that if you can use unsafe code then you would just P/Invoke the native library using POpus or equivalent. So I spent a lot of work depointerizing the code after the initial port. If you want to donate to someone then direct it to these guys who are doing God's work ==> http://ourrescue.org/
@lostromb
one of my goals for this project was to provide an option that does not require --unsafe, the reasoning being that if you can use unsafe code then you would just P/Invoke the native library using POpus or equivalent.
Well, I use your C# libopus in my win64/osx game engine for voice transmiting purposes in multiplayer between players in a team, so on one hand I'm okay with unsafe (performance, after all), on other hand I trying to keep structure of my game engine clean, so I prefer to avoid as much external dependency dlls within my engine folder as possible (so this why I trying to avoid C# wrappers to some popular libraries and prefer ports).
There's ways to do native interop without requiring loose DLLs. Easiest one I know of is to just compile the C code as a CLR assembly and link it directly into .Net. As an example you can look into how LZ4Net does "mixed mode" dynamic safe+unsafe runtime. All of this was possible with Opus before Concentus came along, so I set out to specifically fill the need for ultra-portable Opus code with zero dependencies, hence the lack of unsafe code. (Even then I'm a hypocrite though as there is an unsafe flavor of Concentus I was experimenting with earlier - I still want to see if using fixed arrays on unsafe structs would grant any performance benefit due to better locality)
@lostromb Yeah, LZ4Net good example of this. But, after all, its author decided to go unsafe-only way with LZ4Net rewrite. :) If unsafe-only way will be easier for you to update libopus to 1.2.1 (or latest 1.3-master), then why not? After all, for those who need safe-only -- its possible just to say use current Concentus which is based on 1.1
(in fact I'm curious to see how well it would work
Keep us informed please :)
@lostromb
While that should theoretically work fine (in fact I'm curious to see how well it would work - Opus is highly portable as it is so I'd expect great success
Curious, have you tried? :)
For anyone still looking to work on this issue, I recommend reading RFC 8251 for a set of bugfixes in 1.2. The 8 small patches are well-commentated and should be easier to port than a bunch of features. There are test vectors available too.
