Howto x264_cli + mplayer/mencoder + windows

[ga82]

So, I want to use windows, x264 cli, mplayer or mencoder (windows build).

How do I put it all together and use it to compress video? Just help me with the video compression part. something.avi with audio and video -> something.mkv with h264 video only. I do not wish to use any gui. Also, would like to avoid using any other tools if possible (especially avisynth).

Please give me an example along with the explanation. Thank you in adv...

(In linux, I used named pipes in bash to transfer frames from mencoder to x264. No such thing here in windows)

[quake74]

I am interested in this too. I tried looking for a solution but couldn't find one. Well, except for using mkfifo on cygwin, but that's almost cheating ;)

[DarkZell666]

Here's something that almost worked:

mencoder "Elephants_Dream_HD.avi" -vf scale=640:352,format=YV12 -nosound -ovc raw -o - | x264 - -o "lol.mkv" 640x352

Because this is what came out:
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
New_Face failed. Maybe the font path is wrong.
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.
x264 [info]: slice I:1 Avg QP:23.00 size: 1486 PSNR Mean Y:57.47 U:61.05 V:69.53 Avg:58.72 Global:58.72
x264 [info]: slice P:12 Avg QP:26.00 size: 164 PSNR Mean Y:57.65 U:60.34 V:66.28 Avg:58.51 Global:56.47
x264 [info]: mb I I16..4: 98.0% 0.0% 2.0%
x264 [info]: mb P I16..4: 4.1% 0.0% 0.2% P16..4: 2.9% 0.2% 0.1% 0.0% 0.0% skip:92.5%
x264 [info]: SSIM Mean Y:0.9995100
x264 [info]: PSNR Mean Y:57.636 U:60.391 V:66.534 Avg:58.526 Global:56.606 kb/s:53.17

encoded 13 frames, 16.33 fps, 60.08 kb/s

It only encoded the first 13 frames and stopped, but the CPU continued running 100% until I pressed CTRL+C.
Dunno what went wrong, but it should have worked ^^'

Edit: ffmpeg.exe might be more willing to cooperate :p

[ga82]

mkfifo does not appear to be working in cygwin. And as for the above solution, I think a file called "-" is being created.

Is there no other way? Where are you windows scripting gods?? Where are you encoding gods??

[nm]

Well, have you considered using MEncoder's built-in x264 support instead of the x264 cli? Output a raw H.264 stream with -of rawvideo, mux it to an MP4 container with MP4Box or mp4creator and then feed the MP4 file to mkvmerge. I know, the MP4 muxer is extra and some intermediate files need to be created, but on the other hand you wouldn't need the x264 executable.

[Sharktooth]

Here's something that almost worked:

mencoder "Elephants_Dream_HD.avi" -vf scale=640:352,format=YV12 -nosound -ovc raw -o - | x264 - -o "lol.mkv" 640x352

Because this is what came out:
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
New_Face failed. Maybe the font path is wrong.
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.
x264 [info]: slice I:1 Avg QP:23.00 size: 1486 PSNR Mean Y:57.47 U:61.05 V:69.53 Avg:58.72 Global:58.72
x264 [info]: slice P:12 Avg QP:26.00 size: 164 PSNR Mean Y:57.65 U:60.34 V:66.28 Avg:58.51 Global:56.47
x264 [info]: mb I I16..4: 98.0% 0.0% 2.0%
x264 [info]: mb P I16..4: 4.1% 0.0% 0.2% P16..4: 2.9% 0.2% 0.1% 0.0% 0.0% skip:92.5%
x264 [info]: SSIM Mean Y:0.9995100
x264 [info]: PSNR Mean Y:57.636 U:60.391 V:66.534 Avg:58.526 Global:56.606 kb/s:53.17

encoded 13 frames, 16.33 fps, 60.08 kb/s

It only encoded the first 13 frames and stopped, but the CPU continued running 100% until I pressed CTRL+C.
Dunno what went wrong, but it should have worked ^^'

Edit: ffmpeg.exe might be more willing to cooperate :p
use visual studio to build x264 build and piping will work correctly.

[DarkZell666]

And as for the above solution, I think a file called "-" is being created.nope :p the lol.mkv file is indeed created but only contains 13 black frames ^^' the "-" file means stdin/stdout (both for mencoder and x264).


@Sharktooth, thx for mentionning that, I'll have a try for my personnal education ;)

[ga82]

Well, have you considered using MEncoder's built-in x264 support instead of the x264 cli? Output a raw H.264 stream with -of rawvideo, mux it to an MP4 container with MP4Box or mp4creator and then feed the MP4 file to mkvmerge. I know, the MP4 muxer is extra and some intermediate files need to be created, but on the other hand you wouldn't need the x264 executable.

It appears that is the only apparent sure way of doing it. I'll try that. thanks.

[quake74]

use visual studio to build x264 build and piping will work correctly.

Is this something reasonably easy to do? Which version of visual studio? (And my last question will give you a hint of my level of knowledge) And most important, is it free?

[DarkZell666]

No, it's fagging expensive I'm afraid. I've been a student not so long ago, so I still have my free student licence for VS.NET 2003.

Second thoughts, there are the 2005 Express editions, which are free, but you only have single-programming language support in each version (whereas the full version has quite a bit more stuff in it ;)). You'd want the "Visual C++ Studio 2005 Express" version for a quick start. There's a quick FAQ on compiling x264 somewhere that hasn't surfaced for some time (here:http://forum.doom9.org/showthread.php?t=92726&highlight=compiling+x264).
There's some info on compiling with VS somewhere in there (but the FAQ was written for compiling with mingw and all that stuff).

cakuhnen had a try with VS2005 here: http://forum.doom9.org/showthread.php?t=120245&highlight=compiling+x264
and apparently didn't encounter too much problems ^^

The fact is: normally, it should be straightforward, but there's always something that goes wrong when you try for the first time :p

[Pookie]

The very simple Winmenc front end app will create a batch file for you based on the files you pick to transcode:


mencoder.exe "E:\in.avi" -nosound -ovc x264 -ffourcc H264 -x264encopts bitrate=2000 -o "E:\out.x264.mkv" 2> 2.txt

[nm]

... -o "E:\out.x264.mkv" ...
AFAIK MEncoder can't mux the video directly to a Matroska file, only to AVI (the default), raw H.264 (with -of rawvideo, this is the best option for x264 encoding) and formats supported through libavformat such as MP4 (-of lavf -lavfopts format=mp4, which may produce broken files). The MKV you write here will actually be AVI.

[DarkZell666]

Yup, the whole point of using x264.exe was to be able to mux to mkv in one go :p and lavf doesn't support mkv output either yet :x

[quake74]

No, it's fagging expensive I'm afraid. I've been a student not so long ago, so I still have my free student licence for VS.NET 2003.

Second thoughts, there are the 2005 Express editions, which are free, but you only have single-programming language support in each version (whereas the full version has quite a bit more stuff in it ;)). You'd want the "Visual C++ Studio 2005 Express" version for a quick start. There's a quick FAQ on compiling x264 somewhere that hasn't surfaced for some time (here:http://forum.doom9.org/showthread.php?t=92726&highlight=compiling+x264).
There's some info on compiling with VS somewhere in there (but the FAQ was written for compiling with mingw and all that stuff).

cakuhnen had a try with VS2005 here: http://forum.doom9.org/showthread.php?t=120245&highlight=compiling+x264
and apparently didn't encounter too much problems ^^

The fact is: normally, it should be straightforward, but there's always something that goes wrong when you try for the first time :p

Thanks Dark. I will first follow the path of least resistance and ask cakuhnen for his build ;) and if I have time I'll try myself.

[Pookie]

Whoops. :o Sawree about that. I was too lazy to check if in fact the resulting file was an MKV.

[quake74]

Ok, I feel dumb... Shark suggested using VS builds, and it took me a week to realize that I already downloaded and tested the builds from http://forum.doom9.org/showthread.php?t=120247...

I tested and piping "works" using


mencoder "Elephants_Dream_HD.avi" -vf scale=640:352,format=YV12 -nosound -ovc raw -o - | x264 -o "lol.mkv" - 640x352


The video file is not actually wachable, I guess there are problems in the ",format=yv12". I tried cutting it out and the result is different while still unwatchable...

[DarkZell666]

If by watchable you mean clean, try adding --crf 20 to the x264 cmd-line. I dunno what's the default mode used by x264 if you don't specify anything.

If by watchable you mean "looks b0rked all over the place with green and pink squares", I'm not sure the format=YV12 is to blame (it worked for me in a previous encode anyway). Try I420 just in case, but I'm not even sure mencoder supports it.

Could you actually post some screenshots of what it looks like ? :p

[quake74]

If by watchable you mean "looks b0rked all over the place with green and pink squares", I'm not sure the format=YV12 is to blame (it worked for me in a previous encode anyway). Try I420 just in case, but I'm not even sure mencoder supports it.

Could you actually post some screenshots of what it looks like ? :p

Yeah, that's the "borked all over the place" kinda problem. My encoder says


D:\tmp>mencoder -vf format=fmt=help
MEncoder Sherpya-r21847-MinGW-4.1.1 (C) 2000-2006 MPlayer Team
CPU: Intel(R) Pentium(R) M processor 1.86GHz (Family: 6, Model: 13, Stepping: 8)

CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

Available formats: 444p 422p 411p yuy2 uyvy yvu9 if09 yv12 i420 iyuv clpl hm12 y
800 y8 nv12 nv21 bgr24 bgr32 bgr16 bgr15 bgr8 bgr4 bg4b bgr1 rgb24 rgb32 rgb16 r
gb15 rgb8 rgb4 rg4b rgb1 rgba argb bgra abgr


and here are two examples, first one with format=i420 and other with yv12

http://img170.imageshack.us/img170/1267/i420vi4.jpg (http://imageshack.us)

http://img385.imageshack.us/img385/8194/yv12vs2.jpg (http://imageshack.us)

[DarkZell666]

Oh my that looks wierd :o
I just tried on a sample and I almost jumped !

In fact, something in the piping must be going wrong since:
This produces a valid YV12 uncompressed file:
mencoder "bleachopening.avi" -vf scale=512:384,format=YV12 -nosound -ovc raw -o yv12.avi
And this, produces a valid x264 encode:
x264_p3 --progress -o "bliche.mkv" yv12.avi

The pipping sort of "works" (with the Intel builds you mentionned), but doesn't copy the video stream correctly. So, on which side is the problem ? :o

*Gonna try with something else*

mencoder "bleachopening.avi" -vf scale=512:384,format=YV12 -nosound -ovc raw -o - | x264_p3 --progress -o "lol.mkv" - 512x384
In fact, putting the scale after the format option also b0rks the picture in a different way alltogether.

Edit:
<dead links removed>

[quake74]

I have a guess for the problem: the fact is that by default mencoder outputs avi container (-ovc raw puts raw video stream in avi container) but when feeding from a pipe x264 assumes the input is raw video in raw format (because it has no file extension), and that is why we need to put the 512x384 at the end of the x264 command. So since x264 is expecting raw and gets avi, this messes up something inside x264. Surprisingly, not too much!

Edit: Crap, it's probably worse. Adding -of rawvideo to mencoder borks something and x264 only encodes 1 frame. Even worse, putting -msglevel all=-1 on mencoder changes the SSIM of the single x264 output frame, so I think that some of the mencoder console messages are actually piped to x264...

[alec_robertson]

The latest svn mkvmerge seems to be able to mux directly from avi to mkv (http://forum.doom9.org/showthread.php?t=118133) so you can do the mencoder step in one hit to avi and then mux directly into mkv. I've found the a-v syncing to be more robust encoding both audio and video simultaneously, rather than splitting them:

mencoder input.avi -vf scale,harddup -oac mp3lame -lameopts abr:br=128 -ovc x264 -x264encopts crf=22:bframes=2 -o encoded.avi;
mkvmerge -o encoded.mkv --aspect-ratio 0:16/9 --nalu-size-length 0:3 encoded.avi;

[DarkZell666]

so I think that some of the mencoder console messages are actually piped to x264... Confirmed, some of the console messages appear along the pipe :)

I used this to check:
mencoder "input.avi" -vf scale=512:384,format=yv12 -frames 50 -nosound -ovc raw -o - >yadayada.txtIf you open this you'll be able to read something familiar at the beginning ;)

Using -msglevel all=-1, I was expecting the problem to disapear, but it seems not o_O. Adding "-quiet" or "-really-quiet" didn't change much either. What's even more wierd, is that renaming the yadayada.txt file to yada.Avi, the video is ok ! So what's going wrong this time ?

Here's the last thing I tried:
D:\Progz\mpui>mencoder "bleachopening.avi" -vf scale=512:384,format=yv12 -msglevel all=-1 -really-quiet -nosound -ovc raw -vf scale=512:384,format=yv12 -o - | x264_p3 --progress -o "blah.mkv" - 512x384The b0rkiness looks the same as the sample I posted, except the blue at the top of the picture comes down slower.

Question for anyone reading this thread:what's the ultimate way of telling mencoder to just shut up ? :p

[DarkZell666]

The latest svn mkvmerge seems to be able to mux directly from avi to mkv (http://forum.doom9.org/showthread.php?t=118133) so you can do the mencoder step in one hit to avi and then mux directly into mkv. I've found the a-v syncing to be more robust encoding both audio and video simultaneously, rather than splitting them:

mencoder input.avi -vf scale,harddup -oac mp3lame -lameopts abr:br=128 -ovc x264 -x264encopts crf=22:bframes=2 -o encoded.avi;
mkvmerge -o encoded.mkv --aspect-ratio 0:16/9 --nalu-size-length 0:3 encoded.avi;


Good news that is ! :) If ever we can't get piping to work that'll be the quickest way indeed =)

[DarkZell666]

I've just tried setting the MPLAYER_VERBOSE env. var to -1 via
SET MPLAYER_VERBOSE=-1, which is meant to control the display of messages printed before the command-line is parsed: same punition.

[foxyshadis]

In ffmpeg it's easy to use -f y4m - | ... for the piping, to encapsulate it properly, and it outputs everything to stderr. Surely mencoder has something like that, but since there's no simple command reference in the docs and I'm not going to look through the source, I have no idea.

[DarkZell666]

The only YUV4MPEG support I found was mplayer "yudu.avi" -vo yuv4mpeg:file=yada.yuv, and setting the filename to "-" only created a file named "-" with the data inside :o

In ffmpeg, y4m is in fact yuv4mpegpipe, so here goes: ffmpeg -i "yudu.avi" -f yuv4mpegpipe - | x264 --progress --crf 20 -o "doesntwork.mkv" - 640x480.

I did say doesntwork.mkv because the colors are also b0rked , just like with mencoder (but to a lesser extent, which means there's less garbage going to stdout :p)

ffmpeg seems to send some extra headers that x264 fails to read correctly (ffmpeg -i "yudu.avi" -f yuv4mpegpipe - >stdout.txt) :
YUV4MPEG2 W640 H480 F30:1 Ip A1:1 C420mpeg2 XYSCSS=420MPEG2
FRAME
«¬¯°°¯¬«±±²²³´´´·¸¹»»¹¸·µ(I voluntarily took some binary garbage from the first frame). I'll have to try a more recent build just in case.

I'm not sure wether x264 should be doing something with the first line, or if it's something specific from ffmpeg that shouldn't be there ...
At least the info seems useful, and would avoid the need to add the WxH parameters to x264 :)

[quake74]

The only YUV4MPEG support I found was mplayer "yudu.avi" -vo yuv4mpeg:file=yada.yuv, and setting the filename to "-" only created a file named "-" with the data inside :o

y4m is in fact yuv4mpegpipe, so here goes: ffmpeg -i "yudu.avi" -f yuv4mpegpipe - | x264 --progress --crf 20 -o "doesntwork.mkv" - 640x480.

I did say doesntwork.mkv because the colors are also b0rked , just like with mencoder (but to a lesser extent, which means there's less garbage going to stdout :p)

ffmpeg seems to send some extra headers that x264 fails to read correctly (ffmpeg -i "yudu.avi" -f yuv4mpegpipe - >stdout.txt) :
(I voluntarily took some binary garbage from the first frame). I'll have to try a more recent build just in case.

I'm not sure wether x264 should be doing something with the first line, or if it's something specific from ffmpeg that shouldn't be there ...
At least the info seems useful, and would avoid the need to add the WxH parameters to x264 :)


It works for me! But not using yuv4mpegpipe but rawvideo!


ffmpeg -i d:\dvd\HD\SharkTale.avi -s 368x208 -f rawvideo - | x264 --progress -o ff.mkv - 368x208


Beautiful! Out of curiosity I also tried with the usual sharktooth x264 and that doesn't work.

[DarkZell666]

It works for me! But not using yuv4mpegpipe but rawvideo!


ffmpeg -i d:\dvd\HD\SharkTale.avi -s 368x208 -f rawvideo - | x264 --progress -o ff.mkv - 368x208


Beautiful! Out of curiosity I also tried with the usual sharktooth x264 and that doesn't work.

Beaten to the minute :p I was about to try rawvideo when you posted, great news :D

As Sharktooth said, x264 needs to be compiled with Visual Studio for piping to work under windows, and his usual builds (just like b0b0r's) are made with MingW bross., so only the intel builds he provided (which are compiled with VS I suppose) work for piping.

[quake74]

Ok, about the mencoder spurious pipe output, for me the two files produced by


mencoder orig.avi -frames 100 -ovc raw -of rawvideo -o rawoutput

mencoder orig.avi -frames 100 -ovc raw -of rawvideo -msglevel all=-1 -o - >rawoutputpipe


are identical. However, when I pipe that into x264 I get


mencoder orig.avi -frames 100 -ovc raw -of rawvideo -msglevel all=-1 -o - | x264 -o rawvideopipe.mp4 - 368x208
SSE2 supported but disabled
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
mp4 [info]: initial delay 0 (scale 25)
x264 [info]: slice I:1 Avg QP:23.00 size: 6538 PSNR Mean Y:46.05 U:45.69
V:45.70 Avg:45.93 Global:45.93
x264 [info]: mb I I16..4: 79.6% 0.0% 20.4%
x264 [info]: SSIM Mean Y:0.9966063
x264 [info]: PSNR Mean Y:46.052 U:45.691 V:45.699 Avg:45.930 Global:45.930 kb/s:
1307.60

encoded 1 frames, 62.50 fps, 1394.20 kb/s


Very weird to me... expecially because


x264 -o rawoutputpipe.mkv rawoutputpipe 368x208
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:2 Avg QP:23.00 size: 5915 PSNR Mean Y:45.45 U:59.11
V:52.77 Avg:46.47 Global:46.06
x264 [info]: slice P:98 Avg QP:26.00 size: 2942 PSNR Mean Y:42.06 U:42.31
V:41.23 Avg:41.85 Global:41.67
x264 [info]: mb I I16..4: 73.6% 0.0% 26.4%
x264 [info]: mb P I16..4: 28.6% 0.0% 4.7% P16..4: 20.8% 7.4% 1.4% 0.0% 0
.0% skip:37.2%
x264 [info]: SSIM Mean Y:0.9902164
x264 [info]: PSNR Mean Y:42.132 U:42.649 V:41.463 Avg:41.943 Global:41.722 kb/s:
600.26

encoded 100 frames, 55.19 fps, 601.22 kb/s


works...

[quake74]

I tried this


mencoder.exe orig.avi -vf scale=640:480 -ovc raw -of rawvideo -msglevel all=-1 -o - | ffmpeg -f rawvideo -r 25 -s 640x480 -i - -f avi -s 320x240 b.avi


and received a weird video (different but similar to the one before).

http://img153.imageshack.us/img153/478/ffmpegys5.jpg (http://imageshack.us)

In view of this, I'm gonna say that the pipe output of mencoder is borked.

[nm]

In view of this, I'm gonna say that the pipe output of mencoder is borked.
Yes, because it is not written to actually support pushing the video to stdout. The "-o - > output.raw" trick doesn't work at all on Linux/Unix: it just writes a file named "-", which contains the video and the text output would be printed to output.raw like this: "MEncoder dev-SVN-r20294-3.4.6 (C) 2000-2006 MPlayer Team CPU: AMD Athlon(tm) processor (Family: 6, Model: 4, Stepping: 4) ...". The reason the video ends up to stdout (along with the normal output that breaks things for you) on Windows is that the "-" file is apparently redirected automatically by the OS.

To get it working properly (on Windows), you would need to make a request to the MPlayer/MEncoder developers that msglevel all=-1 would really switch off all output, and even better, request support for handling the "-" file name specially when given to -o, so that it would work on other OS's as well.

[quake74]

To get it working properly (on Windows), you would need to make a request to the MPlayer/MEncoder developers that msglevel all=-1 would really switch off all output, and even better, request support for handling the "-" file name specially when given to -o, so that it would work on other OS's as well.


The output of the commands I showed before are clean from any spurious strings of text (I say this because I looked). Proof is also that x264 is happy to swallow the file created by piping the output of mencoder and the result is a correct video file.

Probably the problem lies even deeper inside windows piping...

P.S. I posted a message on the mplayer-users mailing list. Let's see what happens...

[nm]

My hypothesis was incorrect. After upgrading to latest SVN version, the "-o -" does work on Linux too, and I also get the same problems when piping to x264 although the raw files work fine.

[reiser]

Hi guys,
I am trying the same stuff under linux, because I need hardcoded subtitles for my PSP. The AVC stream from ffmpeg plays fine on the PSP, but it lacks subtitles support. Mencoder supports subtitles in the picture, but the produced file (avi and then muxed to mp4 ) does not plays on the PSP(FW v3.40).
I tried mencoder+x264 (piping) and mplayer -vo yuv4mpeg trough fifo file to x264 but got the same borked picture like you both ways.
The only working way at this point seems to be
mkfifo stream.yuv
mplayer -nosound -noframedrop -vf scale=...,expand=... input.mkv -vo yuv4mpeg
and then in another console in the same dir
cat stream.yuv | ffmpeg -i - -an <lots of video options> output.mp4
I would like the AVC stream from mencoder to be compatible with the PSP, so I could process both audio and video at the same time

[SealTooGreat]

I think that developer of MediaCoder (http://forum.doom9.org/showthread.php?t=119372&highlight=mediacoder) use mencoder/mplayer+x264, so use his gui for that stuff.

[DarkZell666]

@reiser : the problem we discovered here was that mplayer would pipe some text from the console out along with the video stream, which was what caused the b0rkiness. The only quick fix we found to this was to use ffmpeg for decoding instead of mplayer, but then mplayer has some extra filter's you probably wanted to use ... :) if it's just cropping and deinterlacing, ffmpeg can do that too, don't worry :D

Also, are you 100% sure you specified the exact same settings for x264 in mencoder and ffmpeg ? (watch out for some default settings that could be different and that you didn't explicitely specify).

If so, the only reason I can see is that some headers are missing in the mp4 file for the PSP to be "allowed" to read it (unless that BS was for the ipod ? or both ? can't remember). I suppose ffmpeg is able to add them thx to the "-f psp" switch, whereas mencoder doesn't have such an option. Now, the headers ffmpeg adds with "-f psp" are probably a specific level (ie: level 2.1 instead of "unrestricted"), and a custom atom which the psp needs to "identify" the file's origin (and again, I'm not quite sure which from the PSP or the ipod this concerns, but I'd bet it concerns both).

@SealTooGreat : MediaCoder is for win32 AFAIK, and each time I tried it I encoutered a crash no matter what : not a good deal if you ask me =) He indeed fixed x264's piping under windows (he gave akupenguin a patch, dunno if it was incorporated), but I'm not sure he pipes mplayer to x264. If he does I'd be curious to see what cmd-lines he used to make mplayer completely silent while decoding :)

@quake74 : if you're still reading this thread, did you ever get an answer about the issue from the mplayer devs ?

[reiser]

@SealTooGreat unfortunately this is win app.

@DarkZell666 The main problem for me is the lack of soft subtitles support(.sub .srt) in ffmpeg. The options I used are from this guide (http://rob.opendot.cl/index.php/useful-stuff/psp-video-guide/) (works fine) and then I tried to duplicate all options in mencoder. The actual command lines are:
mencoder movie.mkv -sub movie.srt -profile psp-235-1 -o movie.avi #first pass
mencoder movie.mkv -sub movie.srt -profile psp-235-2 -o movie.avi #second pass
and the profiles:

[psp-235-1]
profile-desc="PSP uwide 1st pass"
ovc=x264=yes
oac=faac=yes
faacopts=br=128:object=2
vf=scale=480:204:0:0,expand=:-68:0:0:1
x264encopts=bitrate=700:pass=1:turbo=1:subq=1:8x8dct:frameref=1:bframes=1:nob_pyramid:noweight_b:level_idc=21

[psp-235-2]
profile-desc="PSP uwide 2nd pass"
ovc=x264=yes
oac=faac=yes
faacopts=br=128:object=2
vf=scale=480:204:0:0,expand=:-68:0:0:1
x264encopts=bitrate=700:pass=2:subq=1:8x8dct:frameref=1:bframes=1:nob_pyramid:noweight_b:level_idc=21


But the result is not playable in my PSP.
With x264 I get the same result, when using pipe and when using -vo yuv4mpeg. I think the YUV4:2:0 stream from mencoder is not compatible with x264 or we are missing something. I don't know :confused:

EDIT: SUCCESS!!!
Until now I have used
ffmpeg -i mencoder-output.avi -vcodec copy -acodec copy output.mp4
and then I decided to try different mp4 muxer - MP4Box from gpac. It had some effect, as the file now was listed as playable in the PSP (before it showed "unsupported data"), but did not actually worked - the error was "This video cannot be played". So I played with mencoder options and I was able to produce playable file :) These are the updated profiles:

[psp-235-1]
profile-desc="PSP uwide 1st pass"
ovc=x264=yes
oac=faac=yes
faacopts=br=128:object=2
vf=scale=480:204:0:0,expand=:-68:0:0:1
x264encopts=bitrate=800:pass=1:turbo=1:subq=5:no8x8dct:partitions=p8x8,b8x8,i4x4:brdo:frameref=2:bframes=2:nob_pyramid:noweight_b:level_idc=21

[psp-235-2]
profile-desc="PSP uwide 2nd pass"
ovc=x264=yes
oac=faac=yes
faacopts=br=128:object=2
vf=scale=480:204:0:0,expand=:-68:0:0:1
x264encopts=bitrate=800:pass=2:subq=6:no8x8dct:partitions=p8x8,b8x8,i4x4:frameref=2:brdo:bframes=2:nob_pyramid:noweight_b:level_idc=21

I tried to output rawaudio in the first step and rawvideo in the second, but the resulted was out of sync audio. So I have to encode first to avi, then demux it with MP4Box and then mux it back to mp4. But this is much easier to put in a script :)