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

[Ron]

On Wed, Nov 17, 2010 at 03:48:36PM +0100, Gerd Hoffmann wrote:
> On 11/17/10 13:04, Ron wrote:
> >Are you seriously telling me that you have no plan whatsoever for how
> >to transition from a random snapshot of an experimental codec,
> 
> We can transition just fine.  server + client can signal supported
> codecs using capabilities.  We can even support something completely
> different such as ogg or mp3 (once the patents are expired).  We
> just don't want transition from one random celt snapshot to another
> random celt snapshot and the next random celt snapshot next year.

Ok.  That's better than the picture that had come out so far.
So really, we don't actually have a problem, beyond having to accept
the on the ground truth that there is going to be some codec divergence
between distros for a while.  Maybe for another year or two.

That's suboptimal, but it's not a showstopper.

> > But so far, all have accepted this _is_ an experimental
> >codec, and they must be prepared to move with it.  The interested app
> >maintainers and upstream discussed this, and we settled on 0.7.1 as the
> >next stable epoch for things that want broad interoperability.
> 
> We settled on 0.5.1 for interoperability.
> 
> /me figures the latest celt version is 0.9.1.  The web page lists
> both 0.5.1 and 0.7.1 in the "provided mainly for historical reasons"
> section.  So you picked a random snapshot too, just another one.

Well celt has been in debian since 0.3.0 and nobody has _ever_ talked to
us about 0.5.1 before now.  If you weren't about for the 0.7.1 discussion
then I'm sorry you got missed, but there was a pretty solid consensus.
Consider it this year's snapshot.  There's already been at least one
derivative distro that has released with it.

> >Are you aware there may never be a celt 1.0?  We have roughly 2 years
> >from today before any version of spice will have a chance to be even
> >considered for the next Debian stable release - and if things go as
> >expected, it will not include any version of celt at all.  There will
> >instead be a new (and standardised) codec that was spawned from it and
> >merged with other codec work.
> 
> When celt merges with others and gets renamed in that process -- no
> problem.  Once the bitstream format is stable we'll happily support
> it.  But even then we will not drop celt 0.5.1 support to maintain
> compatibility with older installations.

Ok, that's fine.  But that really doesn't mean every other distro needs
to also worry about that.  It's not ideal, but this is a work in progress.
It can release with Debian when it's ready.

> >If that means an update to the spice bitstream protocol, now might be a
> >good time to explore one.
> 
> Isn't going to happen.
> 
> If you don't want package celt 0.5.1 -- fine.  You can patch your
> spice server and client to just not signal the celt capability, and
> they will interoperate just fine with everybody else using raw
> uncompressed audio.  But IMHO it would be stupid to not support
> audio compression in your spice packages.  That is your call though.

It would be stupid if 0.5.1 was the only choice for compression.
There isn't going to be a Debian release with spice in it for around
2 years now in the best case, so if there isn't another suitable choice
available by then, then something worse than this has gone badly wrong.

Why not just let systems negotiate the best codec they both know?

 Ron