Исходная задача: изменить размер (WxH) видеопотока с предельно низкими потерями в качестве картинки.
Решения:
От изменения только средствами FFmpeg отказался по причине того, что в полученном видео сильно запикселизованы кадры - при воспроизведении на глаз ПОЧТИ не видно (нужно сравнивать с оригиналом, чтобы заметить изменения), да и на паузе воспроизведения аналогично, но на извлечённых кадрах просто ужас (а тут дело принципа в сохранении качества каждого кадра)! Принял решение обработать покадрово: разложить в jpg, изменить размер всех кадров и «склеить» видеоряд.
Стартуем так:
ffmpeg -i 1101.mp4 -f image2 -qmin 1 -qmax 1 1/%d.jpg
А пока выполняется проведём не сложные манипуляции и расчёты:
Количество кадров в теории можно посчитать исходя из количества кадров в секунду и количества этих самых секунд (если верить SMPlayer - 23:50, по данным FFMpeg там не целое число секунд). И того:
(23×60×24)+(1×50×24) = 34320
Теперь надо посчитать кадры в каталоге 1. В баше не силён, и привык не искать простых путей:

function dsa { echo ${#} ;}
function asd { dsa `ls $1` ;}
asd 1

34320

Полученное количество кадров минус то, которое должно получиться в теории:
34331−((23×60×24)+(1×50×24)) = 11
Даже если приведёный выше код по подсчёту файлов некорректен - но врядли даст погрешность всего в 11 кадров (а это около полусекунды) на почти 24 минуты видео. Не плохо, но совсем то, что ожидалось. Приступим к задуманному: convert -resize 50% из каталога 1 в каталог 2, ждём, склеиваем,
ffmpeg -f image2 -i %d.jpg -r 24 -vcodec libx264 -vpre slow -crf 1 -threads 0 a.mp4
Смотрим... И ЧУДО! - результирующий видеопоток длится по данным SMPlayer 22:53! Разбиваем на кадры:

asd 3

32952

34331−((22×60×24)+(1×53×24)) = 1379 кадров потеряно?!
1379÷24 = 57,458333333 секунд куда-то делись...
Проверяем количество кадров в секунду - их 24! Склеиваем всё в каталоге 3 и за ради эксперемента - расщепляем полученный в эксперементе ролик на кадры... 31 585!
Или тут безбожно врёт SMPlayer о количестве кадров, или же FFMpeg нереально глупит не выдавая никаких сообщений-предупреждений...

FFMpeg собрал сам, по распространённому в рунете мануалу «Установка самого последнего FFMpeg и х264 на Ubuntu 10.4». Для тех, кто понимает больше меня в сборке софта показываю на всякий случай конфигурацию FFMpeg (возможно кому-то что-то там удасться разглядеть полезного):
FFmpeg version SVN-r25529, Copyright (c) 2000-2010 the FFmpeg developers
built on Oct 20 2010 12:53:41 with gcc 4.4.3
configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab
libavutil 50.32. 3 / 50.32. 3
libavcore 0. 9. 1 / 0. 9. 1
libavcodec 52.92. 0 / 52.92. 0
libavformat 52.84. 0 / 52.84. 0
libavdevice 52. 2. 2 / 52. 2. 2
libavfilter 1.53. 0 / 1.53. 0
libswscale 0.12. 0 / 0.12. 0
libpostproc 51. 2. 0 / 51. 2. 0

P.S.
Для исходного видео-файла FPS от MPlayer 24.000


P.P.S.
Попробовал два прохода:

ffmpeg -i «$1» -pass 1 -vcodec libx264 -s «$2» -vpre veryslow_firstpass -b 1024k -bt 1024k -threads 0 -f rawvideo -an -y /dev/null && ffmpeg -i «$1» -pass 2 -vcodec libx264 -s «$2» -vpre veryslow -b 1024k -bt 1024k -threads 0 RESIZE_«$1»_.mp4

Выглядит хорошо, НО обязательно требует установки битрейта (-b 1024k -bt 1024k) - а его хотелось бы иметь такимже как и у исходного материала без танцев с выяснениями нужных цифр... Чтобы перекодирующий скрипт мог работать так:
Resizer [input_file_name] [Output_WxH_video]
И при перекодировании действительно изменялся ТОЛЬКО РАЗМЕР КАРТИНКИ и кадры в результате были чисты от разных квадратиков и размываний...