hardgame 0 20 октября, 2017 Опубликовано 20 октября, 2017 · Жалоба Прошу дать оценку необходимого количества LEs для реализации mpeg2 4:2:0 25fps 420х350pixel. Всем спасибо Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 20 октября, 2017 Опубликовано 20 октября, 2017 · Жалоба Очень сильно зависит от поколения Cyclone. Чем спрашивать тут, лучше поискать реальные цифры. Во-первых, mpeg 2 доступен, как opensource. Если не ошибаюсь. Во-вторых, можно взять product brief от закрытых кодеков. Там, как правило, приводятся такие цифры. И у вас даже не указано, вам нужен кодер, декодер или и то, и другое. Битрейт и качество тоже не указаны. Никто адекватных цифр конкретно под ваши данные не назовет. По mpeg-4, конечно, больше данных. По mpeg-2 так сходу и не нашел. Исходя из своего опыта работы с mjpeg и h.264, грубо на уровне ощущений в 15k-20k LEs можно уложиться. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
1891ВМ12Я 0 20 октября, 2017 Опубликовано 20 октября, 2017 · Жалоба Исходя из своего опыта работы с mjpeg и h.264, грубо на уровне ощущений в 15k-20k LEs можно уложиться. Поток будет состоять только из I кадров в случае H.264? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 20 октября, 2017 Опубликовано 20 октября, 2017 (изменено) · Жалоба Поток будет состоять только из 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. А после уже определял бы целевую ПЛИС. Изменено 20 октября, 2017 пользователем x736C Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
hardgame 0 20 октября, 2017 Опубликовано 20 октября, 2017 · Жалоба Прошу прощения за делитанские вопросы, но в теме mpeg не имею ни малейшего опыта. Есть железка с cyclone4 6тыщ LE с ддр на борту и нандой. Дали наборы видео файлов которые нужно выводить по событию Посмотрел ip core по теме, они достаточно большие но и возможности вывода там на порядок выше. В действующую плату не влазят. Есть чипы которые могут осуществить декодирования. Необходима ветка по которой начать идти. Возможно данных мало , чтоб оценить необходимое количество ресурса. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 20 октября, 2017 Опубликовано 20 октября, 2017 · Жалоба Мой совет такой. Перекодируйте все это в MJPEG. Для вашего разрешения должно хватить 6k. MJPEG декодеры есть в сети в opensource. И тут выкладывалось. Зависит, конечно, от множества параметров. Например, влезет ли все в NAND. А куда выводите? То есть нужен декодер, верно? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
hardgame 0 20 октября, 2017 Опубликовано 20 октября, 2017 · Жалоба Спасибо за ответ. Сейчас проект на циклоне работает с набором спрайтов загружаемых с нанды в ддр и дальше графический контроллер и управление с арма. Полученое видео объема 34мб. Разложил на кадры получил 250мб. Была наработка своего рара на лету. Но результат дал 150мб, не мало но не отлично. Количество видео фрагментов большое, и единственным решением оставить формат не изменным. Очень хотелось использовать действующую железку. Но уже мысли от баре металл на арме, линукса , андроида, и спец чипов. Вывод на вга монитор с разрешением 640 на 480 На выходные теория mpeg себе в помощь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 20 октября, 2017 Опубликовано 20 октября, 2017 · Жалоба Попробуйте разложить видео в кадры 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 от размера кадра величина кодера/декодера не сильно зависит. Если вообще зависит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 20 октября, 2017 Опубликовано 20 октября, 2017 · Жалоба Ошибся. mjpeg-2 следует читать как mpeg-2. Полученое видео объема 34мб. Разложил на кадры получил 250мб. Была наработка своего рара на лету. Но результат дал 150мб, не мало но не отлично. Это очень странные цифры. Если свой аналог архиватора, работая на лету, жмет в полтора раза, то возникает вопрос. В каком графическом формате хранились разложенные кадры? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться