libopus 1.2.1

[mizutechvoip]

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.

[lostromb]

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

[mizutechvoip]

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.

[lostromb]

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.

[mizutechvoip]

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!

[Krakean]

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

[lostromb]

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/

[Krakean]

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

[lostromb]

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)

[Krakean]

@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 :)

[Krakean]

@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? :)

[Krakean]

@lostromb ping :)

[lostromb]

I'm too busy with other stuff right now, sorry

[Artoria2e5]

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.