[Stanislav 0]

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

Пытаюсь! Только вот довести до Вас это "нечто, действительно существенное", увы, не получается.

Ни о какой неприязни, конечно, речь не идёт. Только о манере общения.

 

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

Дожив до моих, может, и Вы поумнеете.

 

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

Чрезвычайно польщён...

 

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

Вы хотели получить выходной поток в 170 кбит/с, да ещё без B-фреймов, да ещё для картинки, снимаемой в движении. Интересно, какой размер кадра при этом Вас бы устроил?

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

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

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

[alexdsp 0]

dryadae

Добавлю немного своего мнения.

Для начала уточню: 1) Я делал собственные алгоритмы сжатия для BF. 2) Они работают в железе.

 

По поводу подключения внешней DDR через FPGA. Если вы задумали это делать через асинхронную шину, то сразу надо понимать то, что весь обмен по ней происходит на эффективной частоте SCLK/2 (так как вствляется один такт принудительного "setup"), то есть пиковый трафик будет вдвое меньше чем на SDRAM. Как уже тут говорили, BF не умеет делать "burst" при чтении, но если всё заранее спроектировать, то чтение можно перевести на DMA.

Вот пример моей системы, как образец что может BF, а чего не может.

ADSP-BF532 393 MHz, внешняя SDRAM 131 MHz

Покадровый полноэкранный вэйвлет, сжатие оригинальным арифметическим кодеком.

Видео и производительность:

Сжатие цветного 352x288 - немногим более 50 fps плюс 10 процентов вычислительного ресурса свободны

Сжатие цветного 704x576 примерно 20 fps

Скорость можно ещё поднять процентов на 10 если убрать встроенную обработку видео (шумопонижение, многоточечный детектор движения и по мелочам)

 

Скоро начну делать новый алгоритм базирующийся на текущем. Всё уже продумано, но в железе пока не тестировал. Предварительный расклад таков. По отношению к вышенаписанному, скорость поднимается от 1.5 до 2-х раз при остальных неизменных параметрах.

 

При всём этом хочу напомнить, что этот процессор имеет всего-лишь 16-разрядную шину и не умеет делать "burst" по чтению. Видите, на самом деле всё не так уж и страшно :)

[Stanislav 0]

...Покадровый полноэкранный вэйвлет, сжатие оригинальным арифметическим кодеком.

Видео и производительность:

Сжатие цветного 352x288 - немногим более 50 fps плюс 10 процентов вычислительного ресурса свободны

Сжатие цветного 704x576 примерно 20 fps

Скорость можно ещё поднять процентов на 10 если убрать встроенную обработку видео (шумопонижение, многоточечный детектор движения и по мелочам)

 

Скоро начну делать новый алгоритм базирующийся на текущем. Всё уже продумано, но в железе пока не тестировал. Предварительный расклад таков. По отношению к вышенаписанному, скорость поднимается от 1.5 до 2-х раз при остальных неизменных параметрах...

Результаты впечатляют.

Скажите, а межкадровую обработку делать не планируете?

[alexdsp 0]

...Покадровый полноэкранный вэйвлет, сжатие оригинальным арифметическим кодеком.

Видео и производительность:

Сжатие цветного 352x288 - немногим более 50 fps плюс 10 процентов вычислительного ресурса свободны

Сжатие цветного 704x576 примерно 20 fps

Скорость можно ещё поднять процентов на 10 если убрать встроенную обработку видео (шумопонижение, многоточечный детектор движения и по мелочам)

 

Скоро начну делать новый алгоритм базирующийся на текущем. Всё уже продумано, но в железе пока не тестировал. Предварительный расклад таков. По отношению к вышенаписанному, скорость поднимается от 1.5 до 2-х раз при остальных неизменных параметрах...

Результаты впечатляют.

Скажите, а межкадровую обработку делать не планируете?

 

Планирую, но уже в третьей ревизии.

Помимо сжатия в проекте ещё очень много составляющих которые нужно реализовать.

А по сжатию, надо лишь натянуть режим 704x576 в цвете до 25 fps, и это будет карашо! :)

[Stanislav 0]

Помимо сжатия в проекте ещё очень много составляющих которые нужно реализовать.

А по сжатию, надо лишь натянуть режим 704x576 в цвете до 25 fps, и это будет карашо! :)

Безусловно!

А примеры сжатых файлов выложить куда-нить можете? С декомпрессором, если он нестандартный, ессно...

Интересно было бы заценить...

[vetal 0]

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

Можно подробнее.

На сколько я понимаю DDRх16@85MHz(2 слова за период)=SDRх32@85Mhz(1 слово за период). Или я не прав?

Экономия в уменьшении количества сигналов требующих трассировки, за счет более эффективного использования сонхронизации.

[rat 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), но её мне, к сожалению, найти так и не удалось :(

 

Что шумы? Делал видеосигнал на ПЛИСе(потом 12-bit ЦАП), особых шумов не наблюдал, видел несколько работающих схем у коллег по этой же схеме - на шумы никто не жаловался.

[alexdsp 0]

Stanislav

Разумеется кодек полностью нестандартный, но и не "open source".

А по поводу картинок, то соотношение размер/качество примерно эквивалентно тому что получается при JPEG сжатии благодаря тому, что у меня нет возможности на сложное статистическое оценивание материала в реальном времени, в отличие от JPEG кодеков на PC со значительно более толстыми процессорами. Но благодаря более прогрессивной трансформации и энтропийному сжатию (против Хаффмана у JPEG) ситуация выправляется. Разве что характер искажений при сильном квантовании у нас разный. JPEG рассыпается "квадратиками" (DCT), а у меня появляется "акварельность", более сильная размытость картинки (fullscreen wavelet). Психовизуально - второй вариант лучше.

vetal

На сколько я понимаю DDRх16@85MHz(2 слова за период)=SDRх32@85Mhz(1 слово за период). Или я не прав?

Экономия в уменьшении количества сигналов требующих трассировки, за счет более эффективного использования сонхронизации.

В целом, всё верно, но только к сожалению, у современных блэкфинов нет контроллера DDR, а применение моста ASYNC -> DDR на FPGA приведёт к "уполовиниванию" пикового трафика, так как обмен по асинхронной шине ведётся (эффективно) на половинной частоте шины. А DDR как раз и хорош этим самым "пиковым" трафиком, ради чего весь "сыр-бор" разгорелся.

[dryadae 0]

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

Дожив до моих, может, и Вы поумнеете.

Настолько!? Благодарю, увольте :tongue:

 

 

Вы хотели получить выходной поток в 170 кбит/с, да ещё без B-фреймов, да ещё для картинки, снимаемой в движении. Интересно, какой размер кадра при этом Вас бы устроил?

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

 

(dryadae @ Jun 4 2006, 23:03)

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

Что именно из перечисленного на Ваш взгляд является глупостью? Насчёт более холодных BF - это мне говорили, в том числе, и Вы. Если про лотерею с тепловыделением -то, коли не верите сами, можете посмотреть на соответствующих форумах.

 

Да, кстати, поток я указывала не 170 Кбит/сек, а от 170 и до 882.

 

 

dryadae

Добавлю немного своего мнения.

Для начала уточню: 1) Я делал собственные алгоритмы сжатия для BF. 2) Они работают в железе.

 

По поводу подключения внешней DDR через FPGA. Если вы задумали это делать через асинхронную шину, то сразу надо понимать то, что весь обмен по ней происходит на эффективной частоте SCLK/2 (так как вствляется один такт принудительного "setup"), то есть пиковый трафик будет вдвое меньше чем на SDRAM.

 

Как уже тут говорили, BF не умеет делать "burst" при чтении,

Да, я как бы в курсе.

 

но если всё заранее спроектировать, то чтение можно перевести на DMA.

Разумеется, через 2-D DMA - а как же иначе?

 

Вот пример моей системы, как образец что может BF, а чего не может.

ADSP-BF532 393 MHz, внешняя SDRAM 131 MHz

Покадровый полноэкранный вэйвлет, сжатие оригинальным арифметическим кодеком.

Нельзя ли поподробнее? Можно в общих чертах - какой (если используется) алгоритм motion estimation, сколько в работе задействуется памяти (в т.ч и внешней), задействуются ли прерывания и, если да, насколько активно; какое питание - батерея, или сеть? И, главное, насколько низким может быть итоговый битрейт?

Да, кстати... как критичен Ваш поток к ошибкам связи?

 

Видео и производительность:

Сжатие цветного 352x288 - немногим более 50 fps плюс 10 процентов вычислительного ресурса свободны

Сжатие цветного 704x576 примерно 20 fps

Скорость можно ещё поднять процентов на 10 если убрать встроенную обработку видео (шумопонижение, многоточечный детектор движения и по мелочам)

704x576 - это по отдельным полям (704x288), или уже после деинтерлейса (если, конечно, он есть)? Как, кстати, Вы боретесь с высокой вертикальной частотой?

 

Скоро начну делать новый алгоритм базирующийся на текущем. Всё уже продумано, но в железе пока не тестировал. Предварительный расклад таков. По отношению к вышенаписанному, скорость поднимается от 1.5 до 2-х раз при остальных неизменных параметрах.

То есть 30 fps для PAL - это, по-Вашему, реально?

 

При всём этом хочу напомнить, что этот процессор имеет всего-лишь 16-разрядную шину и не умеет делать "burst" по чтению. Видите, на самом деле всё не так уж и страшно

Вот это уже действительно интересно. Как много в вашем проекте используется обращений к памяти? (Мб/с)

 

В целом, всё верно, но только к сожалению, у современных блэкфинов нет контроллера DDR, а применение моста ASYNC -> DDR на FPGA приведёт к "уполовиниванию" пикового трафика, так как обмен по асинхронной шине ведётся (эффективно) на половинной частоте шины. А DDR как раз и хорош этим самым "пиковым" трафиком, ради чего весь "сыр-бор" разгорелся.

Ну, не только; ещё он позволит сократить число проводников от чипов памяти к "контроллеру" с 53 до 30 с небольшим. Что может оказаться важным, если чипов больше одного, или больше одного устройства имеют доступ к памяти.

С другой стороны можно сделать выход "полной ширины"... а вот новость насчёт SLCK/2 - действительно неприятная. То-то меня ещё удивило, что в таблице таймингов для SDRAM указано число циклов n+14, а для асинхронной памяти - xn+12; теперь ясно, в чём подвох.

 

Да и почему мост должен быть обязательно ASYNC? Ведь, кажется, буферная схема SDRAM с одним тактом ожидания ничему не противоречит, и может быть реализована даже на CPLD... впрочем, стоимость CPLD с таким числом выводов будет явно завышенной.

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

[alexdsp 0]

Как уже тут говорили, BF не умеет делать "burst" при чтении

И тут есть мааленькая неточность, ну.. обманул немного. Контроллер SDRAM у BF так устроен, что он МОЖЕТ формировать бёрст на нечётное слово, но на большее он не способен. То есть - это даёт выигрышь при чтении двойного слова против двух чтений слов в отдельности. Но это так... будем считать, что не умеет.

 

Можно в общих чертах - какой (если используется) алгоритм motion estimation

Улыбнуло :) Для полноэкранной трансформации (каковой является применяемый у меня вэйвлет) не нужно делать оценку движения. Она нужна только в блочных алгоритмах, где размер исследуемой области очень мал и нужно найти корелляцию между этими областями. У меня же трансформация ведётся по всему видео массиву, а не по отдельным его кусочкам типа DCT 8х8.

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

Да, кстати... как критичен Ваш поток к ошибкам связи?

Для примера, алгоритм спокойно умещается во внутреннюю память BF531 + внешняя SDRAM 16Мб. Внешняя память ДОЛЖНА быть 4-х банковой.

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

ОЧЕНЬ низким битрейт быть у меня не может в силу нескольких причин. Сами понимаете, мой алгоритм был создан мною исходя из конкретных особенностей архитектуры процессора для обеспечения производительности в первую очередь. То есть - я должен сжимать CIF не особо напрягаясь. Затем - я должен также сжимать и полный PAL (скоро будет 25 fps). И при всём при этом иметь хорошее качество картинки (конкурентное) и всё такое прочее... Поэтому я вынужден был искать компромиссы и придумывать новые эффективные методы. От DCT я отказался. Правда, написал кодек для BF. От межкадровогого сжатия - тоже, так как это планировалось сделать в следующем этапе работы (было бы слишком сложно и непредсказуемо делать всё и сразу).

В данный момент на CIF(352x288 в цвете) как правило размер кадра при довольно сильном сжатии и как следствие - среднем качестве картинки не может быть меньше 5 кбайт (я это конечно могу изменить, но не буду, так как для нас это приемлимо). Разумеется, алгоритм полностью управляемый параметрически, я могу задать даже режим CBR указав желаемый объём кадра и система будет пытаться выполнить мои требования в реалтайме. То есть это мегабит в секунду. В будущем будет и межкадровое сжатие, там будет поток меньше на "спокойных" сценах, но не сейчас. В проекте очень много и других составляющих кроме сжатия - сеть, жёсткий диск и прочее... Но даже сейчас получилось лучше чем JPEG.

Как любой энтропийный алгоритм - к ошибкам критичен. Защищать нужно на транспортном уровне, что мы и делаем.

704x576 - это по отдельным полям (704x288), или уже после деинтерлейса (если, конечно, он есть)? Как, кстати, Вы боретесь с высокой вертикальной частотой?

Сжимаются два смежных полукадра 704х288 независимо, и как следствие - нет никакого интерлейсинга (если конечно правильно обратно выводить на экран) :)

Про высокую верт. частоту не понял юмора что то... :) Зачем с ней бороться-то? С какой частотой кадры приходят, с такой их и жмём. Если не успеваем, то поступаем наиболее оптимальным образом. Грамотно пропускаем полуполя, на фоне запускаем новый захват, синхронизируемся на первое поле и так далее и тому подобное...

То есть 30 fps для PAL - это, по-Вашему, реально?

Более чем реально, но... PAL - это 25 fps :)

Вот это уже действительно интересно. Как много в вашем проекте используется обращений к памяти? (Мб/с)

В нашем проекте 9 процессоров, 32 PAL камеры и прочее, и если сложить весь трафик.....уухх :))

Да и почему мост должен быть обязательно ASYNC? Ведь, кажется, буферная схема SDRAM с одним тактом ожидания ничему не противоречит, и может быть реализована даже на CPLD... впрочем, стоимость CPLD с таким числом выводов будет явно завышенной.

Ничему не противоречит, но и ни зачем не нужна. DDR-то к ней не прикрутишь...увы...

[dryadae 0]

Улыбнуло Для полноэкранной трансформации (каковой является применяемый у меня вэйвлет) не нужно делать оценку движения. Она нужна только в блочных алгоритмах, где размер исследуемой области очень мал и нужно найти корелляцию между этими областями. У меня же трансформация ведётся по всему видео массиву, а не по отдельным его кусочкам типа DCT 8х8.

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

 

Сжимаются два смежных полукадра 704х288 независимо, и как следствие - нет никакого интерлейсинга (если конечно правильно обратно выводить на экран)

Про высокую верт. частоту не понял юмора что то... Зачем с ней бороться-то?

Речь шла о пространственной частоте, актуальной для DCT. Но коль скоро нет, то - нет.

Смысл вопроса заключался в том, что каждое полуполе выглядет по горизонтали нормальным, а по вертикали - сжатым в два раза; следовательно, к вертикальной частоте алгоритм должен быть более критичным, чем к горизонтальной. Отсюда - Intra и inter-блоки, и zigzag-ордеринг. Просто было интересно, как это вещи решаются в вейвлетах.

 

Более чем реально, но... PAL - это 25 fps

;) Упс, действительно. Но HTDV - это уже 30 fps при бОльшем кадре; а хотелось бы в целом знать весь потенциал технологии.

 

В нашем проекте 9 процессоров, 32 PAL камеры и прочее, и если сложить весь трафик.....уухх

А, секьюрити... Тогда понятно, почему вопросы траффика и мобильного питания не актуальны.

 

Ничему не противоречит, но и ни зачем не нужна. DDR-то к ней не прикрутишь...увы...

Почему же? Можно ведь накапливать данные с фронта и среза в 32-битном регистре... а затем - выдавать на шину. То же самое и при записи, задержка - один цикл. Пожалуй, единсвтенная реальная несовместимость - дифф. клоки, но ведь буфер-то всё стерпит, разве не так? 8)

[Stanislav 0]

Stanislav

Разумеется кодек полностью нестандартный, но и не "open source".

Я имел в виду только исполняемый файл декодера для PC (если, конечно, такой существует).

А по поводу картинок, то соотношение размер/качество примерно эквивалентно тому что получается при JPEG сжатии благодаря тому, что у меня нет возможности на сложное статистическое оценивание материала в реальном времени, в отличие от JPEG кодеков на PC со значительно более толстыми процессорами. Но благодаря более прогрессивной трансформации и энтропийному сжатию (против Хаффмана у JPEG) ситуация выправляется. Разве что характер искажений при сильном квантовании у нас разный. JPEG рассыпается "квадратиками" (DCT), а у меня появляется "акварельность", более сильная размытость картинки (fullscreen wavelet). Психовизуально - второй вариант лучше.

Это всё понятно. Только вот на энтропийное кодирование тоже значительная (скорее всего, бОльшая) часть ресурса расходуется...

[Stanislav 0]

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

Дожив до моих, может, и Вы поумнеете.

Настолько!? Благодарю, увольте :tongue:

Нет, до минимально приемлемого уровня.

 

Вы хотели получить выходной поток в 170 кбит/с, да ещё без B-фреймов, да ещё для картинки, снимаемой в движении. Интересно, какой размер кадра при этом Вас бы устроил?

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

(dryadae @ Jun 4 2006, 23:03)

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

Что именно из перечисленного на Ваш взгляд является глупостью? Насчёт более холодных BF - это мне говорили, в том числе, и Вы. Если про лотерею с тепловыделением -то, коли не верите сами, можете посмотреть на соответствующих форумах.

Для того, чтобы не верить в вышеозвученную ерунду, вовсе не обязательно читать форумы - я больше доверяю амперметру. Вам же рекомендую воспользоваться тактильными методами оценки энергопотребления BF-ов. Если боитесь обжечься, советую предварительно послюнявить палец. :)

 

...Да, кстати, поток я указывала не 170 Кбит/сек, а от 170 и до 882.

Игде? :blink:

Вот, почитайте свою тему. Рекомендую сделать это внимательно...

[alexdsp 0]

Значит, вейвлет полнокадравоый... ладно

Да, я нашёл способ делать полноэкранный вейвлет (любых порядков) БЫСТРО и не упираться в трафик памяти (в разумных пределах конечно), поэтому могу себе позволить отказаться от блочных алгоритмов вообще.

Речь шла о пространственной частоте, актуальной для DCT. Но коль скоро нет, то - нет.

Смысл вопроса заключался в том, что каждое полуполе выглядет по горизонтали нормальным, а по вертикали - сжатым в два раза; следовательно, к вертикальной частоте алгоритм должен быть более критичным, чем к горизонтальной. Отсюда - Intra и inter-блоки, и zigzag-ордеринг. Просто было интересно, как это вещи решаются в вейвлетах.

Несимметрия по вертикали и горизонтали решается очень просто. Автоматически. Просто правильно строится дерево Молла и всё. В результате, после первой итерации пространственные частоты выравниваются. Видимо, поэтому это я как проблему и не воспринял.

Единственное для чего нужен зигзаг, так это для адекватной работы RLE. И ВСЁ!

Энтропийному кодеру RLE не нужен, и более того в предельном случае, последовательность обхода вообще не важна.

а хотелось бы в целом знать весь потенциал технологии

Весь потенциал технологии раскрывается в процессоре BF561, у него и шина 32 бита, и два ядра на 600 Мгц.... красотааа! :)

А, секьюрити... Тогда понятно, почему вопросы траффика и мобильного питания не актуальны.

На самом деле они актуальны. Но также актуально сделать РЕАЛЬНУЮ ВЕШЬ которая превосходит конкурентов по многим показателям. По энергопотреблению мы уже сейчас ДАЛЕКО обходим продукцию конкурентов, здесь блэкфин очень хорош. Трафик уменьшить тоже можно, но НЕЛЬЗЯ урезать функционал и качество в угоду этому трафику. Везде есть разумный компромисс.

Почему же? Можно ведь накапливать данные с фронта и среза в 32-битном регистре... а затем - выдавать на шину. То же самое и при записи, задержка - один цикл. Пожалуй, единсвтенная реальная несовместимость - дифф. клоки, но ведь буфер-то всё стерпит, разве не так? 8)

Это всё правильно, но BF просто НЕ МОЖЕТ породить больше данных на шине, также как и принять их, какая бы быстрая DDR ни была. Моё мнение здесь однозначно, при правильном программировании встроенного контроллера SDRAM, результат будет выше чем с внешними примочками. У BF хорошая шинная архитектура, позволяющая довольно свободно манипулировать внешним трафиком, обеспечивая максимальную утилизацию шин, и эту ситуацию можно только ухудшить.

[alexdsp 0]

Я имел в виду только исполняемый файл декодера для PC (если, конечно, такой существует).

Это всё понятно. Только вот на энтропийное кодирование тоже значительная (скорее всего, бОльшая) часть ресурса расходуется...

Декодер, разумеется существует, но по тем же причинам выложить я его не могу. Хотя, могу сразу оговориться, что в рамках общей радужной картины с моим кодеком, декодирование - самая ресурсоёмкая часть. К сожалению, разжатие примерно втрое медленнее чем сжатие благодаря специфике арифметического кодирования. Но так как разжатие преимущественно осуществляется на PC, то высокая тактовая частота PC-шных процессоров делает своё дело исправно. И там и тут реалтайм достигается.

 

Именно. БОльшая часть. Даже при сжатии. При разжатии просто значительно бОльшая часть.

БОльшая не только по вычислительному ресурсу, но и по сложности вычислений. Существенно сложнее чем все эти вэйвлеты, пускай даже самые хитрые.