LINUX.ORG.RU

Забавы с FFMpeg - изменение WxH видеопотока без потерь в качестве кадров


0

1

Исходная задача: изменить размер (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]
И при перекодировании действительно изменялся ТОЛЬКО РАЗМЕР КАРТИНКИ и кадры в результате были чисты от разных квадратиков и размываний...

★★

>Принял решение обработать покадрово: разложить в jpg, изменить размер всех кадров и «склеить» видеоряд.

Bitches don't know 'bout motion jpeg & two pass encoding?

anonymous ()
Ответ на: комментарий от Led

об арифметике

Я привёл это только из-за того что числа ОЧЕНЬ разные. Хочу плнять причину по которой видеоряд при склеивании теряет кадры и становится короче по времени.

zzdnx ★★ ()
Ответ на: комментарий от zzdnx

А так же хочу научиться менять параметр WxH без потери качества кадров.

При изменении размера кадров в сторону уменьшения размера ты теряешь качество в любом случае.

Deleted ()

ремукси в mkv без перекодироания с помощью mkvtoolnix и в заголовках поставь необходимое разрешение

плееры которые полностью поддерживают mkv буду уважать эти значения и выведут материал в заданном тобой виде

linuks ★★★★★ ()
Ответ на: комментарий от Deleted

ты теряешь качество в любом случае.

При изменении размера кадров в сторону уменьшения размера ты теряешь качество в любом случае.

Это так, и я это понимаю. Просто сейчас я подготавливаю видео для последующего монтажа и там важно, чтобы КАЖДЫЙ КАДР был без пикселизации(и прочих сильно заметных на каждом кадре искажений)... Именно по этой причине я начал поднимать муть с извлечением кадров и изменением размера каждого по отдельности - извлечённые кадры чисты, и при изменении размера тоже, но при «склеивании» кадров результат не совпадает с оригиналом, хотя качество именно такое, как мне нужно получить.

ремукси в mkv без перекодироания с помощью mkvtoolnix

Хорошая идея, пробовал, но нужен именно mp4.
Пробовал ремуксить в матрёшку с последующим пересохранением в mp4 - ремукс проходит хорошо, но после пересохранения появляются искажения. Попробовал mkvMergue с сохранением в mp4-формат (в нём поддерживается и это), НО видео не поменяло параметров WxH! То есть в заголовке матрёшки написано «использовать такие WxH» - и плеер это делает, а в mp4 такой функции просто нету (или я не прав, но в общем, этот метод не прокатил)

zzdnx ★★ ()
Ответ на: ты теряешь качество в любом случае. от zzdnx

Если честно, то для просмотре мне хватает и простого ffmpeg с параметрами «libx264 -vpre veryslow -crf 22» - отлично сжимает, хоть и продолжительно. Для домашнего просмотра / преера-телефона - самое оно. Не стал бы я сюда писать, если бы от меня требовалось такое качество видео потока...

zzdnx ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.