x264 dont use X86 extension such as SSE on the Lucid

Show your FFmpeg command and your complete FFmpeg output. With this information I can attempt to duplicate your error.

ffmpeg -threads 4 -i "/home/fabien/soccer_4cif.y4m" -f mp4 -r 25 -vcodec libx264 -s 1280x720 -b 1500kb -aspect 16:9 -flags +loop -cmp +chroma -deblockalpha 0 -deblockbeta 0 -b 1750k -maxrate 2000k -bufsize 4M -bt 256k -refs 1 -bf 3 -coder 1 -me_method umh -me_range 16 -subq 7 -partitions +parti4x4+parti8x8+partp8x8+partb8x8 -g 250 -keyint_min 25 -level 30 -qmin 10 -qmax 51 -qcomp 0.6 -trellis 2 -sc_threshold 40 -i_qfactor 0.71 -acodec libfaac -ab 128kb -ar 44100 -ac 2 "/home/fabien/soccer_4cif.mp4"

I double checked, and with x264 it works ! It seems that this bug is ffmpeg related.

Any other transcoders uses the libx264 ? I will check if it works with mencoder ...

FFmpeg output:

FFmpeg version SVN-r0.5.1-4:0.5.1-1ubuntu1, Copyright (c) 2000-2009 Fabrice Bellard, et al.
  configuration: --extra-version=4:0.5.1-1ubuntu1 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --disable-stripping --disable-vhook --enable-runtime-cpudetect --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdc1394 --enable-shared --disable-static
  libavutil 49.15. 0 / 49.15. 0
  libavcodec 52.20. 1 / 52.20. 1
  libavformat 52.31. 0 / 52.31. 0
  libavdevice 52. 1. 0 / 52. 1. 0
  libavfilter 0. 4. 0 / 0. 4. 0
  libswscale 0. 7. 1 / 0. 7. 1
  libpostproc 51. 2. 0 / 51. 2. 0
  built on Mar 4 2010 12:35:30, gcc: 4.4.3
Input #0, yuv4mpegpipe, from '/home/fabien/soccer_4cif.y4m':
  Duration: N/A, bitrate: N/A
    Stream #0.0: Video: rawvideo, yuv420p, 704x576, PAR 128:117 DAR 1408:1053, 60 tbr, 60 tbn, 60 tbc
File '/home/fabien/soccer_4cif.mp4' already exists. Overwrite ? [y/N] Y
Output #0, mp4, to '/home/fabien/soccer_4cif.mp4':
    Stream #0.0: Video: libx264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], q=10-51, 1750 kb/s, 90k tbn, 25 tbc
Stream mapping:
  Stream #0.0 -> #0.0
[libx264 @ 0x84b25c0]using SAR=1/1
[libx264 @ 0x84b25c0]frame MB size (80x45) > level limit (1620)
[libx264 @ 0x84b25c0]MB rate (90000) > level limit (40500)
[libx264 @ 0x84b25c0]using cpu capabilities: none!
[libx264 @ 0x84b25c0]profile Main, level 3.0
Press [q] to stop encoding
frame= 20 fps= 0 q=575.0 size= 0kB time=10000000000.00 bitrate= 0.0kbframe= 38 fps= 36 q=575.0 size= 0kB time=10000000000.00 bitrate= 0.0kbframe= 48 fps= 18 q=35.0 size= 0kB time=10000000000.00 bitrate= 0.0kbiframe= 109 fps= 6 q=29.0 size= 515kB time=2.32 bitrate=1818.1kbits/s

x264 output:

y4m [info]: 704x576p 128:117 @ 60/1 fps (cfr)
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1

mencoder output:

MEncoder UNKNOWN-4.4.3 (C) 2000-2009 MPlayer Team
success: format: 0 data: 0x0 - 0x15c0ce36
YUV4MPEG2 file format detected.
YUV4MPEG2 Video stream 0 size: display: 704x576, codec: 704x576
VIDEO: [YV12] 704x576 12bpp 60.000 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:12 fourcc:0x32315659 size:704x576 fps:60.000 ftime:=0.0167
** MUXER_LAVF *****************************************************************
REMEMBER: MEncoder's libavformat muxing is presently broken and can generate
INCORRECT files in the presence of B-frames. Moreover, due to bugs MPlayer
will play these INCORRECT files as if nothing were wrong!
*******************************************************************************
OK, exit.
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 704 x 576 (preferred colorspace: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.34:1 - prescaling to correct movie aspect.
[swscaler @ 0x9229110]using unscaled yuv420p -> yuv420p special converter
x264 [info]: using SAR=35/32
x264 [info]: using cpu capabilities: none!
x264 [info]: profile High, level 3.1
Selected video codec: [rawyv12] vfm: raw (RAW YV12)

I think it something with libx264 or the implementation of it ...

I can not duplicate "using cpu capabilities: none!" and your command uses my CPU capabilities on 64-bit Lucid. Are you using any unofficial packages, such as from a PPA, self-compiled, or from a third-party repository?

This isn't a support forum, but you should use the libx264 presets instead of declaring each option. The presets make encoding easier and allow you to keep up with any API changes (your command is outdated):

http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/

On Mon, Mar 29, 2010 at 20:26:03 (CEST), LouL wrote:

> I can not duplicate "using cpu capabilities: none!" and your command
> uses my CPU capabilities on 64-bit Lucid.

maybe it has something to do with the architecture? i can reproduce this
behavior on my i386 laptop.

I have only tested in 32 bits ubuntu, and no I am not using an anofficial package.

Maybe the problem is on the Intel Core architecture ... Or the bug is only in 32 bits ubuntu.

I will boot a 64bits live cd and check if it work ...

(I also compiled the last svn of vlc and x264, and cpu extension work i think vlc use x264 the same way as x264 (the tool) use it, and not as linked library like ffmpeg and mencoder)

tests results (nightly build):

Live CD 32 bits: same problem ...

Live CD 64 bits: Works perfectly !

32 bits related problem ...

I can also reproduce this behavior on 32-bit Lucid. I believe line 54 in the confflags is to blame:
shared_confflags += --disable-asm

Why --disable-asm?

because on non sse enabled machines, x264 would not load if asm
directives were compiled in.

I've just found the issue, x264 needs to be installed into /usr/lib/sse2
instead of /usr/lib/sse. Moving the library around should fix this
issue.

I'm already working on an upload

I you don't have SSE, your computer is probably too old to do x264 encoding ...

Without x86 extention, it is about 6 fps on Core 2 Quad 2,4 Ghz ...

Thank for all your work and for your reactivity !

I wait for your patch !

On Wed, Mar 31, 2010 at 09:21:19 (CEST), Fabien Lusseau wrote:

> I you don't have SSE, your computer is probably too old to do x264
> encoding ...

true, but I fear that if we wouldn't do that, all applications that link
to x264 will immediatly SIGILL regardless if they do or don't use x264

> Without x86 extention, it is about 6 fps on Core 2 Quad 2,4 Ghz ...
>
> Thank for all your work and for your reactivity !
>
> I wait for your patch !

as said, in the mean time you can rename /usr/lib/sse to /usr/lib/sse2,
that should instantly improve the performance

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

This bug was fixed in the package x264 - 2:0.85.1448+git1a6d32-4

---------------
x264 (2:0.85.1448+git1a6d32-4) lucid; urgency=low

  * install sse optimized version in /usr/lib/sse2. LP: #550524
 -- Reinhard Tartler <email address hidden> Tue, 30 Mar 2010 22:27:28 +0200

I tried to move libx264 to /usr/lib/sse2, but nothing append ... (using 2:0.85.1448+git1a6d32-3)

I will update to the new package. But if the change is only changing directory ...

LouL mentioned this line in conflags:

shared_confflags += --disable-asm

If this line do what i think, it must not work.

Manual move of the library doesn't work, but compiling with the new directory work ... I don't know why ... But it seems to work for me, if you have applied the same patch to the upcomming package, It will work perfectly !

Thank again for your help !