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

[Hans de Goede]

Hi,

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 at 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
encounter.

> 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
compatibility.

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,

Hans