The first pass encoding framerate using media-libs/xvid-1.1.3-r3 on ~amd64 is 2-3 times slower than using the same source video and settings on updated Mandriva 2008.1 x86_64 on the same machine. Reproducible: Always Steps to Reproduce: 1. On ~amd64 emerge media-libs/xvid and media-video/avidemux 2. Start encoding with xvid in two pass mode for a target video size with Quarter Pixel, ultra high motion search precision, ultra wide motion search and MPEG matrix. The computed target bitrate is about 1940kbps here. 3. The first pass framerate is 2-3 times slower than with updated Mandriva 2008.1 x86_64 on the same machine, got about 30/s when expected above 80/s. Only one xvid thread is running. Both for autodetection and manual setting for 2,3,4 threads in avidemux. Actual Results: The first pass framerate is 2-3 times slower than with updated Mandriva 2008.1 x86_64 on the same machine. Expected Results: Above 80 frames per second for the first pass. I tried to use libxvid.so.4.1 from Mandriva in Gentoo and got the same results. It is runnung in KDE session. The media-libs/libmpeg2 is 0.4.1. I probably does not see something, shoud I compile media-libs/libmpeg2 and media-libs/xvid with -msse2? Or -march="something"? Please see attached info.txt. Thank you.
Created attachment 160383 [details] Needed informations.
The 2nd pass is doing about 2.57 per sec.
Created attachment 160439 [details] Lspci -v and kernel .config
Does not applying the xvid-1.1.0-3dnow-2.patch patch when building fix the performance issue for you?
We are experiencing the same problem and have tracked it down to an old Gentoo specific patch (portage/media-libs/xvid/files/xvid-1.1.0-3dnow-2.patch) that attempts to fix a problem with lack of 3dnow support on EM64T (see bug #129022). It is still applied today even though the problem was fixed years ago by the xvid team: $ cvs log src/xvid.c (snip) revision 1.67 date: 2006/01/09 00:39:43; author: Isibaar; state: Exp; lines: +2 -2 - fix for EMT64 platform (snip) $ cvs diff -r1.66 -r1.67 src/xvid.c (snip) - emms = emms_3dn; + emms = emms_mmx; (snip) As far as I can tell, the Gentoo patch makes xvidcore fall back to a pure C implementation if 3dnow is not detected. The problem is worsened further by the fact that xvid's 3dnow detection fails on at least two contemporary AMD CPUs: (from /proc/cpuinfo) model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ model name : Dual Core AMD Opteron(tm) Processor 270 This was determined by writing a small program that calls check_cpu_features() in src/utils/x86_64_asm/cpuid.asm; check_cpu_features() & XVID_CPU_3DNOW == 0 on the above CPUs which clearly have 3dnow support. Removing the 3dnow patch from the ebuild causes a ~2x performance boost (and of course no segfaults) on the following platforms: model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ model name : Dual Core AMD Opteron(tm) Processor 270 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz
Created attachment 174974 [details] ebuild that fixes this problem Removes "epatch "${FILESDIR}"/${PN}-1.1.0-3dnow-2.patch", otherwise identical in behavior compared to xvid-1.1.3-r3.ebuild
Hello, thank you, I`ll try it using emerge -e system and let you know. Best regards, David Kredba.
We are working on getting xvid-1.2.1 into ~arch, it's currently in package.mask for testing.
Hello, yes, it is working for me now with unmasked xvid-1.2.1. It is doing about 69 frames per second using two threads. Later I try it on 4 proc machine, but it will be perfect. Great, thank you very much. Best regards, David Kredba.
When can we get this package updated in the portage tree then?
So how long should we wait for this to be accepted into the port? Is anybody even reading these from gentoo?
(In reply to comment #10) > When can we get this package updated in the portage tree then? > As soon as someone tests it againsts every reverse dependency in the tree. It affects a lot of stuff.
After I built the xvid-1.2.1 for testing I called revdep-rebuild and it did not find any breakage to the system. So please what "every reverse dependency in the tree" do you mean? Am i missing something? Thank you.
Its been masked long enough and i've been using it since the beginning; everything seems fine wrt rev deps so i've unmasked it. We probably can close this bug or wait for 1.2 to hit stable
Please test =media-libs/xvid-1.2.2-r1, it's going stable for security issues.
