Я намагаюся кодувати .mp4 відео з набору кадрів за допомогою FFMPEG за допомогою кодека libx264.

Це команда, яку я виконую:

/usr/local/bin/ffmpeg -r 24 -i frame_%05d.jpg -vcodec libx264 -y -an video.mp4

Я іноді отримую таку помилку:

[libx264 @ 0xa3b85a0] height not divisible by 2 (520x369)

Після невеликого пошуку навколо, здається, що проблема пов'язана з алгоритмом масштабування і може бути виправлена, додавши аргумент -vf.

Однак у моєму випадку я не хочу робити будь-яке масштабування. В ідеалі я хочу, щоб розміри були абсолютно такими ж, як і рамки. Будь-яка порада? Чи є якесь співвідношення сторін, яке h264 виконує?

Відповідь на оригінальне запитання, яке не хоче масштабувати відео,:

-vf "pad=ceil(iw/2)*2:ceil(ih/2)*2"

Команда:

ffmpeg -r 24 -i frame_%05d.jpg -vcodec libx264 -y -an video.mp4 -vf "pad=ceil(iw/2)*2:ceil(ih/2)*2"

В основному, .h264 потребує рівних розмірів, тому цей фільтр:

1. Розділіть початкову висоту та ширину на 2
2. Закруглете його до найближчого пікселя
3. Помножте його ще раз на 2, зробивши таким чином парне число
4. Додайте до цього числа чорні пікселі

Ви можете змінити колір прокладки, додавши параметр фільтра :color=white. Дивіться документацію на майданчик .

Просто використовуйте -2

З документації щодо фільтра масштабу :

Якщо одне із значень -nз n > 1, масштабом фільтр також буде використовувати значення , яке підтримує співвідношення сторін вхідного зображення, обчислене з іншим зазначеного розміром. Після цього, проте, переконайтеся, що обчислений розмір ділиться на, nі, якщо потрібно, відрегулювати значення.

Приклади

Встановіть ширину 1280, а висота автоматично буде обчислена для збереження співвідношення сторін, а висота поділяється на 2:

-vf scale=1280:-2

Те саме, що вище, але замість оголошеної висоти; залишаючи ширину, яку повинен вирішувати фільтр:

-vf scale=-2:720

"ділиться на 2"

Як вимагає x264, "ділиться на 2 на ширину та висоту" потрібне для YUV 4: 2: 0 кольорових підпробових виходів. 4: 2: 2 знадобиться "ділиться на 2 на ширину", а 4: 4: 4 цих обмежень не має. Однак більшість гравців, які не базуються на FFmpeg, можуть правильно розшифрувати лише 4: 2: 0, тому часто ви бачите ffmpegкоманди з -pix_fmt yuv420pопцією під час виведення відео H.264.

Caveat

На жаль, ви не можете використовувати -2як ширину, так і висоту, але якщо ви вже вказали один вимір, то використання -2- це просте рішення.

Якщо ви хочете встановити якусь вихідну ширину і мати вихід у тому ж співвідношенні, що і вихідний

scale=720:-1 

і не впасти з цією проблемою, тоді можна використовувати

scale="720:trunc(ow/a/2)*2"

(Просто для людей, які шукають, як це зробити за допомогою масштабування)

Проблема з scaleрішеннями тут полягає в тому, що вони спотворюють вихідне зображення / відео, які майже ніколи не потрібні.

Натомість я знайшов найкраще рішення - додати 1-піксельну колодку до непарного виміру. (За замовчуванням накладка чорна і важко помітна.)

Проблема з іншими padрішеннями полягає в тому, що вони не узагальнюють над довільними розмірами, оскільки вони завжди прокладають.

Це рішення додає 1-піксельну накладку на висоту та / або ширину, лише якщо вони непарні:

-vf pad="width=ceil(iw/2)*2:height=ceil(ih/2)*2"

Це ідеально, тому що він завжди робить правильно, навіть коли не потрібні прокладки.

Ймовірно, це пов'язано з тим, що відео H264 зазвичай перетворюється з RGB в простір YUV як 4: 2: 0 перед застосуванням стиснення (хоча саме перетворення формату є алгоритмом стиснення втрат, що призводить до 50% економії місця).

YUV-420 починається з RGB (червоно-зеленого синього) зображення і перетворює його в YUV (в основному один канал інтенсивності та два канали "відтінку"). Канали Hue потім підпробовуються, створюючи один зразок відтінку для кожного 2X2 квадрата цього відтінку.

Якщо у вас є непарна кількість RGB-пікселів або по горизонталі, або по вертикалі, ви будете мати неповні дані для останнього стовпчика пікселя або рядка в підпробовому просторі відтінку кадру YUV.

LordNeckbeard має правильну відповідь, дуже швидко

-vf scale=1280:-2

Для android, не забудьте додати

"-preset ultrafast" and|or "-threads n"

Ви також можете використовувати bitandфункцію замість trunc:

bitand (x, 65534)

зробить те саме, що trunc(x/2)*2і на мою думку це прозоріше.
(Розгляньте тут 65534 магічне число;))

Моє завдання полягало в автоматичному масштабуванні багатьох відеофайлів до половини роздільної здатності .

scale=-2,ih/2призводять до трохи розмитих зображень

причина:

• вхідні відео мали їх співвідношення сторін екрану (DAR) набір
• scale масштабує реальні розміри кадру
• під час попереднього перегляду розміри нових відеозаписів повинні бути виправлені за допомогою DAR, що у випадку відео з низькою резонансною здатністю (360x288, DAR 16: 9) може призвести до розмивання

рішення:

-vf "scale='bitand(oh*dar, 65534)':'bitand(ih/2, 65534)', setsar=1"

пояснення:

• вихід_висота = вхід_висота / 2
• output_width = output_height * original_display_aspect_ratio
• і вихідна ширина, і вихідна висота тепер округлені до найближчого меншого числа, що ділиться на 2
• setsar=1означає, що параметри output_dimensions тепер остаточні, корекцію співвідношення сторін не слід застосовувати

Хтось може вважати це корисним.