Ubuntu
x264 package

Import 20070116 snapshot

Bug #80387 reported by John Dong
4
Affects Status Importance Assigned to Milestone
x264 (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Since 20061216 a breakthrough new threading algorithm was committed into upstream SVN which enables efficient utilization of multiple cores during encodes. Marillat currently has not reacted to this change yet but I think Feisty should take advantage of this capability and not wait on Marillat.

I will be preparing packages and updating this bug report as I go along, as I expect minor API changes to warrant the patching of ffmpeg, mplayer, and avidemux.

John Dong (jdong)
Changed in x264:
assignee: nobody → jdong
Revision history for this message
John Dong (jdong) wrote :

New x264 source package (based off debian-multimedia packaging): http://buntudot.org/people/~jdong/ffmpeg/feisty/x264_0.cvs20070117-0ubuntu1.dsc

Fix API change for ffmpeg: http://buntudot.org/people/~jdong/ffmpeg/feisty/ffmpeg-patch-x264.debdiff

Ditto for mplayer:
http://buntudot.org/people/~jdong/ffmpeg/feisty/mplayer-fix-x264.debdiff

Rebuild avidemux (no source change necessary):
http://buntudot.org/people/~jdong/ffmpeg/feisty/avidemux-rebuild.debdiff

The ffmpeg API change fix also included a patch to close bug https://launchpad.net/ubuntu/+source/ffmpeg/+bug/76354.

Note that mplayer does not build against Feisty cleanly due to caca's API changing, but that is not my fault and should not block these patches from going in anyway.

Changed in x264:
assignee: jdong → nobody
Revision history for this message
Barry deFreese (bddebian) wrote :

I've uploaded x264. Once that builds I will look at the others.

Changed in x264:
status: Unconfirmed → In Progress
Revision history for this message
John Dong (jdong) wrote :

http://librarian.launchpad.net/5787763/buildlog_ubuntu-feisty-powerpc.x264_1%3A0.cvs20070117-0ubuntu1_FAILEDTOBUILD.txt.gz

PPC FTBFS; other arches look fine. It seems like common/quant.c includes an altivec'ed header without including the altivec.h header. The attached debdiff should fix this.

Revision history for this message
John Dong (jdong) wrote :

FTBFS again, looks like an upstream issue (Linux more strict than Apple with Altivec?)

How do you feel about continuing despite FTBFS on ppc? IMO it's not fair to hold every other arch back because of PPC quibbling.

(alternatively we can try reversing the SVN revision that optimized Altivec leading to this FTBFS)

Revision history for this message
John Dong (jdong) wrote :

On further thought, I have reversed upstream SVN commits 604 and 601 (interestingly marillat's at 604, which also failed to produce a PPC binary).

This should fix the PPC FTBFS for good. Since the altivec optimizations in those revisions don't compile in ppc linux anyway, it's better to have a binary than no binary for our ppc folk :)

Attached debdiff should be applied against -ubuntu2 revision

Daniel T Chen (crimsun)
Changed in x264:
status: In Progress → Fix Released
Daniel T Chen (crimsun)
Changed in x264:
status: Fix Released → Fix Committed
Revision history for this message
Daniel T Chen (crimsun) wrote :

ffmpeg patch applied and uploaded.

avidemux patch corrected (so it doesn't touch debian/control:Build-Depends), applied, and uploaded.

Revision history for this message
John Dong (jdong) wrote :

All looks good, marking Fix Released.

Changed in x264:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.