Самый большой размер входного изображения при кодировании видео?

Я получил кучу очень больших 16-битных видео размером около 65535×65535 пикселей. По сути, это высококачественные таймлапс-панорамы. Я хочу преобразовать их в фильм 7680×4320 (8K UHD, 8 бит). Меня не слишком волнует формат, но хочется какой-нибудь компрессии.

Я думаю, что могу изменить размер изображений с помощью Python, чтобы уменьшить их до HEVC (8192 × 4320) ...

Есть ли что-нибудь, что будет воспроизводить (с VLC?) и может обрабатывать большее количество пикселей, чем 8192×4320? Каковы мои варианты?

Когда я пытаюсь использовать FFmpeg, я получаю такие ошибки, как:

[mjpeg @ 000000000062eae0] [IMGUTILS @ 000000000023ed40] Picture size 20000x19824 is invalidN/A
Error while decoding stream #0:0: Invalid data found when processing input
Любой проигрыватель, основанный на ffmpeg/libav, скорее всего, потерпит неудачу, если это сделает ffmpeg. Вам придется уменьшить размер видео, а затем конвертировать. Поскольку ваш вход — MJPEG, вы можете попытаться извлечь кадры без потерь в виде последовательности изображений. Уменьшите размер с помощью другого приложения (imagemagick?), а затем закодируйте этот результат.ffmpeg -i in.mov -c copy frames%d.jpg
Я полагаю, что могут быть аппаратные ограничения на воспроизведение этих файлов, независимо от программного обеспечения.

Ответы (1)

FFmpeg срабатывает при этом операторе Imgutils.cв функцииav_image_check_size()

if ((int)w>0 && (int)h>0 && (w+128)*(uint64_t)(h+128) < INT_MAX/8) return;  [ else error() ]

где INT_MAXопределяется limits.hкак минимум 32767( 2^15-1) или больше, в зависимости от вашего компилятора.

Компиляция с помощью 64-битного компилятора позволит увеличить изображения.

Он срабатывает при (int)w<=0 || (int)h<=0 || stride >= INT_MAX || stride*(uint64_t)(h+128) >= INT_MAXИ INT_MAX фиксируется на 2 ^ 31-1. На какой компилятор limit.h вы ссылаетесь? У меня GCC 6.3.0. Я скомпилировал 64-битный ffmpeg с использованием 64-битной цепочки инструментов, и я также получаю ту же ошибку для размера OP.
На самом деле приведенного вами утверждения нет в текущем коде. Тот, который я цитировал, был добавлен туда в декабре 2016 года.
@Mulvya - en.m.wikibooks.org/wiki/C_Programming/C_Reference/limits.h - Стандарт говорит, что разрешено большее значение. Это INT_MAX является минимальным значением в соответствии со Стандартом (Ни один совместимый компилятор C не может иметь более низкое значение. Дальнейший поиск в Google показывает, что размер некоторых ОС составляет 64 бита. Я приму более новый источник. Подставьте его значения. Подойдет ли половина размера? Если он собирается использовать Python, я не думаю, что он будет принимать произвольно большие значения, но он может принимать значения бит 64. Размер, который он хочет воспроизводить, подразумевает, что у него есть экран 8K (или он архивирует на будущее).
Я был бы удивлен, если бы это было 64-битное ограничение, потому что я использую 64-битную версию ffmpeg, в частностиffmpeg-20170321-db7a05d-win64-static
Просто комментарий: какого черта FFMPEG использует (подписанные) целые числа для H и W? Если бы они были unsigned int, то все было бы прекрасно и ладно до 65535 (включительно).