<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Implement opus audio compression" href="https://bugs.freedesktop.org/show_bug.cgi?id=56993#c13">Comment # 13</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Implement opus audio compression" href="https://bugs.freedesktop.org/show_bug.cgi?id=56993">bug 56993</a> from <a class="email" href="mailto:tanuk@iki.fi" title="Tanu Kaskinen <tanuk@iki.fi>"> Tanu Kaskinen</a> <pre>(In reply to Arun Raghavan from <a href="show_bug.cgi?id=56993#c12">comment #12</a>) > FWIW, if the compression were just limited to being within the tunnel > modules, I would have said it might be okay to add this in, since it can > always be replaced with something more generic in the future. The patch does > add this via public API, though, so that part makes it a no-go from my > perspective. I don't like the public API changes either, but if we assume that those can be eliminated, are you against adding opus support to the native protocol? As far as I can see, it's not possible to limit this to just the tunnel modules, because they use the native protocol and the other end doesn't have any special handling for tunnels, they are just normal client connections. Even if we were to use GStreamer instead of libopus, I think the native protocol would have to specifically support opus. We can't offload the codec negotiation to GStreamer in the native protocol (in the RTP modules we might be able to do that). So, are you against any compression support in the native protocol or not?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>