On Mon, Jun 25, 2012 at 05:29:09PM +0300, Michael Tokarev wrote:
> 23.06.2012 20:26, Liang Guo wrote:
> >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?
IMO, spice 0.10.1-3~nocelt in experimental is in good shape, spice
0.10.1-2 with celt embedded in sid is not.
Embedding celt in spice cause celt not available in other
archetecture, if other package ,spice-gtk for example, need
celt, it wll be limited to spice supported archetecture.
> >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 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.
>
> >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.
>
> 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.
How can we test spice with celt removed to make sure it works fine? if we
can and we do the test. I think it's OK to ship spice without celt to wheezy,
and no technical committee decision is needed.
Consider another situation, we can do some simple test aganst spice with
our patch that removes celt support, spice client {with, without} celt can
connect to spice server {with, without} celt, and audio works, but we cannot
test spice without celt with older spice used by other platform, should
we include our spice without celt to wheezy or remove it? This is what
I want technical committee to help us to decide.
(I assume upstream will test celt with older release, but I know nothing
about upstream work flow).
> 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.
>
> 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.
I think opus should be added upstream first, then backported to debian or wait
upstream release a version with opus support. If we add opus support ourself,
upstream may add opus support with a way that may not compatible with us, then
we will be in a passive position.
> 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
Thanks and Regards,
--
Liang Guo
http://bluestone.cublog.cn
Attachment:
signature.asc
Description: Digital signature