Вероятно, из-за того, что видео H264 обычно преобразуется из RGB в пространство YUV как 4: 2: 0 перед применением сжатия (хотя само преобразование формата является алгоритмом сжатия с потерями, что дает 50% экономии пространства).

YUV-420 начинается с изображения RGB (красный зеленый синий) и преобразует его в YUV (в основном один канал интенсивности и два канала «оттенка»). Затем каналы Hue подбираются путем создания одного образца оттенка для каждого квадрата 2X2 этого оттенка.

Если у вас есть нечетное количество RGB-пикселей по горизонтали или по вертикали, у вас будут неполные данные для последнего столбца пикселя или строки в подвыборном цветовом пространстве кадра YUV.

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

bitand (x, 65534)

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

. Моя задача заключалась в автоматическом масштабировании большого количества видеофайлов до половины разрешения.

scale=-2,ih/2 приводят к слегка размытым изображениям

Причина:

• входные видео имеют [fормат отображения g1] формата изображения (DAR)
• scale масштабирует размеры реального кадра
• во время предварительного просмотра, размеры новых видео должны быть исправлены с помощью DAR , который в случае довольно низкого разрешения видео (360x288 , DAR 16: 9) может привести к размытию раствора

:

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

:

• output_height = input_height / 2
• output_width = output_height * original_display_aspect_ratio
• как output_width , так и output_height теперь округлены до ближайшего меньшего числа, делящегося на 2
• setsar=1. output_dimensions теперь окончательны, коррекция соотношения сторон не применяется

Кто-то может найти это lpful.

LordNeckbeard имеет правильный ответ очень быстро

-vf scale=1280:-2

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

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

Просто используйте -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"

(Только для людей, которые ищут, как это сделать с масштабированием)