(gdb) bt
#0  0xb7f3423e in x264_pixel_satd_8x8_ssse3 () from /usr/lib/libx264.so.0
#1  0xb7ed8a55 in x264_slicetype_mb_cost () from /usr/lib/libx264.so.0
#2  0x00000008 in ?? ()
#3  0x00000000 in ?? ()

16:46 -!- thresh has joined #x264
16:46 < thresh> #0  0xb7f3423e in x264_pixel_satd_8x8_ssse3 () from
/usr/lib/libx264.so.0
16:46 < thresh> does it ring any bell ?
16:48 < astrange> are you using svn instead of git?
16:48 < thresh> the package was made with 745 revision
16:49 < astrange> it was fixed right after the switch to git

2 thresh 4 astrange: nope, visually the same segfault with current snapshot;
handling sample to led@ (could you pass the link upstream too?)

Some mencoder tests a few days ago show that segfault is there when sound is
recoded too; nosound would result in proper video.

I've rolled back libx264 and libfaac to 4.0/branch builds --

libx264: 0.58-alt0.20080320.1 -> 0.56-alt0.671.1
libfaac: libfaac-1.26-alt1 -> 1.25-alt3

and the same ffmpeg line as shown does work; upgrading libx264 again results in
segfault again.

Seems like a compound problem?  As far as I understand mplayer would use ffmpeg
to do a mp4 container, and disabling/enabling sound together with library
rollback being important to working around the problem hints at that too.

PS: I've tried x264 git yesterday (failed to build latest commit but did build
and test 32fb497 to no avail); could probably fiddle with faac as well but would
be so much better to help you folks, as I'm not much into the intricacies of the
whole software stack involved.

всё ещё актуально?

Предположительно да -- на днях обновил дома libx264 из M41, вскоре был уведомлён, что H.264 перестали экспортиться из kino.

Вообще кучка страшных для libx264/mencoder образцов угрожающе выросла...

(In reply to comment #7)
> Предположительно да -- на днях обновил дома libx264 из M41, вскоре был уведомлён,
> что H.264 перестали экспортиться из kino.

Это не из-за x264. Поэтому, пока что fixed