Bug#678679: Spice, current status and the fueture in Debian
Hi,
Most of this is Michael's reply, cc'd verbatim to the bug now instead of
to submit@ :)
I have just a couple of small clarifications to add, but agree with Michael
that this doesn't really seem like a question for -ctte, he and I have both
been talking to upstream with mostly productive results, and I have no reason
to doubt at this stage that the people involved won't sort out the best thing
to do amongst themselves - even if that will take a little time to complete
and converge.
On Mon, Jun 25, 2012 at 05:29:09PM +0300, Michael Tokarev wrote:
> 23.06.2012 20:26, Liang Guo wrote:
> >Package: tech-ctte
> >Severity: normal
> >
> >Hi, Technical Committee,
> >
> >We'd like to decide how the spice[1] should be maintained in Debian.
> >
> >1) Background
> >The Simple Protocol for Independent Computing Environments (SPICE) is
> >a remote display system built for virtual environments, just like vnc
> >or remote desktop, but provide more rich feature and better
> >performance. SPICE was developed by Qumranet[2], which was acquared by
> >RedHat, RedHat is the primary sponsor of SPICE and includes it in RHEL
> >(since 5.4) and RHEV platform. Spice has 2 different part, server part
> >and client part, server part is intergrated to qemu, client part can
> >be a standalone program, such as spice-gtk and virt-viewer, or run as
> >a browser plugin. Spice client and spice server communicate with tcp
> >socket. Spice can only works on x86 and i386 platform now.
> >
> >Spice project provide xserver-xorg-video-qxl and spice-vdagent as the
> >guest xserver driver and the guest helper program to provide
> >copy/pause support in qemu/kvm guest OS.
> >
> >2) Celt, the root of our problem
> >Spice uses celt[3] for audio codec. Different celt version may use
> >different bitstream, it means that if Spice client want to correctly
> >decode audio codec from spice server, it should use the same celt
> >version as the spice server. For compatibility or other reason, the
> >upstream decide to pin to celt 0.5.1.
> >
> >Celt is already in Debian[4], and is maintained by Ron Lee. For celt
> >0.5.1 is not maintained by upstream any more, including it in Debian
> >may introduce potential security problem, so we decide to not include
> >it in Debian. this problem has been discussed at bug 603699[5].
> >
> >According messages from Ron, celt is offically dead, the upstream will
> >not maintain it any more. A new codec, opus, is published as RFC by
> >the IETF CODEC working group, and is encouraged to replace celt.
>
> Yes, this is basically the story behind spice and celt.
>
> >Alon Levy is working on adding opus codec support to spice, but it is
> >not merged into upstream git yet. Even opus codec support is added by
> >upstream, in order to compatible with the previous version, they may
> >not remove celt051 codec soon.
> >
> >3) Current status of spice in Debian
> >At the end of the discussion in bug 603699, I decide to package spice
> >with a embeded celt051, and celt051 runtime library is in package
> >libspice-server1[6] now. Spice package is in a bad shape, but it
> >provide the same function as the upstream.
>
> Why do you say the package is in "bad shape" ? Please explain.
>
> Current version in experimental, if not counting the removal of
> celt, should be quite good, no?
>
> I know the library has known bugs (for one, it does not work with
> 32bit userspace at all), but it is upstream bug, and the fix isn't
> easily backportable to current stable version (0.10) -- I tried.
>
> If this is the only issue, we don't have much alternatives here
> (celt issues aside) but to either keep 0.10 ("stable" with known
> bugs), or to update to 0.11 which is a "development" version.
> And this is a good question to ask/answer. However, I don't
> think ctte is the right contact for this... ;)
>
> >Spice client program, spice-client and spice-gtk depends on
> >libspice-server1, for they uses celt runtime library.
> >
> >xserver-xorg-video-qxl and spice-vdagent are in Debian and in a
> >good shape.
> >
> >According the Popcon statistics[7], 0.13% Debian users uses
> >spice-client, 3.21% Debian uses uses libspice-server1(for qemu/kvm
> >depends on libspice-server1, this can be traded as qemu users),
> >so 4% qemu/kvm user uses spice-client.
> >
> >4) The fueture
> >4.1 Remove spice celt051 support in Debian
> >Actually spice support another codec: RAW, when using raw codec, audio
> >streams is not compressed, so more bandwidth is consumed, When using
> >spice in Internet, the latency will become large and introduce bad
> >user experience.
This is not correct. For raw PCM audio, the latency, if anything, will
become *smaller* - potentially many orders of magnitude smaller.
But my guess is that it will probably be identical, with their protocol
using the same packet size for both. The minimum packet size (and hence
latency) is much, much, smaller for raw PCM than it is for a frequency-
domain codec like celt.
As a general rule for audio coding, improvements in latency *always*
come at the cost of additional bandwidth requirements, and that's
true for the lowest latency modes of celt/opus as well. It shouldn't
take much math to see why that is a fairly fundamental invariant.
> This is what some upstream developers are saying: don't remove/disable
> celt051 due to some "bad user expirence" this causes. Without audio
> compression, spice will be less useful on slow links since audio will
> work worse (require more bandwidth, will be jumpy or not work at all).
> Note there's no bandwidth requirements on spice site at all, be it
> with celt or without.
And this concern seems like a red-herring, since even raw PCM audio will
consume only a tiny portion of the bandwidth needed for video. If you
don't have enough bandwidth for it, your user experience is going to be
bad even if you don't use audio at all :) But this was also rebutted by
other upstream developers too and I didn't see any consensus there on it
actually being a significant concern to people who had really thought
about it in any detail.
> >Michael have tested the compatibility for spice server with and
> >without celt051 and spice client with and without celt051, and send
> >the patch[8] to the upstream, but the upstream refused to apply this
> >patch, they insist spice should come with celt051 support now.
In the most recent discussion on spice-devel there was a fairly broad
spectrum of opinions, with only one or two people dissenting from the
idea that the constraints and requirements of Fedora and Debian differ,
and that Debian disabling celt now (with Fedora to do it some time in
the future) would cause any sort of real problem for either of us.
There is no security support for celt 0.5.1 (or any later version now)
and a real concern that there are issues in the 0.5.1 release. Most
of the upstream developers recognise this, but it will take them time
to organise a transition that suits Redhat's customers. It seems to
be reasonably certain that they will have done that before Wheezy's
support cycle is ended - so it seems equally reasonable for us to act
on this now, even if they don't also do it immediately. There is
nearly 6 months still before their next distro release is due.
> I have run some tests, yes, but I'm really not sure I did it right,
> since I don't really know how to ensure the audio is transferred
> using spice and not by using some other mean.
>
> >We can apply this patch and ship spice without celt in Debian, but for
> >we are not expert on spice and celt, and lack necessary device to test
> >the compatibility with the upstream release, we may in the risk of
> >shipping spice that not compatible with spice in other distribution.
>
> And there's one more issue here. Reportedly (according to upstream
> spice developers), a) some older versions of spice didn't support
> RAW audio stream properly (were buggy), so these wont work with
> "celt-crippled" version of spice, but I for one didn't find definitive
> answers about which versions were buggy and how and where these were
> shipped with. And b) even the current version of spice hasn't really
> been tested much in RAW audio stream mode. I'd not be surprized if
> the only tests of this mode ever made were mine, but I'm not even sure
> I actually ran spice-transferred audio or not. So there's alot of
> uncertainity in there.
>
> >4.2 Completely remove spice
> >If spice is removed from Debian, We will not able to use debian as a
> >spice server or spice client.
>
> This is a bad move, since spice is very frequently used feature with
> qemu/kvm, and we'll have to deal with possible incompatibles within
> libvirt too, who may expect to use spice-enabled qemu/kvm. But it
> is definitely one of possible solutions.
>
> >We can still run Debian in RHEV or other spice compatible qemu/kvm
> >hypervisor, xserver-xorg-video-qxl and spice-vdagent don't use celt.
>
> >Thank you for your kindly help.
>
> Now, I think the best course to take is:
>
> 1) push current experimental, celt-less version to unstable,
> after some basic verifications of audio.
> 2) maybe update to 0.11, to at least fix known bugs.
> It is unclear whenever upstream will support 0.10 "stable" version, but it is more
> "no" than "yes", or else the 32bit bug should have been fixed long ago.
> 3) depending on the result (if it "works at all" or not ;), either keep it
> this way or drop it from wheezy entirely.
I agree with this as the best immediate plan of action.
> 4) if it will work okay, maybe we'll have a chance before wheezy release to
> have a patch that will enable opus codec, or even a new upstream release (0.12),
> but that is unclear for now ofcourse - whenever it will be ready and whenever
> it will be okay to update it this way during freeze.
It seems unlikely that the patch to 0.12 will be something the release team
will be keen to grant a freeze exception for (since I'm guessing it will be
quite large), so that probably will need to be targetted at bpo after the
release, or experimental during it. But we can assess all this as it
really happens, when it really happens.
> Sure thing the best will be to have opus support in spice in wheezy. And
> this is the most close variant I can think of.
>
> But I need an answer to the previous question: why are you saying the package
> is in "bad shape", and what do you think is needed to fix that. If you can,
> please do so and perform an upload to unstable -- unfortunately I can't do
> that from here, the internet access in the hotel I'm currently in is crappy
> at _best_... :(
>
> Thank you!
>
> /mjt
>
> >[1] http://www.spice-space.org/
> >[2] http://en.wikipedia.org/wiki/Qumranet
> >[3] http://celt-codec.org/
> >[4] http://packages.debian.org/search?keywords=celt&searchon=names&suite=all§ion=all
> >[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603699
> >[6] http://packages.debian.org/sid/amd64/libspice-server1/filelist
> >[7] http://qa.debian.org/popcon.php?package=spice
> >[8] http://lists.freedesktop.org/archives/spice-devel/2012-June/009410.html
> >Thanks and Regards,
> >--
> >Liang Guo
> >http://bluestone.cublog.cn
Cheers,
Ron
Reply to: