Перейти к содержанию

cyclone + mpeg2

Прошу дать оценку необходимого количества LEs для реализации mpeg2 4:2:0 25fps 420х350pixel.
Всем спасибо

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Очень сильно зависит от поколения Cyclone.
Чем спрашивать тут, лучше поискать реальные цифры.
Во-первых, mpeg 2 доступен, как opensource. Если не ошибаюсь.
Во-вторых, можно взять product brief от закрытых кодеков. Там, как правило, приводятся такие цифры.

И у вас даже не указано, вам нужен кодер, декодер или и то, и другое.

Битрейт и качество тоже не указаны. Никто адекватных цифр конкретно под ваши данные не назовет.
По mpeg-4, конечно, больше данных. По mpeg-2 так сходу и не нашел.

Исходя из своего опыта работы с mjpeg и h.264, грубо на уровне ощущений в 15k-20k LEs можно уложиться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Цитата(x736C @ Oct 20 2017, 16:20) <{POST_SNAPBACK}>
Исходя из своего опыта работы с mjpeg и h.264, грубо на уровне ощущений в 15k-20k LEs можно уложиться.

Поток будет состоять только из I кадров в случае H.264?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Цитата(AVR @ Oct 20 2017, 18:38) <{POST_SNAPBACK}>
Поток будет состоять только из I кадров в случае H.264?

Не очень понял вопрос. MPEG-2 ведь тоже имеет межкадровое сжатие.
Поэтому и написал, что количество требуемых ресурсов ПЛИС напрямую зависит от качества и битрейта. То есть от того, какие опции включены.

Но вообще я могу и ошибаться. Так как субъективные ощущения — это одно, а реальный кодек — другое.
MJPEG на более солидное разрешение влезает спокойно в 10-15k.
H.264 в самом простом виде и тоже для более солидного разрешения (1024x768) требует 40k от MAX 10.
Без модуля LME (Light Motion Estimation), то есть только Intra 16x16 encoder — 15k. При этом не требуется внешняя память.

Но требуемое количество ресурсов очень сильно зависит от разрешения. Танцую от этих цифр. Качественно можно представить.
Я бы все равно использовал dev. board с запасом хотя бы тысяч 50 LE. А после уже определял бы целевую ПЛИС.
Изменено пользователем x736C

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Прошу прощения за делитанские вопросы, но в теме mpeg не имею ни малейшего опыта.
Есть железка с cyclone4 6тыщ LE с ддр на борту и нандой. Дали наборы видео файлов которые нужно выводить по событию
Посмотрел ip core по теме, они достаточно большие но и возможности вывода там на порядок выше. В действующую плату не влазят.
Есть чипы которые могут осуществить декодирования. Необходима ветка по которой начать идти.
Возможно данных мало , чтоб оценить необходимое количество ресурса.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Мой совет такой. Перекодируйте все это в MJPEG. Для вашего разрешения должно хватить 6k.
MJPEG декодеры есть в сети в opensource. И тут выкладывалось.
Зависит, конечно, от множества параметров. Например, влезет ли все в NAND.
А куда выводите? То есть нужен декодер, верно?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Спасибо за ответ.
Сейчас проект на циклоне работает с набором спрайтов загружаемых с нанды в ддр и дальше графический контроллер и управление с арма.
Полученое видео объема 34мб. Разложил на кадры получил 250мб. Была наработка своего рара на лету. Но результат дал 150мб, не мало но не отлично.
Количество видео фрагментов большое, и единственным решением оставить формат не изменным.
Очень хотелось использовать действующую железку. Но уже мысли от баре металл на арме, линукса , андроида, и спец чипов.
Вывод на вга монитор с разрешением 640 на 480
На выходные теория mpeg себе в помощь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Попробуйте разложить видео в кадры jpeg, при этом подобрать такое качество jpeg, чтобы размер сильно не поменялся. То есть общий коэффициент сжатия остался прежний. Естественно, это надо делать какими-то batch-средствами. Если качество при этом вас устроит, то почему бы не перейти на mjpeg.
Количество фрагментов не должно пугать, все можно перекодировать одним крошечным скриптом.
Не очень представляю общую архитектуру. Может быть, можно вообще на ARM вынести декодирование. Что за ARM и какое он место занимает в архитектуре.
Есть еще mjpeg-2 декодер opensource. Можно попробовать его. Но вероятно тоже придется перекодировать исходные фрагменты, т.к. декодер может поддерживать не все режимы. И еще вопрос, уместится ли он в 6k.
http://opencores.org/project,mpeg2fpga

Вот неплохая ссылка, можно оценить, сколько занимает jpeg decoder в совершенно различных ПЛИС.
http://www.visengi.com/products/jpeg_hardware_decoder
В 6k ни один не укладывается. Тем более, что это только jpeg. Нужен еще парсер mjpeg контейнера. Скорее всего это и невозможно.
Причем для jpeg от размера кадра величина кодера/декодера не сильно зависит. Если вообще зависит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Ошибся. mjpeg-2 следует читать как mpeg-2.

Цитата(hardgame @ Oct 20 2017, 20:52) <{POST_SNAPBACK}>
Полученое видео объема 34мб. Разложил на кадры получил 250мб. Была наработка своего рара на лету. Но результат дал 150мб, не мало но не отлично.

Это очень странные цифры. Если свой аналог архиватора, работая на лету, жмет в полтора раза, то возникает вопрос. В каком графическом формате хранились разложенные кадры?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация