[dryadae 0]

Собственно, сабж. Интересуют все плюсы и минусы того или иного решения применительно к задаче видео(де)компрессии в реальном времени, то есть изначально предполагается высокий уровень обращений к буферу (операции чтения). Чтобы мне не говорили, я В КУРСЕ того, чтоб Blackfin не работает с DDR. Вот и хотелось бы понять, имеет ли смысл создание собственного контроллера (CoolRunner / Spartan 3E), который бы переадресоовывал обращения BF в DDR, ради призрачной "скорости", или же достаточно будет взять обычную PC133 на 32 бита, и работать на "половинной", по сравнению с новыми технологиями, частоте.

 

P.S. BF предполагается использовать в качестве системного контроллера, а также для генерации видеосигнала при декомпрессии.

P.S.S. Внешняя память должна работать, как двух-, или даже четырёхпортовая (только чтение, запись ведётся монопольно, из одного источника)

[des00 25]

Собственно, сабж. Интересуют все плюсы и минусы того или иного решения применительно к задаче видео(де)компрессии в реальном времени, то есть изначально предполагается высокий уровень обращений к буферу (операции чтения). Чтобы мне не говорили, я В КУРСЕ того, чтоб Blackfin не работает с DDR. Вот и хотелось бы понять, имеет ли смысл создание собственного контроллера (CoolRunner / Spartan 3E), который бы переадресоовывал обращения BF в DDR, ради призрачной "скорости", или же достаточно будет взять обычную PC133 на 32 бита, и работать на "половинной", по сравнению с новыми технологиями, частоте.

 

P.S. BF предполагается использовать в качестве системного контроллера, а также для генерации видеосигнала при декомпрессии.

P.S.S. Внешняя память должна работать, как двух-, или даже четырёхпортовая (только чтение, запись ведётся монопольно, из одного источника)

 

Не буду ходить вокруг да около сразу вопрос в лоб : ВЫ просчитывали требуемые ПОТОКИ данных? в применении к вашему энкодеру/декодеру.

 

если нет разговор не имеет смысла

[rat 0]

Собственно, сабж. Интересуют все плюсы и минусы того или иного решения применительно к задаче видео(де)компрессии в реальном времени, то есть изначально предполагается высокий уровень обращений к буферу (операции чтения). Чтобы мне не говорили, я В КУРСЕ того, чтоб Blackfin не работает с DDR. Вот и хотелось бы понять, имеет ли смысл создание собственного контроллера (CoolRunner / Spartan 3E), который бы переадресоовывал обращения BF в DDR, ради призрачной "скорости", или же достаточно будет взять обычную PC133 на 32 бита, и работать на "половинной", по сравнению с новыми технологиями, частоте.

 

P.S. BF предполагается использовать в качестве системного контроллера, а также для генерации видеосигнала при декомпрессии.

P.S.S. Внешняя память должна работать, как двух-, или даже четырёхпортовая (только чтение, запись ведётся монопольно, из одного источника)

 

ИМХО Вы сразу лишаете себя встроенной поддержки DDR, а это серьезный минус. "BF предполагается использовать в качестве системного контроллера, а также для генерации видеосигнала при декомпрессии" - видеосигнал должен генерировать(конечным автоматом) все-таки ПЛИС, а BF заниматься обработкой и заливать необходимую видеоинформацию в ПЛИС.

[dxp 34]

Собственно, сабж. Интересуют все плюсы и минусы того или иного решения применительно к задаче видео(де)компрессии в реальном времени, то есть изначально предполагается высокий уровень обращений к буферу (операции чтения). Чтобы мне не говорили, я В КУРСЕ того, чтоб Blackfin не работает с DDR. Вот и хотелось бы понять, имеет ли смысл создание собственного контроллера (CoolRunner / Spartan 3E), который бы переадресоовывал обращения BF в DDR, ради призрачной "скорости"

Допустим, Вы сделаете классный мост (с DDR контроллером) на Спартанце, который будет обеспечивать поток 266 32-битных мегаслов в секунду. Подцепите это к Blackfin'у. А Blackfin по внешней шине может максимум только 133 16-битных мегаслова в секунду и все, т.е., четверть от того трафика. Неувязочка, не находите?

[Stanislav 0]

Собственно, сабж. Интересуют все плюсы и минусы того или иного решения применительно к задаче видео(де)компрессии в реальном времени, то есть изначально предполагается высокий уровень обращений к буферу (операции чтения). Чтобы мне не говорили, я В КУРСЕ того, чтоб Blackfin не работает с DDR. Вот и хотелось бы понять, имеет ли смысл создание собственного контроллера (CoolRunner / Spartan 3E), который бы переадресоовывал обращения BF в DDR, ради призрачной "скорости", или же достаточно будет взять обычную PC133 на 32 бита, и работать на "половинной", по сравнению с новыми технологиями, частоте.

 

P.S. BF предполагается использовать в качестве системного контроллера, а также для генерации видеосигнала при декомпрессии.

P.S.S. Внешняя память должна работать, как двух-, или даже четырёхпортовая (только чтение, запись ведётся монопольно, из одного источника)

Вообще-то организация внутренней памяти BlackFin-а (многопортовая по множеству 4 К блоков), в совокупности с многоканальным DMA контроллером, позволяет в ряде случаев получить производительность при использовании SDRAM, сравнимую с производительностью только с внутренней памятью. Смысл в том, что пока одни блоки обрабатываются, другие подкачиваются в прозрачном режиме по DMA. Для обработки видео должно быть самым цимесом. Сам так делать пока не пробовал, но на сайте AD есть аппликухи, посвящённые данному вопросу.

2 dxp

ADSP-BF535 и ADSP-BF561 имеют 32-битную внешнюю шину данных.

Хотя, это не принципиально.

[dxp 34]

Вообще-то организация внутренней памяти BlackFin-а (многопортовая по множеству 4 К блоков), в совокупности с многоканальным DMA контроллером, позволяет в ряде случаев получить производительность при использовании SDRAM, сравнимую с производительностью только с внутренней памятью. Смысл в том, что пока одни блоки обрабатываются, другие подкачиваются в прозрачном режиме по DMA. Для обработки видео должно быть самым цимесом. Сам так делать пока не пробовал, но на сайте AD есть аппликухи, посвящённые данному вопросу.

Да, тут нет никаких трудностей, сам так сделать как раз и собираюсь. Специально проверял в железе - все работает - DMA качает блоки данных на максимальной (для SDRAM) скорости, потери только на регенерацию и при переходе на другой базовый адрес (банк, строка). По окончании передачи он (DMA) может сгенерировать прервание - удобно сообщить ядру, что блок данных закачан.

 

ADSP-BF535 и ADSP-BF561 имеют 32-битную внешнюю шину данных.

Хотя, это не принципиально.

535 уже отстой несколько, а про 561 не подумал :).

[dryadae 0]

Не буду ходить вокруг да около сразу вопрос в лоб : ВЫ просчитывали требуемые ПОТОКИ данных? в применении к вашему энкодеру/декодеру.

 

если нет разговор не имеет смысла

Написано жне - МНОГО. Чем больше, тем лучше. И, желательно, с кэшем.

 

видеосигнал должен генерировать(конечным автоматом) все-таки ПЛИС, а BF заниматься обработкой и заливать необходимую видеоинформацию в ПЛИС.

А шумы?

 

535 уже отстой несколько, а про 561 не подумал

В принципе, я на 561-ый и нацеливалась. У 535-го (который, кстати, с индексом P) внутри уж больно много всякой мути, не нужной для мобильного приложения.

 

ADSP-BF535 и ADSP-BF561 имеют 32-битную внешнюю шину данных.

Хотя, это не принципиально.

Вот именно. 32-битных DDR-чипов на рынке пока не наблюдается, а корпус на 16 бит на двойной частоте - это то же самое, что и 32-бита на одинарной. При этом, что немаловажно, число корпусов желательно ещё и минимизировать...

Скажем, 133 Мгц*4 (за вычетом регенерации и пр.) ~ 532 Мб/сек Это не так много, как хотелось бы, но явно лучше, чем толпа корпусов с дифференциальным клоком Сомнения гложут лишь по поводу того, что BF не поддерживает burst reads>1, и может выжрать таким образом львиную долю полосы пропускания.

Вообще-то в качестве вариантов рассматривалась трёхпортовая SGRAM (PC133), но её мне, к сожалению, найти так и не удалось :(

[des00 25]

Не буду ходить вокруг да около сразу вопрос в лоб : ВЫ просчитывали требуемые ПОТОКИ данных? в применении к вашему энкодеру/декодеру.

 

если нет разговор не имеет смысла

Написано жне - МНОГО. Чем больше, тем лучше. И, желательно, с кэшем.

 

УУУУ, да вам только энкодеры и писать, много это сколько ?

CIF avc 100MB/c,

D1 avc 500MB/c,

HD 1080 avc 3200MB/c

 

А кеш, как говорит мой знакомый гуру (без обид) придумали люди, которые не умеют считать свои потоки в память.

 

Желаю удачи.

[dryadae 0]

УУУУ, да вам только энкодеры и писать, много это сколько ?

Вообще-то, помимо raw throughput, существует ещё такое понятие, как latency - которая, ясное дело, совсем не нужна.

 

 

CIF avc 100MB/c,

D1 avc 500MB/c,

HD 1080 avc 3200MB/c

Откуда взялись эти числа? С потолка? Память нужна для хранения референсного кадра при генерации векторов движения, или применении оных к предшествующему.

После 4:0:0 дискретизации от этих raw data останутся рожки да ножки; правда, при чтении будет ещё некоторый процент повторов (довольно большой - именно для этого нужен кэш), плюс - потери на регенерацию, плюс - поток на формирователь видеосигнала (декодер), который пока неизвестен.

Кстати, 100 Мб/сек у CIF ну никак не получается - 320*240*3*30fps=6,9 Мб/с! И это - TrueColor, чего, ясное дело, в рилтаймовых кодеках не бывет.

 

А кеш, как говорит мой знакомый гуру (без обид) придумали люди, которые не умеют считать свои потоки в память.

Ну говорит, и что с того?

Изменено 2 июня, 2006 пользователем dryadae

[Stanislav 0]

УУУУ, да вам только энкодеры и писать, много это сколько ?

Вообще-то, помимо raw throughput, существует ещё такое понятие, как latency - которая, ясное дело, совсем не нужна.

 

 

CIF avc 100MB/c,

D1 avc 500MB/c,

HD 1080 avc 3200MB/c

Откуда взялись эти числа? С потолка? Память нужна для хранения референсного кадра при генерации векторов движения, или применении оных к предшествующему.

После 4:0:0 дискретизации от этих raw data останутся рожки да ножки; правда, при чтении будет ещё некоторый процент повторов (довольно большой - именно для этого нужен кэш), плюс - потери на регенерацию, плюс - поток на формирователь видеосигнала (декодер), который пока неизвестен.

Кстати, 100 Мб/сек у CIF ну никак не получается - 320*240*3*30fps=6,9 Мб/с! И это - TrueColor, чего, ясное дело, в рилтаймовых кодеках не бывет.

 

А кеш, как говорит мой знакомый гуру (без обид) придумали люди, которые не умеют считать свои потоки в память.

Ну говорит, и что с того?

Похоже, "исправляться" Вы упорно не желаете. :) Затею с видеокомпрессором на 3-м спартане, Вам, похоже, пришлось оставить, несмотря на Вашу отчаянную самоуверенность, за явной бесперспективностью. Только вот полезных выводов Вы, по-моему, не сделали: до хрипоты пытаетесь спорить с теми, кто пытается Вам помочь (см. пост #2) и задаёте вопросы в форме утверждения, вместо того, чтобы понять, о чём же именно идёт речь. Что резко выделяет Вас на фоне действительно понимающих проблему людей, и не в лучшем свете.

[dryadae 0]

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

 

"Исправляться", как Вы выразились, я не перед кем здесь не обязана - особенно перед Вами.

 

задаёте вопросы в форме утверждения

Очередные возрастные фантазии?

 

Что резко выделяет Вас на фоне действительно понимающих проблему людей, и не в лучшем свете.

А к "действительно понимающим", бесспорно, относитесь Вы (и кто бы сомневался, при такой-то постановке вопроса?)

 

И последнее. Кодек будет сделан - на Спатране, поскольку другие решения или чересчур дорогостоящие, или слишком громоздкие. Специально для Вас - с возможностью апгрейда до стандарта HDTV :P

[makc 192]

К порядку, уважаемые!

Эта тема подходит к тому, чтобы превратиться в выяснению личных отношений, что недопустимо.

Что же касается Вас, dryadae, умерьте немного свой пыл и постарайтесь снизить тон. Вам пытаются помочь и высказывают свою личную точку зрения, а не правила которым Вы обязаны следовать. Если же Вам не интересно мнение участников, то не спрашивайте, делайте свое дело, как считаете нужным.

[des00 25]

CIF avc 100MB/c,

D1 avc 500MB/c,

HD 1080 avc 3200MB/c

Откуда взялись эти числа? С потолка? Память нужна для хранения референсного кадра при генерации векторов движения, или применении оных к предшествующему.

После 4:0:0 дискретизации от этих raw data останутся рожки да ножки; правда, при чтении будет ещё некоторый процент повторов (довольно большой - именно для этого нужен кэш), плюс - потери на регенерацию, плюс - поток на формирователь видеосигнала (декодер), который пока неизвестен.

Кстати, 100 Мб/сек у CIF ну никак не получается - 320*240*3*30fps=6,9 Мб/с! И это - TrueColor, чего, ясное дело, в рилтаймовых кодеках не бывет.

 

Эти числа взяты из просчета реал-тайм энкодеров AVC, при реализации системы со след параметрами

AVC main profile, с поддержкой I, P, B фреймов, intra 16x16 all modes, inter8x8 support quarter pel resolution, mv := [-512 : 511.75], 2 ref.frame support, MBAFF support, CABAC/CAVLC,

при реализации на одном чипе с одним контролером памяти.

Все вычисляеться очень просто, выделяються требования на поддержку фич стандарта и оговариваеться качество выходного стрима (ксттаи скажу вам по секрету I frame only делаеться вообще на лету), просчитываются потоки и объемы коэффициентов, которые нужно куда то сложить, определяються таймлайны доступа к памяти и т.д.

 

Если вам не нужно большое качество вашего энкодера, то это одно решение, если же вы хотите зажать

1080HD в 15 мегабит (с хорошим качеством картинки), то это совершенно другое решение, в общем решайте и думайте. Энкодер это не только закапчуреный поток, и вы хотя бы определись что вы будете жать, mpeg1, mpeg2, mpeg4, avc, mjpeg и т.д и загляните в эти стандарты, узнаете много нового (особенно про avc)

 

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

 

Удачи.

[dryadae 0]

Отвечаю по порядку. Stanislav ранее утверждал, что Blackfin должен лучше соответствовать моим задачам, нежели FPGA. После непродолжительных консультаций ;) на www.blackfin.org выяснилось, что производительности новейшего BF561 может хватить лишь на обработку CIF в реальном масштабе времени, чего здесь явно недостаточно. Тем не менее, данный процессор ввиду его широкой шины оказался наиболее подходящим на роль системного контролеера и, возможно, контроллера памяти... если бы только не DDR-альтернатива.

 

Далее, мне говорили, будто бы изделия от ADI выделяют намного меньше тепла, нежели FPGA и, как следствие, больше подходят для мобильных приложений. Очередная неправда - на том же форуме выяснилось, что при выполнении одинаковых задач одни Блакфины греются так, что к ним и не прикоснёшься, тогда как другие остаются почи холодными. То есть всё это, опять же, чистой воды лотерея.

 

Насчёт реализуемости - вопрос достаточно спорный. Повторяю, речь не идёт о какой-то сверхзадаче, чтобы кодек за 10$ кодировал поток с высочайшим качством для показа его на широком экране. Главное - низкий битрейт при условии приемлемого качества изображения, и низких вычислительно-транспортных задержках, практически исключающих буферизацию (и, как следствие, B-фреймы). Таким образом, основная задача FPGA - выполнить motion estimation по заданному в памяти референсному фрейму, а это требует высокой скорости чтения из памяти, по возможности поддержанной кэшированием, и хорошим внутренним параллелизмом

Однако, в связи возмоожным прогрессом в области передатчиков ISM-диапазона (которого пока не наблюдается - доступные по цене 2.4 ГГц пока, к сожалению, ограничиваются 800 Кб/c), система должна легко адаптироваться и к бОльшим битрейтам, чем заданный изначально (или определять их сама, на "лету")

 

А пыл здесь совершенно не при чём; это вполне резонная реакция на утверждение "Вы не знаете ничего, потому что я вас умнее". Хотя... кто знает? HD было приведено, ясное дело, "для красного словца" - хотя первоначально, разумеется, хотелось бы сделать нечто, достаточно универсальное решение, и способное работать, в тои числе, и с "широкими" каналами.

 

Энкодер это не только закапчуреный поток, и вы хотя бы определись что вы будете жать, mpeg1, mpeg2, mpeg4, avc, mjpeg и т.д и загляните в эти стандарты, узнаете много нового (особенно про avc)

Наверное, вы хотели сказать - во что? Потому что "жать MPEG" звучит, по меньшей мере, странно... Если так, то это будет нечто вроде MPEG-1/2 без B-фреймов, для (негарантированной) передачи по датаграммному протоколу.

 

P.S. Кто-нибудь, кстати, кстати, знает, что случилось с blackfin.org? вот уже некоторое время подряд (ок. 2-х недель) сервер совершенно не отвечает на запросы.

:?: :?: :?:

[des00 25]

Насчёт реализуемости - вопрос достаточно спорный. Повторяю, речь не идёт о какой-то сверхзадаче, чтобы кодек за 10$ кодировал поток с высочайшим качством для показа его на широком экране. Главное - низкий битрейт при условии приемлемого качества изображения, и низких вычислительно-транспортных задержках, практически исключающих буферизацию (и, как следствие, B-фреймы).

Вот тут то ИМХО и кроется подвох, на маленьких разрешениях добиться высокого качества можно либо на малых квантайзерах (что не даст низкого битрейта), либо усложняя алгоритмику (вводя партицирование, деблок), что не даст низких вычислительных ресурсов.

Кстати откуда у вас будет лететь сырое видео ? И еще дополнение B фрейм весит раза в 2-4 меньше P фрейма, который в свою очередь весит раза в 2 меньше I фрейма (цифры вроде не путаю)

 

Таким образом, основная задача FPGA - выполнить motion estimation по заданному в памяти референсному фрейму, а это требует высокой скорости чтения из памяти, по возможности поддержанной кэшированием, и хорошим внутренним параллелизмом

ну что хорошая задача, но на маленьких разрешениях толку от ДДР не будет никакого, вам тогда лучше поставить статику и делать поиск прямо в ней, хотя зависит от алгоритма. И что бы делать поиск по CIF высокого параллелизма не требуеться, вот то ли дело на ХД.....

 

Кстати каким именно алгоритмом вы собираетесь пользоваться? искать по реконстрактнутой пикче или по исходной ? как будете валить вектора фпга в дсп ?

 

А пыл здесь совершенно не при чём; это вполне резонная реакция на утверждение "Вы не знаете ничего, потому что я вас умнее".

 

Ну это вы себе придумываете, я спросил вас об оценке объема памяти и пропускной способности, вы же сказали дайте широко и побольше, тогда вам на x86 с 4мя гигами памяти нужно.

 

Наверное, вы хотели сказать - во что? Потому что "жать MPEG" звучит, по меньшей мере, странно... Если так, то это будет нечто вроде MPEG-1/2 без B-фреймов, для (негарантированной) передачи по датаграммному протоколу.

 

Ну у нас в фирме кто как говорит, я всегда говорю "что будем жать"

 

ИМХО нечто вроде mpeg-1/mpeg-2 не подходит для малых разрешений, сказываеться блочность изображения. И как я понимаю вы собираетесь row данные в mpeg2 - TS заворачивать для передачи по радиоканалу ? или просто row данные будете валить ?

 

И все таки вы будете отказываться от P фреймов ? т.е. B фрейм, это тот же P фрейм, но с 2 мя реф. кадрами.

 

Дополнительно вы собираетесь платить лицензионные отчисления авторам стандарта ?