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

[Loïc Martin]

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


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xvid license pb
Url: http://list.xvid.org/pipermail/xvid-devel/attachments/20090218/9c717b60/xvidlicensepb.ksh