New upstream version available (1.2.2)

[Serge Maslov]

Xvid 1.2.2 released.

Changes since 1.2.1:

* xvidcore library
     - Workaround for nasm bug with MACHO/OSX target
     - Fix for missing resync marker range check (reported by IBM ISS)
     - Improved precision for RGB<->YUV conversions
     - Fix for potential RGB24 access violation
     - Updated compiler options for Apple PPC target
     - Fixed MSVC6 projects to work for path names with spaces

* VFW frontend
     - Updated mingw makefile

* DShow frontend
     - Bugfix for wrong handling of xvidcore XVID_ERR_MEMORY
       return code (reported by IBM ISS)

Changes since 1.2.0:
xvidcore library
 * Fix for 'nested function' potential compilation error
 * WIN64 fix: Properly treat xmm6/xmm7 registers as non-volatile on WIN64
 * Added test for WIN64 xmm6/xmm7 preservation to xvid_bench
Changes since 1.1.3:
xvidcore library
 * Complete AMD64/EM64T 64-bit support
 * Added support for WIN64 platform
 * Multi-threaded encoding support
 * SSE3/SSE4 optimizations
 * Faster and more precise mpeg intra quantization
 * Fixed bug in packed pixel format colorspace conversion
 * Noexec-stack security patch
 * Fix for bad resync marker length
 * Improved decoder robustness for broken streams containing B-frames
 * Fix for potential out-of-bound access to MV bits table
 * Added SSIM quality-metric plugin
VFW frontend
 * WIN64 compatibility
 * Added widgets for SSE3/SSE4
 * Auto-detection of available processor cores
 * Minor GUI cosmetics
DShow frontend
 * WIN64 compatibility
 * Minor GUI cosmetics

Please, update package!

[Alexander Ponyatykh (lazyranma)]

Hello!
I've made the updated package. It's my first attempt to build something for Ubuntu, so I'm not sure if I did everything right. but anyway here it is:
Original tarball: http://downloads.xvid.org/downloads/xvidcore-1.2.1.tar.gz
Diff file attached.

[Alexander Ponyatykh (lazyranma)]

The last version had problems with ./configure. Here is the new one.

[Loïc Martin (loic-martin3)]

I've got working packages, they're at my ppa for Jaunty and Intrepid. I'm not uploading the diff.gz now because amd64 packages show about 40% decrease in performance compared to 1.1.2 packages in Ubuntu's repositories (timed conversion of StopMotionUbuntu.ogv (in the Free Culture Showcase) is at 5.6 sec. compared to 1.9 sec in 1.1.2.
 The problem also appear upstream, I tested compiling from source, so it's not an Ubuntu package issue.

I'll get in touch with upstream before submitting an diff.gz in this bug. In the meantime people can test the i386 packages, or I'll do that later if I have the time. If upstream confirms the decrease in speed is expected (higher default quality options maybe?) I'll attach it, else I'll probably wait till the problem is corrected.

Packages are at : https://launchpad.net/~loic-martin3/+archive/ppa

You can test easily with :
time mencoder StopMotioUbuntu.ogv -ovc xvid -xvidencopts -bitrate=2000 -nosound -o converted.mp4

Alexander Ponyatykh, thanks for your work. You should hang out in #ubuntu-motu on freenode irc, there's plenty of people ready to offer advice and your good work is welcome!

I checked your diff.gz a bit, you should have a look at https://wiki.ubuntu.com/PackagingGuide/Complete#Recipe:%20Updating%20An%20Ubuntu%20Package and possibly https://wiki.ubuntu.com/MOTU/Videos (see http://www.youtube.com/watch?v=JJzM2LNOtWU ).
I didn't use it though, for some of the reasons expressed in the guide (don't reuse upstream debian diredctory, especially when there's already a source package in Ubuntu), but also because of some of the reasons expressed in my changelog:

  * New upstream release (LP: #306399);
  * [debian/control]:
    - bump Standards-Version to 3.8.0;
    - bump debhelper to 5;
    - add myself as uploader.
  * [debian/copyright]: author the file, each source file checked for author
    and license, forward files with missing/incomplete information upstream;
  * [debian/patches]: drop patches, applied upstream;
  * [debian/rules]: write a get-orig-source target to repackage tarball (drop
    upstream debian directory, change directory name from xvidcore to
    xvidcore-1.2.1);
  * [debian/watch]: adapt the file to the new site.

[Loïc Martin (loic-martin3)]

Here is a working and tested diff.gz:. No regressions for speed, asm enabled on both i386 and amd64 this time. Package has been tested in Jaunty i386 and amd64, packages are also on my ppa at https://launchpad.net/~loic-martin3/+archive/ppa

xvidcore (2:1.2.1-0ubuntu1) jaunty; urgency=low

  * New upstream release (LP: #306399);
  * [debian/control]:
    - change Build-Depends from yasm to nasm (yasm doesn't work anymore, see
      http://list.xvid.org/pipermail/xvid-devel/2009-February/006054.html);
    - bump Standards-Version to 3.8.0;
    - bump debhelper to 5;
    - add myself as uploader.
  * [debian/copyright]: author the file, each source file checked for author
    and license, forward files with missing/incomplete information upstream;
  * [debian/patches]: drop patches (01_ia64_fix, CVE-2007-3329), applied
    upstream;
  * [debian/rules]: write a get-orig-source target to repackage tarball (drop
    upstream debian directory, change directory name from xvidcore to
    xvidcore-1.2.1);
  * [debian/watch]: adapt the file to the new site.
  * [debian/README.source]: create the file to document repackaging.

 -- Loïc Martin <email address hidden> Thu, 19 Feb 2009 12:34:12 +0100

Here is the upstream Changelog:

Changes since 1.2.0:
xvidcore library

    * Fix for 'nested function' potential compilation error
    * WIN64 fix: Properly treat xmm6/xmm7 registers as non-volatile on WIN64
    * Added test for WIN64 xmm6/xmm7 preservation to xvid_bench

Changes since 1.1.3:
xvidcore library

    * Complete AMD64/EM64T 64-bit support
    * Added support for WIN64 platform
    * Multi-threaded encoding support
    * SSE3/SSE4 optimizations
    * Faster and more precise mpeg intra quantization
    * Fixed bug in packed pixel format colorspace conversion
    * Noexec-stack security patch
    * Fix for bad resync marker length
    * Improved decoder robustness for broken streams containing B-frames
    * Fix for potential out-of-bound access to MV bits table
    * Added SSIM quality-metric plugin

VFW frontend

    * WIN64 compatibility
    * Added widgets for SSE3/SSE4
    * Auto-detection of available processor cores
    * Minor GUI cosmetics

DShow frontend

    * WIN64 compatibility
    * Minor GUI cosmetics

Changes since 1.1.2:
xvidcore library

    * Fixed a potential vulnerability in mbcoding.c reported by Trixter Jack at Secunia

[Scott Kitterman (kitterman)]

What testing of this has been done?

[Loïc Martin (loic-martin3)]

Here is a working and tested diff.gz:. No regressions for speed, asm enabled on both i386 and amd64 this time. Package has been tested in Jaunty i386 and amd64, packages are also on my ppa at https://launchpad.net/~loic-martin3/+archive/ppa

xvidcore (2:1.2.1-0ubuntu1) jaunty; urgency=low

  * FFe request : New upstream release (LP: #306399);
  * [debian/control]:
    - change Build-Depends from yasm to nasm (yasm doesn't work anymore, see
      http://list.xvid.org/pipermail/xvid-devel/2009-February/006054.html);
    - bump Standards-Version to 3.8.0;
    - bump debhelper to 5;
    - add myself as uploader.
  * [debian/copyright]: author the file, each source file checked for author
    and license, forward files with missing/incomplete information upstream;
  * [debian/patches]: drop patches (01_ia64_fix, CVE-2007-3329), applied
    upstream;
  * [debian/rules]: write a get-orig-source target to repackage tarball (drop
    upstream debian directory, change directory name from xvidcore to
    xvidcore-1.2.1);
  * [debian/watch]: adapt the file to the new site.
  * [debian/README.source]: create the file to document repackaging.

 -- Loïc Martin <email address hidden> Thu, 19 Feb 2009 12:34:12 +0100

Here is the upstream Changelog:

Changes since 1.2.0:
xvidcore library

    * Fix for 'nested function' potential compilation error
    * WIN64 fix: Properly treat xmm6/xmm7 registers as non-volatile on WIN64
    * Added test for WIN64 xmm6/xmm7 preservation to xvid_bench

Changes since 1.1.3:
xvidcore library

    * Complete AMD64/EM64T 64-bit support
    * Added support for WIN64 platform
    * Multi-threaded encoding support
    * SSE3/SSE4 optimizations
    * Faster and more precise mpeg intra quantization
    * Fixed bug in packed pixel format colorspace conversion
    * Noexec-stack security patch
    * Fix for bad resync marker length
    * Improved decoder robustness for broken streams containing B-frames
    * Fix for potential out-of-bound access to MV bits table
    * Added SSIM quality-metric plugin

VFW frontend

    * WIN64 compatibility
    * Added widgets for SSE3/SSE4
    * Auto-detection of available processor cores
    * Minor GUI cosmetics

DShow frontend

    * WIN64 compatibility
    * Minor GUI cosmetics

Changes since 1.1.2:
xvidcore library

    * Fixed a potential vulnerability in mbcoding.c reported by Trixter Jack at Secunia

[Loïc Martin (loic-martin3)]

Scott Kitterman:
I tested encoding with mencoder on both i386 and amd64 Jaunty, and checked there was no speed regression (it's actually slightly better on amd64) which was the reason I didn't want to upload the diff.gz on Monday. Sadly it took longer than I expected to solve the regression.

[StefanPotyra (sistpoty)]

Have you checked rebuilding the rdepends yet?
Also, can you please attach a diff of the symbols of libxvidcore4?

Generally, in case there's no ABI breakage, it's ok to bring this in *now*, but I'd also like to ask input from Mario (as mythtv is one of the consumers of xvidcore)

[StefanPotyra (sistpoty)]

@Mario: Any opinion on xvidcore?

[Luca Falavigna (dktrkranz)]

> Xvid 1.2.1 released.
> xvidcore library
> * Complete AMD64/EM64T 64-bit support

Has it been tested for AMD64? I see it's currently built for that
architecture too, is current version not functional?

[Mario Limonciello (superm1)]

I would much prefer to see some builds on a PPA of the rdepends (including mythtv) before agreeing to this. That would also give us an opportunity to verify no regressions have come up properly instead of just "Yeah... it should work"

[Scott Kitterman (kitterman)]

ack from me

[Scott Kitterman (kitterman)]

On Thu, 19 Feb 2009 13:47:32 -0000 StefanPotyra
<email address hidden> wrote:
> but I'd also like to ask input from Mario (as mythtv is one of
>the consumers of xvidcore)
>
Good point. Yes, please.

[Luca Falavigna (dktrkranz)]

LoIc, Mario: any news on this?

[Mario Limonciello (superm1)]

Did it get posted to a PPA yet with the rdepends? Would like to test it before agreeing.

[Loïc Martin (loic-martin3)]

I've been moving the past few days (that was a really short notice and unexpected), and am still in the process of unpacking things ;)

The packaging I've submited in the diff.gz on 19/02 isn't satisfying, after having done what people advised in their answers I noticed the simlinks aren't created in the right way, and I need to fix that first. The package + rdepends has been on my ppa at https://launchpad.net/~loic-martin3/+archive, all the rdepends build fine when the symlinks aren't set correctly, but gts-plugins and mpeg4ip fails to build with a newer version of the packaging (that version has the right symlinks for libxvidcore, but not for libxvidcore-dev).

I need to figure how to correct the symlink first, then rebuild. I should have more time to spend on this issue in a few days.

I'm attaching the diff of the symbols of libxvidcore4, I wanted to wait till the packaging was fixed before uploading it, but moving got in the way.

[StefanPotyra (sistpoty)]

any news on this one? If you can't get to it soon, I guess it'll be too late for jaunty.

[Loïc Martin (loic-martin3)]

Hi Stefan,
As long as I dropped the Beta freeze deadline, I should have stopped the request for FF ;)

I still have two packages failing to build with xvid 1.2.1 libs locally (the same that didn't build on my ppa), and I still don't have broadband, so it's hard to troubleshoot it at the moment.

You can safely remove MOTU release team, I'll try to upload the package at the beginning of the Karmic cycle and get people help me fix the FTBFS issues at that time.

[StefanPotyra (sistpoty)]

ok, thank, unsubsribing motu-release.

[Loïc Martin (loic-martin3)]

xvidcore (2:1.2.1-0ubuntu1) karmic; urgency=low

  * New upstream release (LP: #306399);
  * [debian/control]:
    - change dependency from yasm to nasm (can be reverted once we package
      xvid 1.3+);
    - bump Standards-Version to 3.8.0;
    - bump debhelper to 5;
    - add myself as uploader.
  * [debian/changelog]: bump Standards-Version to 3.8.0, debhelper to 5;
  * [debian/copyright]: author the file, each source file checked for author
    and license, forward files with missing/incomplete information upstream;
  * [debian/patches]: drop patches (01_ia64_fix, CVE-2007-3329), applied
    upstream;
  * [debian/rules]:
    - write a get-orig-source target to repackage tarball (drop upstream
      debian directory, change directory name from xvidcore to
      xvidcore-1.2.1);
    - changes in dhlink and dh_install lines (inspired from upstream) so it
      creates the right links for this version and hopefully future ones;
  * [debian/watch]: adapt the file to the new site;
  * [debian/README.source]: create the file, document repackaging.

 -- Loïc Martin <email address hidden> Sat, 09 May 2009 19:06:05 +0200

[Loïc Martin (loic-martin3)]

Package is now ready, test builds for rdepends are at https://launchpad.net/~loic-martin3/+archive/xvid

Avidemux, mplayer (and for lpia mythtv) FTBFS are not due to this new version of xvidcore:
- they fail to build on default Karmic too (see https://launchpad.net/~loic-martin3/+archive/fail);
- they build ok with this xvidcore 1.2.1 on Jaunty (see https://launchpad.net/~loic-martin3/+archive/xvid)

Note that any upload should wait till Aplha 1 Freeze is over, since it should affect Mythubuntu.
Siretart said today that he'll work on mplayer in the next few weeks, I don't know who's going to take care of avidemux (but again, the FTBFS is independent from this xvidcore package).

[Maia Everett (linneris)]

While I appreciate the work you did on the original package, xvidcore has been traditionally merged into Ubuntu from debian-multimedia.org: http://debian-multimedia.org/pool/main/x/xvidcore/

Perhaps you could prepare a debdiff for its version 1.2.1-0.0?

[Loïc Martin (loic-martin3)]

If you think the packaging is better, please go ahead and do so. I won't.

[Loïc Martin (loic-martin3)]

Forgot the changelog. As always, packages available at https://launchpad.net/~loic-martin3/+archive/xvid for both Karmic and Jaunty.

xvidcore (2:1.2.2-0ubuntu1) karmic; urgency=low

  * New upstream release (LP: #306399);
  * [debian/control]:
    - change dependency from yasm to nasm (can be reverted once we package
      xvid 1.3+);
    - bump Standards-Version to 3.8.1;
    - bump debhelper to 5;
    - add myself as uploader;
    - improve long and short descriptions, add ASP after MPEG-4 to differentiate
      from MPEG-4 AVC codecs.
  * [debian/copyright]: author the file, each source file checked for author
    and license, forward files with missing/incomplete information upstream;
  * [debian/patches]: drop patches (01_ia64_fix, CVE-2007-3329), applied
    upstream;
  * [debian/rules]:
    - write a get-orig-source target to repackage tarball (drop upstream
      debian directory, change directory name from xvidcore to
      xvidcore-1.2.1);
    - changes in dhlink and dh_install lines (inspired from upstream) so it
      creates the right links for this version and hopefully future ones;
    - overall cleanup (+patching system will probably move to quilt on Debian
      side, no patches at the moment).
  * [debian/watch]: adapt the file to the new site;
  * [debian/README.source]: create the file, document repackaging;
  * [debian/*.dirs and debian/*.install]: create the files.

 -- Loïc Martin <email address hidden> Fri, 29 May 2009 14:48:28 +0200

[Alessio Treglia (quadrispro)]

works fine, Martin, please upload it

[Daniel Holbach (dholbach)]

Alessio: Loïc can't upload yet. Maybe you can sponsor it.

Did this pass https://wiki.ubuntu.com/FreezeExceptionProcess already?

[Alessio Treglia (quadrispro)]

No, it didn't.

Loïc, could you provide all the information needed to ask for an FF exception?

[Loïc Martin (loic-martin3)]

The packaging in the diff.gz is from May. Now xvid is maintained by Debian Multimedia (=pkg-multimedia) in Debian, by Fabian Greffrath. The new packaging has moved to CDBS, which I don't use nor pretend to understand, so I haven't been able to contibute to it.

You probably want more Reinhard Tartler's opinion (Siretart), since he's looking over it and also maintaining all the packages that would have to be rebuilt on the new xvidcore. He's in a better position to decide if it's worth the trouble, and if it should go fine.

As for regression problems, I tested both 1.2.1 and 1.2.2 intensively in May, but that didn't help for getting it into Ubuntu anyway. Demudi's packaging isn't exactly the same as the binaries I tested (they depend on yasm now that yasm 0.8 is in Debian and Ubuntu), but hopefully should work as well.

[Loïc Martin (loic-martin3)]

Just forgot to paste the link ;)
http://git.debian.org/?p=pkg-multimedia/xvidcore.git;a=summary

[Maia Everett (linneris)]

I'm going to branch Ubuntu changes in git and then upload an update for lucid. From what I can tell, there are no changes needed compared to the Debian version - all previous Ubuntu patches have been applied upstream.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xvidcore - 2:1.2.2+debian-0ubuntu1

---------------
xvidcore (2:1.2.2+debian-0ubuntu1) lucid; urgency=low

  * Fakesynced new upstream release from the debian-multimedia git repository.
    (LP: #306399)
  * Dropped Ubuntu patches, all applied upstream:
    - 01_ia64_fix.dpatch
    - 50_non-exec-stack.dpatch
    - CVE-2007-3329.dpatch
 -- Maia Kozheva <email address hidden> Fri, 20 Nov 2009 12:48:09 +0600