A tool for transcoding video for ps3 using Linux

[jva]

Hi there.

For a while I was searching a tool to transcode my media library to be ps3 compatible. I noticed that such tool does not exist for Linux, or I was just unable to find such software. Thus, I wrote a shell script that does that for me.

The information in the script (coding params, etc) are gathered from the discussions of this forum. It took a while to iron out coding parameters that work for ps3 and also produce good coding results. The script relies on existence of ffmpeg and x264 command line tools that are compiled with proper options and settings. I'm running Ubuntu linux (feisty fawn) and the stock tools delivered with it. They work just fine and the script is (was) able to transcode all my videos to ps3 supported format.

I decided to share the scrip here, just in case there is a need for this kind of a solution by someone else as well. I thought the MPEG AVC forum was the correct place, even though there were linux specific threads as well.

All comments are warmly welcome and hopefully this script makes someone elses day easier as well. Further comment and usage information can be found from the script itself.

Thanks
- Jarkko

[dssgorila]

waiting for the attachment to be approved. and I will test it out.

[jva]

waiting for the attachment to be approved. and I will test it out.

Ok, since I do not seem to understand the approval process of the attachment, here is the script as a copy-paste. One way to do it.

I've been testing this now quite a bit and with some videos the encoding result is quite bad. This has something to do with the x264 params and thus to be investigated. Another thing is that the for some reason the script does not process matroska files properly. It only encodes first frame of the video and then stops. That needs to be investigated as well. Well, anyway, here is the script for those who are interested.


#!/bin/bash

####
#
# ps3_transcode_v2.sh
# -------------------
# A small script to transcode a video file into ps3 compatible
# format.
#
# This program relies on video format support of ffmpeg. Any file
# that is undestood by ffmpeg can be transcoded using this script.
#
# The script was written because I did not find a decent solution
# readily available for linux to do the video transcoding for my ps3.
# There were several options for Windows, but those are not too
# useful on linux platform.
#
# Easy example way to transcode all .avi files in $DIR:
# find $DIR -name "*.avi" | \
# xargs -I {} echo "ps3_transcode_v2.sh \
# -input \"{}\" \
# -output \"{}.mp4\"" >transcode_script.sh
# chmod +x ./transcode_script.sh
# ./transcode_script.sh
#
# Comments warmly welcome to the author:
#
# Jarkko Vatjus-Anttila <j.vatjus-anttila@luukku.com>
#


####
# Global variables for the whole script
#
# RATIO:
# ------
# bitrate ratio (values taken from good quality movie samples)
# 1920x1080 -> 8096kbit/s -> 0.00390 kbit/pixel
# 512x384 -> 300kbit/s -> 0.00153 kbit/pixel
#
# -> choosing ratio: 0.00240 kbits/pixel
#
# This value is used later in this script to quess a good
# bitrate for the video, based on its resolution
#
RATIO=0.00240



####
# CheckDependency() sub routine is used to check external dependencies
# (commands) that should exist in the system.
#

CheckDependency() {
if [ -z `which "$1"` ]; then
echo "$1 does not exist. Maybe \"sudo apt-get install $1\" helps?"
exit
fi
echo "Checking $1 ... ok"
}

####
# Usage() sub routine display the generic usage of the script
#

usage() {
echo "ps3_transcode.sh -input <file> -output <file> [-subtitles <file>]"
echo " [-bitrate <forced bitrate>] [-ratio <value>] [-timelimit <value>]"
echo " [-help|--help]"
echo "Params:"
echo " -input Input file name (e.g. Input.avi)"
echo " -output Output file name (e.g. Output.mp4"
echo " -subtitles Subtitle filename (e.g. Input.srt)"
echo " -bitrate Forced bitrate in kbits/s"
echo " -ratio Compression ratio bits/pixel (default: $RATIO)"
echo " -timelimit Limit transcoding time to N seconds (useful for testing)"
echo " -keeptemp Do not delete temporary coding files"
echo " -help|--help Display this usage text"
echo "Example:"
echo " ps3_transcode.sh -input video.avi -output video.mp4 -ratio 0.00350"
}



####
# Check input parameter existense
#
INPUT=
OUTPUT=
SUBTITLES=
FORCED_BITRATE=
STOP_FFMPEG=
KEEPTEMP=

while [ $# -gt 0 ]; do
case "$1" in
-input)
if [ -z "$2" ]; then
echo "ERROR: Missing -input argument"
usage
exit 1
fi
INPUT="$2"
if [ ! -e "$INPUT" ]; then
echo "ERROR: Input file does not exist!"
usage
exit 1
fi
shift;;
-output)
if [ -z "$2" ]; then
echo "ERROR: Missing -output argument"
usage
exit 1
fi
OUTPUT="$2"
shift;;
-subtitles)
if [ -z "$2" ]; then
echo "ERROR: Missing -subtitles argument"
usage
exit 1
fi
SUBTITLES="$2"
SUBTITLES_CMD="-add $SUBTITLES"
if [ ! -e "$SUBTITLES" ]; then
echo "ERROR: Subtitles file does not exist!"
usage
exit 1
fi
shift;;
-bitrate)
if [ -z "$2" ]; then
echo "ERROR: Missing -bitrate argument"
usage
exit 1
fi
FORCE_BITRATE="$2"
echo "bitrate: $FORCE_BITRATE"
shift;;
-ratio)
if [ -z "$2" ]; then
echo "ERROR: Missing -ratio argument"
usage
exit 1
fi
RATIO=$2
shift;;
-timelimit)
if [ -z "$2" ]; then
echo "ERROR: Missing -timelimit argument"
usage
exit 1
fi
STOP_FFMPEG="-t $2"
shift;;
-keeptemp)
KEEPTEMP=1;;
-help|--help)
usage
exit 1;;
*)
echo "Unknown option $1"
usage
exit 1
esac
shift
done

if [ -z "$INPUT" ]; then
echo "ERROR: No input filename given!"
usage
exit 1
fi
if [ -z "$OUTPUT" ]; then
echo "ERROR: No output filename given!"
usage
exit 1
fi

echo "Using input params:"
echo "Input: $INPUT"
echo "Output: $OUTPUT"
if [ ! -z "$SUBTITLES" ]; then
echo "Subtitles: $SUBTITLES"
fi
if [ ! -z "$FORCE_BITRATE" ]; then
echo "Forced bitrate: $FORCE_BITRATE"
fi
if [ ! -z "$STOP_FFMPEG" ]; then
echo "ffmpeg timelimit option \"$STOP_FFMPEG\" set"
fi

if [ "$INPUT" = "$OUTPUT" ]; then
echo "Input and output are the same. You should not do that!"
exit 0
fi


####
# Check Dependencies:
# - mplayer
# - faac
# - ffmpeg
# - bc
# - MP4Box
# - x264
CheckDependency mplayer
CheckDependency ffmpeg
CheckDependency bc
CheckDependency MP4Box
CheckDependency faac
CheckDependency x264



####
# First collect information about the video using mplayer
# x-resolution, y-resolution and original fps
#
VINFO=`mplayer "$INPUT" -endpos 0 -ao null -vo null 2>/dev/null |grep "VIDEO:"`
XRES=`echo $VINFO | cut -f 3 -d " " | cut -f 1 -d "x"`
YRES=`echo $VINFO | cut -f 3 -d " " | cut -f 2 -d "x"`
FPS=`echo $VINFO | cut -f 5 -d " "`
echo "xres=$XRES, yres=$YRES, fps=$FPS"



####
# Calculate good estimation for the bitrate of the video
# using defined RATIO
#
BITRATE=`echo "$XRES * $YRES * $RATIO" | bc | cut -f 1 -d "."`
echo $BITRATE
if [ ! -z $FORCE_BITRATE ]; then
BITRATE=$FORCE_BITRATE
echo "Overriding bitrate: $BITRATE"
fi



####
# Audio encoding
#
FAAC_OPTS=" \
-P \
-R 44100 \
-B 16 \
-C 2 \
-c 44100 \
-q 120"

echo "$0: Starting audioencoding"

rm -f "$OUTPUT".aac
nice -n 15 ffmpeg $STOP_FFMPEG -i "$INPUT" -ar 44100 -f s16be - | \
nice -n 15 faac $FAAC_OPTS -o "$OUTPUT".aac -

# This hack is here in place if ffmpeg refuses to recognize audio
# stream format. This is bad code, but at the moment best that I can
# think of. We use mplayer to decode audio into pcm and encode itt
# afterwards with faac.
if [ -z "`cat "$OUTPUT".aac`" ]; then
echo "OMG aac file empty!"
rm -f "$OUTPUT".aac
ffmpeg $STOP_FFMPEG -i "$INPUT" -acodec copy "$OUTPUT".aac
mplayer -quiet -vo null -vc dummy \
-ao pcm:waveheader:file="$OUTPUT".2.wav "$OUTPUT".aac
rm -f "$OUTPUT".aac
ffmpeg -i "$OUTPUT".2.wav -ar 44100 "$OUTPUT".wav
faac "$OUTPUT".wav -o "$OUTPUT".aac
rm -f "$OUTPUT"*.wav
# exit 1
fi


####
# Video encoding
#
X264_OPTS="
--sar 1:1 \
--partitions all \
--aud \
--level 4.1 \
--ref 3 \
--mixed-refs \
--bframes 3 \
--b-pyramid \
--direct auto \
--direct-8x8 1 \
--8x8dct \
--analyse all \
--subme 6 \
--me umh \
--b-rdo \
--bime \
--weightb \
--trellis 1 \
--threads 1 \
--no-ssim \
--no-psnr \
--progress"

echo "$0: Starting video encoding"

rm -f "$OUTPUT".264
nice -n 15 ffmpeg $STOP_FFMPEG -i "$INPUT" -f rawvideo - | \
nice -n 15 x264 -B $BITRATE $X264_OPTS -o "$OUTPUT".264 - ${XRES}x${YRES}

if [ -z "`cat "$OUTPUT".264`" ]; then
echo "OMG 264 file empty!"
exit 0
fi



####
# A/V multiplexing
#
echo "$0: Starting MP4Box multiplexing"
MP4Box -new \
-add "$OUTPUT".aac \
-add "$OUTPUT".264 \
$SUBTITLES_CMD \
-fps $FPS \
"$OUTPUT"



####
# Cleanup
#
if [ -z $KEEPTEMP ]; then
rm -f "$OUTPUT".aac "$OUTPUT".264
fi



####
# End
#
echo ""
echo "Done! Result in $OUTPUT"

[nm]

Why not use the crf mode instead of estimating a suitable bitrate from the specified ratio and source resolution? That way the variability caused by different sources wouldn't be much of a problem.

[jva]

Why not use the crf mode instead of estimating a suitable bitrate from the specified ratio and source resolution? That way the variability caused by different sources wouldn't be much of a problem.

So I would assume that means simply removing bitrate option and replace that with --crf option. I will try this. The scale of crf is 0.0 -> 1.0?

As far as I understand, the crf affects only the bitrate of the output stream. I was actually wondering whether the other coding parameters of x264 have affect on the quality in general. Or let's say that of course they do, but whether the combination of x264 options in the script is a "bad choice" in general and that would be causing degration in quality with certain scenes. I will test this more as well. My goal is to find generic-enough parameters that work with my ps3 and that I can use regularily with the script with any kind of material. I do not know whether that is actually impossible.

[nm]

So I would assume that means simply removing bitrate option and replace that with --crf option.
Yes.
I will try this. The scale of crf is 0.0 -> 1.0?
The range is 1.0-50.0 and people generally use something between 15 and 30 (20 is a good starting point). Lower value means better quality and higher bitrate.

As far as I understand, the crf affects only the bitrate of the output stream. I was actually wondering whether the other coding parameters of x264 have affect on the quality in general. Or let's say that of course they do, but whether the combination of x264 options in the script is a "bad choice" in general and that would be causing degration in quality with certain scenes. I will test this more as well. My goal is to find generic-enough parameters that work with my ps3 and that I can use regularily with the script with any kind of material. I do not know whether that is actually impossible.
I think your options are quite balanced, but to get good quality in average bitrate -based encoding mode, you'll need to run two passes (--pass 1, --pass 2). In CRF mode the second pass is not needed. When encoding in two passes, you can lower some settings (but not the bitrate) for the first pass to increase encoding speed without sacrificing quality (this is called turbo in some frontends like MEncoder).

As for other options, I'd suggest adding --no-fast-pskip to avoid blocking in some cases. Also the AQ patch may be useful if you see annoying blocks in dark parts of the image. The severity of this problem depends on the source video and the display you use.

[jva]

Ok, I modified the x264 params of the script to utilize --crf option and used value 20 as starting point. I was happy to see that one of those very difficult scenes look now much more crisp and the movement in there is not so blurred anymore.

I also took the --no-fast-pskip into use at the same time. It is hard to tell whether that caused any difference at this point. I think that the most of the quality improvement came from --crf option.

And also I tested the encoded video that it still works with ps3, so the params are good in that sense as well. Thanks for the help! :)

[kaid]

Hey, thanks for the script! I just wanted to post my own quite simple transcoding-solution here using only mplayer and x264, which works really awesome. Requires a lot of diskspace (According to my approximations about 380GB for a 90 minute uncompressed YUV in full 1920x1080@24fps), but from what i saw from your script it's about the same... I'm still looking for a transcoding pipeline (no Windows, only Linux/OSX!) that works by directly streaming output to input, so you don't have to have 380GB of free space. So far all tries to pipe the output of mplayer have been unsuccessful. I figured mencoder with x264 should theoretically be all you need for that, but I haven't found anything that works yet, the only mencoder solution i found would not work since (my?) mencoder does not seem to recognize either the -ovc x264 switch nor the -x264encopts one... Anyone?

Okay, here goes, it's very basic (but works, thanks to mplayer's YUV4MPEG output being exactly what x264 wants as input! ;-):


mplayer -vo yuv4mpeg -nosound <inputfile>; mv stream.yuv stream.y4m; \
x264 -r 3 -B 10000 --threads 4 --level="4.1" -o <output.mkv/264> stream.y4m; rm stream.y4m


This encodes on all my 4 G5s, if you have fewer or more CPUs adjust the "threads" accordingly. The resulting file is in profile Main@Level4.1. I haven't done much tweaking with the encoding options, but the streams work perfectly on PS3 as it is (I plan on adding 2pass though). This is for 1080p, since that's almost exclusively the ones that do not work on PS3 using tsmuxer due to too many reference frames. You could up the ref-frames (-r parameter) to 4 for 1080p and to 9 for 720p cause that's the maximum the Level4.1 (=Bluray) spec allows for, but I haven't tried this yet, so I won't guarantee compatibility... Besides many people tell me anything beyond 3 reference frames doesn't yield any better results anyway! ;-)

Any suggestions for some good x264 encoding parameters that don't take 5 days to encode but still deliver good quality? ;-)

[cogman]

meh, Ill through my script into the bucket :D


#!/bin/sh

mkfifo video.y4m
mkfifo audio.wav

for i in 1 2 3 4 5 6 7 8
do
s=$(expr $i + 8)
title=S2Ep$s
echo $s
neroAacEnc -ignorelength -q 0.45 -if audio.wav -of $title.m4a &
x264 video.y4m -o $title.264 --threads auto --no-fast-pskip -t 2 --mixed-refs --me tesa -w --direct auto -A all --crf 21.0 -r 5 -m 6 -b 16 --b-pyramid --progress --b-rdo -8 &
mplayer dvd://$i -vo yuv4mpeg:file=video.y4m -vf hqdn3d -ao pcm:fast:file=audio.wav -alang en -af volnorm=1 -cache 8192 -lavdopts threads=5
done

rm video.y4m
rm audio.wav



I use this script to encode my mash disks. It works pretty slick. I tried throwing a muxer in there but for some strange reason I always got corrupted data from it. It has a denoiser from mplayer turned on and volume normalization. It requires x264, mplayer, and neroAacEnc in the /usr/bin dir. Something like this could easily be adapted for any dvd, but this is just useful for my disks that have 8 episodes on them.

Also, I should note that the two files are made initially with mkfifo. So this doesn't really touch the Hard-drive except to write data (unless you don't have a lot of ram)

[nm]

Hey, thanks for the script! I just wanted to post my own quite simple transcoding-solution here using only mplayer and x264, which works really awesome. Requires a lot of diskspace (According to my approximations about 380GB for a 90 minute uncompressed YUV in full 1920x1080@24fps), but from what i saw from your script it's about the same... I'm still looking for a transcoding pipeline (no Windows, only Linux/OSX!) that works by directly streaming output to input, so you don't have to have 380GB of free space. So far all tries to pipe the output of mplayer have been unsuccessful.
Use a FIFO: mkfifo stream.y4m
mplayer -vo yuv4mpeg:file=stream.y4m -nosound <inputfile> &
x264 -r 3 -B 10000 --threads 4 --level="4.1" -o <output.mkv/264> stream.y4m
rm stream.y4m

I figured mencoder with x264 should theoretically be all you need for that, but I haven't found anything that works yet, the only mencoder solution i found would not work since (my?) mencoder does not seem to recognize either the -ovc x264 switch nor the -x264encopts one... Anyone?
Install x264 libraries and headers to the system ($ make install) and then configure and rebuild MPlayer/MEncoder ($ ./configure; make; make install). After running ./configure for MPlayer, check the output for any messages about x264. It should tell that the x264 libraries were found.

This encodes on all my 4 G5s, if you have fewer or more CPUs adjust the "threads" accordingly.
Or let x264 select the appropriate number of threads automatically (--threads 0).

[nm]

Also, I should note that the two files are made initially with mkfifo. So this doesn't really touch the Hard-drive except to write data (unless you don't have a lot of ram)
You might want to add those commands to your script so that is has some chances of working when people copy&paste it directly :)

[cogman]

You might want to add those commands to your script so that is has some chances of working when people copy&paste it directly :)

ahh, good point. just a sec.

[kaid]

Thanks nm for your hints, very very useful information! ;-D
I do wonder how mkfifo works though. So you detach the mplayer decoding thread and launch x264. so far so good. but: since decoding is obviously much faster than encoding, won't the threads run out of sync rather soon, requiring you to still have 380GB on the HD as soon as RAM runs out? 8) the decoding thread should be stalled to match the encoding thread's speed, how would we go about doing that?

[cogman]

Thanks nm for your hints, very very useful information! ;-D
I do wonder how mkfifo works though. So you detach the mplayer decoding thread and launch x264. so far so good. but: since decoding is obviously much faster than encoding, won't the threads run out of sync rather soon, requiring you to still have 380GB on the HD as soon as RAM runs out? 8) the decoding thread should be stalled to match the encoding thread's speed, how would we go about doing that?

thats what mkfifo does. basically mplayer is being told that the medium is very slow and busy when it is writing, only freeing up when x264 actually reads something. some programs will fail after a long period of time, but most will treat it like 5 1/2 inch floppies.

[kaid]

Ahaaaa.... 8) Thanks for the info, this is EXACTLY what I was looking for! ;-D Unix never ceases to amaze me. somewhere, somehow, there's ALWAYS just what you need! ;-) And this is true in so many respects it boggles the mind...

[kaid]

One more question that is not 100% related, but you guys can probably shed some light: is there an option to tell x264 to do slice-encodes? If I am re-encoding, I would like the streams to be playable on older Dualcore (or Dual CPU) to maximize playatibility. I gathered from the web that x264 used to always do slice-encodes (just like Quicktime still does), and that this was their way of multithreading encoding back before there was a multithreaded full-frame encoder (it just happened to work great on several cores while decoding, too!). But alas, the multithreaded full-frame encoder solution was implemented and slice-encoding was scrapped. Completely?? If so: why not still have it as an option at least? This seems as illogical as encoding in Level 5.1 by default, which is just intended for extremely high resolutions, bitrates and fps (which no normal CPU on the planet could play anyway, so wtf?)
Also, I am looking for a multithreaded x264-decoder (for all the non-sliced 1080p!). No, coreavc is not an option, opensource preferred, since I'm running PPC! ;-) I do know someone made an mplayer patch back in september 2007 that did 2-threaded single-frame decoding, and that scaled up to about 130%. Not perfect, but hey, it sure beats looking at that 99% in top while seeing your video stutter, right? ;-) Why has that patch never made it into mplayer? Or has it, and there's an option to turn it on i did not find? ;-)

Here's the patch & some words from its maker:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-September/035877.html

[ChuckleWorthy]

Great post jva/Jarkko - very interesting script. I'm working on a similar task here (http://forum.doom9.org/showthread.php?p=1149392#post1149392). I shall quite probably make use of some of your programming techniques etc. Ta.

Also this post here (http://forum.doom9.org/showthread.php?p=1157654#post1157654) works really well for encoding x264 streams for FF/Rewinding on a PS3.

Hopefully one of above links may be of some use...
Cheers
Chuckle

[akupenguin]

why not still have it as an option at least?more options = more code. I am strongly opposed to code which I see as useless, especially if you're asking me to maintain it. (And it doesn't matter if someone else volunteers for the maintaining part; it's in x264, it'll be in the way whenever I want to modify something related.)
And since frame-based threading is the Right Thing To Do, I consider slice-threaded decoding not worth supporting even if it is the only kind that exists at the moment.
This seems as illogical as encoding in Level 5.1 by defaultBlame the standards committee for not including an "unrestricted" level. That would would have been ideal, since it would have the same denotation of "I don't guarantee much of anything" without the connotation "this stream is hard to play".

[kaid]

X264 changelog from 20th of July:

- autodetect level based on resolution/bitrate/refs/etc, rather than defaulting to L5.1
if vbv is not enabled (and especially in crf/cqp), we have to guess max bitrate, so we might underestimate the required level. <- tough this can still be a problem for Hardware Devices @ very high bitrates but most of the Chips nowdays should be able to even maintain stable (no stutter) with spikes that could happen with X264.


Thanks so much Akupenguin! ;-D Can I just say at this point that x264 really really rocks? 8) Even though the PPC version may not be as highly optimized as the x86 version, it still beats the living crap both in speed and quality out of anything Toast or Apple calls a good AVC-encoder! ;-)

Did you guys ever consider including an "uncrop" feature to 1280x720 or 1920x1080 in x264? A lot of people use x264 to transcode to AVC (probably all of them ;-) and quite often they may want to make the video AVCHD compatible (which requires uncropped resolutions).... I really have no idea how to tell mplayer to do this in my script, and it would be awesome if x264 took care of this! No scaling, just adding black borders where appropriate! ;-)


nm/cogman:
I did the whole thing with mkfifo now, and it worked fantastically, thanks once more! 8) Only thing was that I could not detach the mplayer output simply by adding &, probably because it won't start playing before x264 tries to read the file. I got around this by opening another terminal and entering the x264 line there, works just as well!

Oh, and one more thing about x264-encoding options: I did try constant rate factor encoding, as recommended above. With --crf 20 I got a ridiculously small file, it ended up with 3.6 MBit bitrate (full res 1080p that is!). And to be honest I cannot tell the difference to the 2pass CBR encode with 10.4 MBit I made afterwards! ;-) I really tried seeing artifacts, but I just can't find any! I knew H.264 was extremely efficient and that common bitrates are mostly way too high anyway, but THIS small for 1080p?? Without any visible artifacts? Wow!

[akupenguin]

Did you guys ever consider including an "uncrop" feature to 1280x720 or 1920x1080 in x264?
No. Letterboxing is evil, and I will do everything in my power to discourage people from it. Any decent player can handle arbitrary resolutions, and a standard that says otherwise isn't worth using.
What's AVCHD for, anyway? Surely everyone would be better off supporting plain AVC, of which AVCHD is just a special restricted case.

[kaid]

No. Letterboxing is evil, and I will do everything in my power to discourage people from it.

I know what you mean, the black bars in SVCD also were quite annoying! ;-)

Any decent player can handle arbitrary resolutions, and a standard that says otherwise isn't worth using.

This should be the case, but unfortunately we've got to make do with what we've got. What's more: By that reasoning you could also say that any decent player these days has auto-crop! ;-) VLC does as well as Mplayer...


What's AVCHD for, anyway? Surely everyone would be better off supporting plain AVC, of which AVCHD is just a special restricted case.

Well, if you have a PS3, there are quite some restrictions on plain AVC (I'm talking single files here: mp4 or m2ts!): No subtitles, no chapters, no multiple Audiotrack and worst of all no DTS... And as far as I know the only way to get these features on PS3 is via AVCHD... Which unfortunately does not support arbitrary resolutions like the XMB fileplayer does! It's really a dilemma...
With almost 15 Million PS3s out there already it is probably *the* most popular HD-player, compared to other standalone players for sure and even compared to AVC-capable HTPCs!...

Also, keep in mind that the Bluray spec wants it that way, too... And I would venture a guess there are some people out there also using x264 for authoring, since its speed, configurability and quality is as unmatched as its "price"! ;-)

[nm]

Did you guys ever consider including an "uncrop" feature to 1280x720 or 1920x1080 in x264? A lot of people use x264 to transcode to AVC (probably all of them ;-) and quite often they may want to make the video AVCHD compatible (which requires uncropped resolutions).... I really have no idea how to tell mplayer to do this in my script, and it would be awesome if x264 took care of this! No scaling, just adding black borders where appropriate! ;-)
Try the expand filter, like this:-vf dsize=1280:720:0,scale=0:0,expand=1280:720
Here, dsize & scale will fit any frame size at any aspect ratio within 1280x720 (square pixels) and expand does the letterboxing.

[kaid]

Wow. Thanks so much once more nm! ;-) Deep down i knew Mplayer could do it, I just didn't know where to look, hehe!...
Is there any tool that can do letterboxing without re-encoding? You know, like those lossless JPEG crop algos, only working in macroblock steps!.. I noticed tsmuxer has a greyed out uncrop feature, which must work without re-encoding (once it's actually implemented) because tsmuxer ist not an AVC encoder... Anyone know more about this?