FS#7834 - xvidcore could be faster

Attached to Project: Arch Linux
Opened by Sascha Hoppe (sH) - Friday, 17 August 2007, 07:15 GMT
Last edited by Tobias Kieslich (tobias) - Thursday, 16 October 2008, 21:12 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture All
Severity Low
Priority Normal
Reported Version 2007.08 Don't Panic
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Description:
I have a dual boot system: Ubuntu Feisty and Arch Don't Panic
After severe speed problems with transcode on Ubuntu (8 frames) I was happy with the 12.5 frames
I got with Arch.
After installation of the fixed package, posted here https://bugs.launchpad.net/ubuntu/+source/xvidcore/+bug/84705
I get impressive 22 frames in Ubuntu feisty, so it takes half the time to compress video then in Arch.

Is it possible to make the xvidcore in Arch as fast as in Feisty?
Don't know why it's so fast now, according to the thread, the package was build with nasm for MMX/SSE optimized code.
Maybe this is the reason?

Additional info:
* package version(s)
* config and/or log files etc.

Steps to reproduce:

-Compress video with libxvidcore4_1.1.2-0.1ubuntu2~proposed1_i386.deb on Ubuntu Feisty and transcode
-Compress the same video in Arch and notice the speed decrease.
This task depends upon

Closed by  Tobias Kieslich (tobias)
Thursday, 16 October 2008, 21:12 GMT
Reason for closing:  Fixed
Additional comments about closing:  It's rebuild against nasm>2 so that issue should be done
Comment by Roman Kyrylych (Romashka) - Friday, 17 August 2007, 09:49 GMT
MMX/SSE optimized code should be OK for x86_64 but AFAIK we don't use MMX/SSE for i686.
Comment by Roman Kyrylych (Romashka) - Friday, 17 August 2007, 09:53 GMT
Hm.. it appears that nasm dependency is needed only for 32bit package. 64-bit package should not have speed issues even without it.
Comment by Anthony Haslam (ahaslam) - Friday, 02 November 2007, 17:30 GMT
On x86_64 here, I confirm that xvid really could (and should) be faster.
There's a simple remedy, that is to change Nasm in the 'makedepends' to Yasm. This makes encoding with the xvid codec 2-3 times faster, making it comparable to other distro's.
For more information see my forum post, where I've posted my tests & results: http://bbs.archlinux.org/viewtopic.php?id=39296.


Comment by Sascha Hoppe (sH) - Wednesday, 07 November 2007, 20:47 GMT
I can confirm this. I recompiled the package with dependancy yasm instead of nasm via abs and the encoding is two times faster.
Comment by Aaron Griffin (phrakture) - Wednesday, 07 November 2007, 21:45 GMT
Ok wait, to be clear, are we talking about BOTH architectures, or just one?
Comment by Sascha Hoppe (sH) - Wednesday, 07 November 2007, 21:58 GMT
I opened the bug as i686 user and now I am x86_64 user. I can't say if the problem still exists in i686 but it had existed back then.
Comment by Anthony Haslam (ahaslam) - Tuesday, 13 November 2007, 07:21 GMT
As nobody's confirmed this on i686, may I recommend an interim solution of adding something like, "[ "${CARCH}" = "x86_64" ] && makedepends=('yasm')" to the existing PKGBUILD?
Comment by Michael (SiD) - Thursday, 03 January 2008, 23:03 GMT
I couldn't confirm this on i686.
xvidcore from repos and build from abs with yasm as makedepnd have the same encoding speed.
Tested with avidemux.
Comment by John Antoniou (kakashigr) - Sunday, 06 January 2008, 20:14 GMT
I can confirm this on x86_64. I downloaded the PKGBUILD and changed nasm to yasm. The encoding is faster than before, but its still not as fast as it is on say, Ubuntu. Changing nasm to yasm is definitely a step forward to the solution, but something else is missing too.
Comment by Roman Kyrylych (Romashka) - Tuesday, 08 January 2008, 10:47 GMT
I believe changing makedepends from nasm to yasm is not needed when nasm will be updated to 2.0 (yeah, it was resurrected!) which supports all the fancy SSEx instructions.
Comment by Anthony Haslam (ahaslam) - Sunday, 12 October 2008, 10:09 GMT
Nasm 2.xx has fixed the issue, the xvidcore just needs rebuilding against it.

http://bbs.archlinux.org/viewtopic.php?pid=432822#p432822

Loading...