[XviD-devel] Packaging issues, copyright/license check and big drop in performance in 1.2.1 compared to 1.1.2 (amd64)

[Michael Militzer]

Hi,

I'm not really familiar with the task of packaging software and especially
not with Ubuntu and its policies, so bear with me...

To answer your questions:

1. Once we released a tarball without the debian directory the debian
users were unhappy. So removing the debian dir might likely break the
scripts of others. Same with the directory naming. It could certainly be
changed but may come unexpected to others that rely on the current naming.
And I'd be also reluctant to provide multiple variants of the tarballs...

The page 'http://www.xvid.org/downloads.html' will always point to the
current download page. This link is fix since years. The tarballs will also
always be available at 'http://downloads.xvid.org/downloads/'. So it's
rather safe to rely on that.

2. The files you list lacking copyrights are almost all related to the IA64
source code. The xvid IA64 port had been contributed under the GPL-2+ by
students of university of Karlsruhe many years ago.

The files fdct.c, idct.c had been taken from other GPL/LPGL licensed
projects long ago (iirc libmpeg2 and ffmpeg) and are e.g. also part of
current libavcodec. I consider the files to be distributable under GPL.

3. I think the performance drop is suspicious. Are you sure you have compiled
with asm optimizations enabled? Did you have nasm present?

The PPC asm code can be compiled with gcc and has no further dependencies.

Regards,
Michael



Quoting Loïc Martin <loic.martin3 at gmail.com>:

> Hi,
>
> The change in Xvid website might have cause broken Ubuntu's watch file,
> and thus our xvidcore packages are quite old, stuck at 1.1.2
>
> 1. While packaging 1.2.1 I noticed a few issues:
> - would it be possible for you to provide a tarball without any debian
> directory (common practice, which would save having to repackage the
> archive and write a get-orig-source target)
> - can the directory in the tarball be xvidcore-version (same reason as
> above)?
>
> Also, in the interest of keeping distribution's packages up to date,
> would it be possible to provide those tarballs on a fixed page for all
> new releases (I'm not sure is http://www.xvid.org/Downloads.43.0.html is
> that fixed page, and since the files are in another location without
> webpage, I'm not so confident we'll notice new releases). Our watch file
> is as is, if an expert can tell me it will work for new release I'd be
> more confident we won't trail 2 years behind development ;) :
>   http://www.xvid.org/Downloads.43.0.html \
>   http://downloads.xvid.org/downloads/xvidcore-([\d\.]*)\.tar\.gz
>
>
> 2. Since our debian/copyright wasn't really accurate (only one author,
> and a Copyright of 2001) I moved it to Debian's proposed new copyright
> format at http://wiki.debian.org/Proposals/CopyrightFormat and checked
> source files one by one (by far the longest part of the packaging).
>
> I noticed a few files with missing copyright, license or both. I'm
> attaching the list to this email, along with our new debian/copyright
> file if others want to reuse it for their packaging (Debian, for example).
>
> I also have trouble determining the right license for
> src/dct/{fdct.c,idct.c} , are they special license dual licensed with
> GPL-2+ (since the headers only mention the GPL-2+, but the README the
> headers links to says otherwise).
>
>
> 3. I tested 1.2.1 to check for regressions, and the performance has
> dropped enough in amd64 to warrant investigation. Both our packaging and
> the one offered in xvidcore original tarball (in debian) produce
> libraries that shows this behavior. On a timed encode with the short
> video that comes with Ubuntu Jaunty LiveCD:
> time mencoder StopMotioUbuntu.ogv -ovc xvid -xvidencopts -bitrate=2000
> -nosound -o converted.mp4
>
> The encode takes 5.889 sec, againts 1.886 sec with Ubuntu's 1.1.2 packages.
>
> The packaging in your source tarball use nasm (>= 2.0) [i386] (why no
> amd64?), ours use yasm [i386 amd64] but both show the same drop in
> performances.
>
> Is that expected with 1.2.1, or is there a problem somewhere? I'll hold
> updating the package in Ubuntu in case it's the later, and hopefully we
> can then find a solution in time for 1.2.1 to enter Jaunty (Feature
> Freeze is Feb. 19th :( ).
>
> Since I'm at it, I noticed ppc assembler code in the source - should we
> build depend on something for ppc?
>
> The packaging I prepared is at
> https://launchpad.net/~loic-martin3/+archive/ppa
> in case you want to have a look.
>
> Cheers,
> Loïc
>
>
>