[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Spice-devel] Bug#603699: ITP: celt051 -- The CELT codec v0.5.1


The reason spice is still using celt-0.5.1 is that celt as
a protocol / format is considered not finished yet by celt
upstream and thus the bitstream format may change (and does
change) with every new upstream release.

In order to provide compatibility between different spice
client and server versions we've frozen the celt bitstream
protocol as used in spice at version 0.5.1

On 11/17/2010 04:25 AM, Liang Guo wrote:
Add Cc to spice-devel list

On Wed, Nov 17, 2010 at 5:11 AM, Adrian Knoth<adi@drcomp.erfurt.thur.de>  wrote:
Ok, you'll lose backward compatibility to non-celt-0.9 installations
already deployed and not being able to update... but who's using them?
And who will be using them by 2011?

RHEL6 and fedora are using spice with celt051,  even if after several
years development, spice can use a stable version of celt(maybe 1.0),
spice may consider  backward compatible to support celt051 in the
future. so there will be plenty of spice server with celt051 support
for many years.

If there's such a legacy user base, then I suggest to embed your private
copy of celt-0.5.1 into the spice client source. For everyone else, it's
the wrong signal to expect any CELT version (below 1.0) to be widely
installed anywhere.

So strictly speaking: it's possible for spice to support more than one
celt version (as shown above) without ruining backward compatibility.
In Debian, only provide the newest celt version. If need be, embed
celt-0.5.1 into spice, but the other approach would be to entirely
ignore this 0.5.1 thing.

This way, there'll be support for newest celt with the fallback to raw
audio transfer (DATA_MODE_RAW).

It looks like we have following options:

1 Package celt051 and spice in Debian, for spice and packaging
works, it is a good option, after spice switch to the latest version
celt and not use celt051 any more, we may remove celt051 in
Debian archive. but there will be two different celt version 0.5.1 and
the latest in Debian.

Yes this would be the right solution. Note I think it would be great to
have spice in Debian and I would be happy to help with any issues you may

2 Embed celt051 to spice, this option will add workload and
complexity of packaging, and violate the Debian Policy 4.13[1], the
advantage is Debian have only one version of celt.

Although I'm only one member of the spice upstream team / community
I think I can speak on behalf of upstream when saying we won't take
patches to enable something like this. You're of course free to
patch configure and the Makefiles in Debian to enable this, but we
won't take such patches upstream.

3 Patch spice to remove depends on celt0.5.1, just let spice use
only RAW codec. When connect to spice server. other spice client
connect to Debian spice server, we will get high latency, high
bandwidth consume audio. I'm not sure this option works.

Please do not do this, this may break compatibility with none Debian
spice versions and even if it does not it will make us look bad.

4 Do nothing, wait spice to switch to latest celt, or work on spice to
switch to latest celt or at least support latest celt and celt 0.5.1, it
will be matter long long before. Within this period, Debian can only
run as a RHEV or spice-enabled qemu  Guest OS.

Again I'm only one member of the spice upstream team. But AFAIK
our (upstreams) stance on this is that we won't switch to a newer celt
until the bitstream protocol is stable, if at all.

The if at all part depends on if it will be doable without too much
pain to support both celt-0.5.1 and celt "1.0" in the same binary.
This is important to us as we care a lot about protocol

Which is in downstreams best interest too btw, otherwise one gets a
situation like with unison were distros need to package multiple versions
so that users can talk to different servers with different versions,
ie in Fedora we have both unison213 and unison227.

Thanks & Regards,


Reply to: