Всем привет! У нас в мире есть такая мегасофтина, называется ffmpeg. Эта штуковина, условно говоря, конвертирует любой аудио или видео формат в любой другой и имеет при этом примерно 100500 опций (всякое упоковывание в контейнеры, рескейлинг хитрыми алгоритмами, и так далее).

Теперь собственно идея, до боли простая - можно ли хотя бы часть функционала перенести на FPGA, и даст ли это плюшки вроде очень быстрой конверсии какого-нть формата в какой-то еще? Для примера, представьте что у вас есть uncompressed avi с кадрами 1280х720 и звуком - вам нужно например умно преобразовать это в 4K разрешение и упаковать в MP4.

Вообщем интересует сама "поднимаемость" такой идеи. Какие-то аппаратные энкодеры видеосигналов уже делают в FPGA, но хочется понять реально ли это в принципе.

поиском по форуму. тема обсуждалась и вроде был клуб по интересам.

обсуждалась здесь, возможно еще где-то на форуме - не помню...

PS сделать реально - вопрос времени и желания...

О, вот оно как оказывается. Но что-то там тема заглохла. К тому же, может я чего не понимаю, но кажется там люди настроены на realtime транскодинг, у меня же вопрос, можно ли существенно ускорить процесс на FPGA. Чтобы дать контекст, у меня задачки такие: есть например час несжатого видео (720p, 8Gb), конверсия его в 4K (через XBR) занимает несколько часов. А хочется скормить AVI шайтан-машинке и чтобы она моментально (плюс-минус) выплюнула готовый MP4.

можно, но нужно сильно хорошо поработать.

Все поднимаемо. Сделали же на ПЛИС и H.264 и HEVC. Тут весь вопрос в трудозатратах и стоимости законченного решения. В моей практике гораздо проще было ставить ASSP-кодек на плату, который и 4K сконвертирует и работать будет "из коробки" (тот же fujitsu). Это дешевле, чем ставить ПЛИС, которая сможет справляться с аналогичными задачами.

Если хочется сделать это на FPGA, то я бы в сторону OpenCL посмотрел. Видел живьем немало демок по обработке изображений (включая распознавание) - все выглядело более чем достойно. Причем не обязательно иметь связку x86 host + PCIe accelerator. Можно поднять все в SoC'е. У самого все руки не доходят прототип сделать из борды на CV SoC + плата с сенсором изображения + дисплей и обработать видео в реальном времени на OpenCL. Как дойдут - поделюсь результатами.

Какая-то такая тема: https://www.youtube.com/watch?v=ythPvAPB4iI

Ну PCI или не PCI это детали, можно по-разному упаковать. Вопрос в том, можно ли покрыть большую часть функционала и какие кол-во FPGA/ARM/whatever на плате нужно чтобы это было возможно.

можно. лучше всего каскад топовый цинк + 2-4 топовых кинтекса.

Делал конвертацию raw потока с матрицы в jpeg поток(для trp вещания) и одновременно писал кадры в ддр, ниос параллельно запаковывает это все дело в avi и пишет на sd флеш. Работает на циклоне 5. Но это простой mjpeg, MP4 со всеми профилями сделать гораздо сложнее, ну и дороже соответственно

Идея поднимаемая. Но бессмысленная. Слишком много возни, фпга требуется большая.
Зачем из 720p делать 4к а потом паковать??? Кому такая дурь СЕЙЧАС нужна?

...для начала задачу описали бы свою четче...

Это был только пример. Вообще задача общего плана - кодировка аудио и видео данных. Нужно это многим.

Кстити, нашел уже как минимум одну железку которая делает именно то, что я предлагаю: http://www.signalogic.com/index.pl?page=ffmpeg

При формализации задачи возможно все, вопрос в том, что реально это занимает много ресурсов времени (очень много времени, если делать хорошо и на заказ).

Каким образом будет поддерживаться 100500 режимов перекодирования в ФПГА? Внешняя загрузка текущей конфигурации из МК?

Размер внешней памяти ограничит как минимум размер кадра и глубину обработки.

PS: Сколько я не пробовал перпаковывать в другой стандарт всякими ffmpeg - результат был хуже, чем скаченное в нужном стандарте из инета. Видимо получить качественный продукт непросто, надо нажать более пары кнопок и в более другом софте...

- Примерно так энкодер и работает.
- При перекодировании никогда лучше не будет. Есть вариант super-resolution, но он также имеет кучу проблем.

Либо реал тайм и понижение качества, либо куча памяти и значительное время ожидания. В теории последнее можно уменьшить, но память все равно нужна в большом количестве.

Но я думаю youtube примерно так и работает, заливка на большом разрешении, потом перекодирование железом, они могут себе это позволить.