https://bugs.freedesktop.org/show_bug.cgi?id=56993
--- Comment #14 from Arun Raghavan <a...@accosted.net> ---
(In reply to Tanu Kaskinen from comment #13)
[...]
> 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).
In the RTP case, I imagine the negotiation would be part of configuration for
the module (therefore in PA), and that is okay. It's particularly working with
the compressed bitstream (encoding/decoding/parsing) that I think does not
belong in PA.
> So, are you against any compression support in the native protocol or not?
I am not in favour of having encoding/decoding being part of our protocol. This
added complexity in the native protocol is not worth the gains for the (imo)
relatively uncommon use-case of tunnel modules.
I'm not against the native protocol supporting compressed audio. i.e. clients
providing compressed audio for devices that support compressed playback. in
fact, this is something I would actively like to have, but there are tricky
bits to deal with latency reporting, rewinds, etc.
That said, if we had this, then the tunnel modules themselves could do the
encode/decode.
I am curious about your views on this -- do you think this is something we
should add to the native protocol, or are you batting for this since the work
has been done, or ...?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
_______________________________________________
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs
