[dryadae 0]

Декодер, разумеется существует, но по тем же причинам выложить я его не могу.

А если, предположим, сконвертировать Ваш декодированный поток в uncompressed AVI, и выложить, скажем, фрагмент буквально в 2-3 секунды, не больше, просто для оценки качества?

 

Это всё правильно, но BF просто НЕ МОЖЕТ породить больше данных на шине, также как и принять их, какая бы быстрая DDR ни была.

Да нет, тут вопрос уже не в скорости, а в проводниках "до шинного арбитра".

 

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

И каковы же результаты? Сколько Мб/сек даёт непрерывное чтение и запись (SIMD-like) при работе с памятью?

 

Вижу, Вы немало с этим помучились. Тогда хотелось бы выяснить следующий вопрос - если у Вас в проекте 9 процессеоров, то каждый из них них имеет независимую шину, или же для арбитража применяются сигналы BR/BG/BGH? Просто интересно, может ли в отношении памяти BF быть не шинным арбитром, а подчинённым устройством, скажем, к тому же FPGA? В руководстве об этом написано на редкость невнятно; там вообще этой теме уделено буквально два-три абзаца.

[des00 25]

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

 

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

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

 

Хмм а не могли бы вы озвучить алгоритм категорию используемого вами алгоритма ?

Я правильно понимаю что вы использовали бинарный арифметический MQ (без деления) кодер ? А вы использовали контекстную адаптацию ? если да то контексты сами расчитывали ?

 

А вы расматривали реализацию MJPEG ? сравнивали с вашей системой ?

 

Или у вас одним из критериев выбора было отсутствие лицензионных отчислений ? :)

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

 

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

 

А можно табличку (хотя бы с точностью %20) Разрещение - пропускная способность памяти.

 

Заранее спасибо :)

 

 

 

Вижу, Вы немало с этим помучились. Тогда хотелось бы выяснить следующий вопрос - если у Вас в проекте 9 процессеоров, то каждый из них них имеет независимую шину, или же для арбитража применяются сигналы BR/BG/BGH? Просто интересно, может ли в отношении памяти BF быть не шинным арбитром, а подчинённым устройством, скажем, к тому же FPGA? В руководстве об этом написано на редкость невнятно; там вообще этой теме уделено буквально два-три абзаца.

 

По вопросам построения подобной системы у нас шас заложено 4 642 TI с локальным сдрамом,

+ спартан с ддр мозгами, на спартане будет 5- ти канальный контроллер памяти + система синхронизации дспешников, т.е. подобие системы с cross-bar свичем.

т.е. не дсп рулят, а фпга.

 

Насчет вашей же идеи про фпга и ддр, думаю что все же лучше оставить блекфину сдрам, т.к. у ддр памяти есть еще и латентность доступа, поэтому по хорошему остается вариант только асинхронного обмена (что правильно заметили идет на более медленном клоке), но помимо этого думаю что еще контроллер интерфейса содержит в себе задержки на пару тактов (у 642 го так), что даст еще больший проигрыш по пропускной способности памяти (кеш в фпга немного решает эту проблему, но только при потоковом чтении), при рандомном труба.

 

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

вам 1 го банка за глаза.

[alexdsp 0]

Хмм а не могли бы вы озвучить алгоритм категорию используемого вами алгоритма ?

Я правильно понимаю что вы использовали бинарный арифметический MQ (без деления) кодер ? А вы использовали контекстную адаптацию ? если да то контексты сами расчитывали ?

 

А вы расматривали реализацию MJPEG ? сравнивали с вашей системой ?

 

Или у вас одним из критериев выбора было отсутствие лицензионных отчислений ? :)

 

Арифметический кодек - не бинарный MQ :) Наиболее близким аналогом является range-coder , но только внешне. Кодер полностью сделан и оптимизирован для процессоров BF.

Да, кодер адаптивный. Контексты расчитывает сам.

Ещё раз повторюсь. Целью было не "победить" JPEG и остальных, а сделать "много" кадров в секунду при прочих адекватных характеристиках. Я прекрасно понимаю, что может быть другие алгоритмы в чём то и превосходят мой, но по скорости на семействе блэкфинов они и рядом не лежат с моим. Вот и всё. :)

Да. Полная лицензионная чистота - залог крепкого экономического здоровья :)

 

А можно табличку (хотя бы с точностью %20) Разрещение - пропускная способность памяти.

 

Позже. Надо посчитать. Но если навскидку, то сейчас я далеко не упираюсь в память. При 60 fps на цветном 352х288.

[alexdsp 0]

Арифметика такая.

Сначала полукадры пишутся при помощи DMA в SDRAM. Полукадр занимает 1440*288=414720 байт

Теперь трафик SDRAM самого алгоритма.

Для ч/б компоненты при разрешении 704*288 полный трафик SDRAM алгоритма составляет примерно 550 Кб из которых 405 - это собственно, чтение этого полукадра обратно из SDRAM. Неплохо, правда !? :))

Да... добавлю. Везде, внутри каждого банка SDRAM доступ ведётся ТОЛЬКО по последовательным адресам. Никакого рандома! То есть, будем считать, что про пречарджи и рефреши можно временно забыть :)

Примерно столько же трафика уйдёт на Cb и Cr компоненты.

То есть, цветной полукадр "скушает" 405(PPI DMA) + 550(Y) + 550(Cb,Cr) = примерно 1.5 Мбайт трафика.

При сжатии обоих полукадров цифра удваивается. То есть, сжатие 704х576 в цвете порождает трафик 3 Мбайта.

Что же нам может предложить самый "хилый" из блэкфинов bf531? SDR шину шириной 16 бит и SCLK=133МГц => 266 Мбайт/сек что в конечном итоге даёт 266/3 = 88 fps

Ну, в реальности, всё таки будут потери на переходы и смены банка, пречарджи и рефреши и пр.

Думаю, что тут мой предел по трафику при PAL video 704х576 будет где-то в пределах 50 fps, а мне всего-то нужны какие-то 25 :)

В общем, в железе так оно и есть. Я утилизирую меньше половины пропускной способности шины и полностью упираюсь в ядро процессора.

[des00 25]

Арифметика такая.

Сначала полукадры пишутся при помощи DMA в SDRAM. Полукадр занимает 1440*288=414720 байт

Теперь трафик SDRAM самого алгоритма.

Для ч/б компоненты при разрешении 704*288 полный трафик SDRAM алгоритма составляет примерно 550 Кб из которых 405 - это собственно, чтение этого полукадра обратно из SDRAM. Неплохо, правда !? :))

Да... добавлю. Везде, внутри каждого банка SDRAM доступ ведётся ТОЛЬКО по последовательным адресам. Никакого рандома! То есть, будем считать, что про пречарджи и рефреши можно временно забыть :)

Примерно столько же трафика уйдёт на Cb и Cr компоненты.

То есть, цветной полукадр "скушает" 405(PPI DMA) + 550(Y) + 550(Cb,Cr) = примерно 1.5 Мбайт трафика.

При сжатии обоих полукадров цифра удваивается. То есть, сжатие 704х576 в цвете порождает трафик 3 Мбайта.

Что же нам может предложить самый "хилый" из блэкфинов bf531? SDR шину шириной 16 бит и SCLK=133МГц => 266 Мбайт/сек что в конечном итоге даёт 266/3 = 88 fps

Ну, в реальности, всё таки будут потери на переходы и смены банка, пречарджи и рефреши и пр.

Думаю, что тут мой предел по трафику при PAL video 704х576 будет где-то в пределах 50 fps, а мне всего-то нужны какие-то 25 :)

В общем, в железе так оно и есть. Я утилизирую меньше половины пропускной способности шины и полностью упираюсь в ядро процессора.

 

понятно, спасибо я так и думал,

больше всего памяти как раз multi reference ME и жрет, но если искать best mathc то подобное решение (с однократной загрузкой кадра) есть и для МЕ :)

[alexdsp 0]

понятно, спасибо я так и думал,

больше всего памяти как раз multi reference ME и жрет, но если искать best mathc то подобное решение (с однократной загрузкой кадра) есть и для МЕ :)

На ассемблере для blackfin? В режиме сжатия дающее 25 fps (хотя бы CIF)?

[dryadae 0]

понятно, спасибо я так и думал,

больше всего памяти как раз multi reference ME и жрет, но если искать best mathc то подобное решение (с однократной загрузкой кадра) есть и для МЕ

Но у Блакфина - весьма ограниченная степень параллелизма (максимум два ME одновременно у BF561). FPGA, на первый взгляд, именно этим и подкупают, однако тут вступает в дело память...

[alexdsp 0]

Но у Блакфина - весьма ограниченная степень параллелизма (максимум два ME одновременно у BF561). FPGA, на первый взгляд, именно этим и подкупают, однако тут вступает в дело память...

Зато результат достигается быстро и недорого в сравнении с FPGA. Опять же, где есть такие FPGA стоимостью $25, которые делают 4 одновременно 16х16=>32 MAC-а на частоте 600МГц ?

А ведь блэкфин - это самое что ни есть бюджетное решение. А ведь есть ещё Tigersharc, есть продукты от TI типа DM642 и проч...(по TI я не спец.), и в этом случае изделие на FPGA совсем делается неконкурентным (может быть, разве что в военном применении, где цена вообще значения не имеет). Ну... ещё вариант, если вы решили печь ASIC. Тогда такое стремление можно оправдать.

Ещё раз зацитирую...

Но у Блакфина - весьма ограниченная степень параллелизма (максимум два ME одновременно у BF561).

Это с чего вы так решили? Ну... тогда следуя аналогии получится, что bf53х - только одну!? :)

Посмотрите в сторону инструкции процессора SAA. Эта инструкция за один такт обрабатывает 8 пикселей. В двух ядрах - их соответственно будет 16.

И вообще, нахрена козе баян, а сжатию - МЕ?

Даёшь полноэкранные трансформации! Нет блочным алгоритмам! Урррааа! :)

В общем... делать сжатие на FPGA вы меня не уговорили ;)

[dryadae 0]

Зато результат достигается быстро и недорого в сравнении с FPGA. Опять же, где есть такие FPGA стоимостью $25, которые делают 4 одновременно 16х16=>32 MAC-а на частоте 600МГц ?

У S3E двадцать встроенных умножителей 18x18=36 бит, способных работать на частоте в 300 Мгц. Всё - за 30 баксов, не считая тех АЛУ, которые создаются на генераторах функций...А это - достаточно много. Плюс - возможность конвейеризировать всё это без лишних задержек. Так, по крайней мере, я это себе вижу.

 

А ведь блэкфин - это самое что ни есть бюджетное решение. А ведь есть ещё Tigersharc, есть продукты от TI типа DM642 и проч...

Дорого.

 

и в этом случае изделие на FPGA совсем делается неконкурентным (может быть, разве что в военном применении,

где цена вообще значения не имеет).

А для перспективы HDTV?

 

Ну... ещё вариант, если вы решили печь ASIC. Тогда такое стремление можно оправдать.

Ну это вряд ли. Иначе бы просто не было этой ветки.

 

Это с чего вы так решили? Ну... тогда следуя аналогии получится, что bf53х - только одну!?

Посмотрите в сторону инструкции процессора SAA. Эта инструкция за один такт обрабатывает 8 пикселей. В двух ядрах - их соответственно будет 16.

А в 40-а блоках - несколько сотен.

 

И вообще, нахрена козе баян, а сжатию - МЕ?

Даёшь полноэкранные трансформации! Нет блочным алгоритмам! Урррааа!

В общем... делать сжатие на FPGA вы меня не уговорили

Да нет, это я себя скорее уговариваю. На разработку внешнего кэш-контроллера с DDR-интерфейсом :)

[des00 25]

На ассемблере для blackfin? В режиме сжатия дающее 25 fps (хотя бы CIF)?

 

Моя область это кодеки на фпга :), за сим на блек фине не проверял.

 

2 dryadae

Но у Блакфина - весьма ограниченная степень параллелизма (максимум два ME одновременно у BF561). FPGA, на первый взгляд, именно этим и подкупают, однако тут вступает в дело память...

 

Вот как раз тут память не вступает, а вступают аппаратные ресурсы. Т.е. МЕ это палка о двух концах

либо мы мало "качаем" кадр из внешней памяти и имеем очень широкий вычислитель для броадкастовских схем МЕ/средний вычислитель + кеш для циклических схем.

 

В случае с процом и так понятно что кадр закачиваеться 1 раз, а вычислений требуется уйма, ИМХО по этому alexdsp вы упираетесь не в память а в проц.

 

Либо подкачиваем инфу постоянно, вполне возможно с перекрытием по данным: плюсы такого решения не нужно городить кеш контроллер + более простой вычислитель, минусы: повышеная пропуская способность памяти (в среднем кадр выкачиваеться раз в 5-8 больше), на если правильно разложить кадр по памяти и написать свой умный контроллер памяти, то получиться неплохо ( ест-но разговор про фпга).

 

Но опять же как только мы возжелаем искать не best match, а учитывать rate distortion тут потребуется квази рандомный доступ, что еще накидывает требования на память, но это разговор надолго......

 

 

 

 

 

Даёшь полноэкранные трансформации! Нет блочным алгоритмам! Урррааа! :)

 

Хмм вот тут вы сильно ошибаетесь, есть стандарты, у стандартов есть имя.

Если есть 2 железки на одной вы указываете кодек © солянка сборная моя, на второй © mpeg4.10

(avc) support, то как вы думаете какое решение вы продадите быстрее ?

 

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

 

Насчет блочных алгоримов, тут тоже предмет отдельного спора, на сколько я знаю mjpeg2000 в рейлтайме на D1/720HD/1080HD даже на 1 голове x86 платформы не делаеться.... (впрочем как и avc HD)

 

А ведь блэкфин - это самое что ни есть бюджетное решение. А ведь есть ещё Tigersharc, есть продукты от TI типа DM642 и проч...(по TI я не спец.), и в этом случае изделие на FPGA совсем делается неконкурентным (может быть, разве что в военном применении, где цена вообще значения не имеет)

......

В общем... делать сжатие на FPGA вы меня не уговорили ;)

 

TI DaVinci D1 avc main profile не может вытянуть в реалтайме, а это самая мощная платформа.....

[dxp 32]

Зато результат достигается быстро и недорого в сравнении с FPGA. Опять же, где есть такие FPGA стоимостью $25, которые делают 4 одновременно 16х16=>32 MAC-а на частоте 600МГц ?

У S3E двадцать встроенных умножителей 18x18=36 бит, способных работать на частоте в 300 Мгц. Всё - за 30 баксов, не считая тех АЛУ, которые создаются на генераторах функций...А это - достаточно много. Плюс - возможность конвейеризировать всё это без лишних задержек. Так, по крайней мере, я это себе вижу.

И что, весь кодек - весь проект сможет работать на 300 МГц? Что-то сомнительно. Но дело не в этом. То, что если просто гнаться за скоростью, любая задача, которую можно распараллелить, на FPGA выйдет шустрее, это очевидно. Только вот это не единственный фактор. Трудоемкость разработки алгоритма в виде программы пусть даже на ассемблере на порядок и более ниже, чем в виде железа, которое надо спроектировать, отмоделировать, синтезировать, добившись нужных времянок. Согласитесь, цена вопроса существенная. Поэтому, если задачу можно реализовать на процессоре - ее надо на нем и реализовывать. А вот если нельзя, то на нет и суда нет. :)

[dryadae 0]

Но опять же как только мы возжелаем искать не best match, а учитывать rate distortion тут потребуется квази рандомный доступ, что еще накидывает требования на память, но это разговор надолго.

А с best match обращений получится ещё больше... Как раз рандомность-то с отсутствием burst reads и неплохо уживается - если память "широкая". Впрочем, в варианте с подвижной камерой ME понадобится намного хитрее...

 

И что, весь кодек - весь проект сможет работать на 300 МГц? Что-то сомнительно.

Пока - да. В референсном дизайне от Xilinx скорость DCT составляет 140 Мгц (S3E), RLE - 100, а Хаффмана вообще 70 (что, впрочем, неудивительно) Но там такая муть, что сам чёрт ногу сломит; и потом референс - это всего один блок, кодируемый на всём чипе (используется 10 embedded-умножителей). Наверняка же можно сделать лучше.

 

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

Не за скоростью, за latency. Ну и за масштабируемостью решения - тоже. Как "поженить" между собой два Блакфина, мне пока плохо представляется.

 

Трудоемкость разработки алгоритма в виде программы пусть даже на ассемблере на порядок и более ниже, чем в виде железа, которое надо спроектировать, отмоделировать, синтезировать, добившись нужных времянок. Согласитесь, цена вопроса существенная.

Это да. Ещё и кривой dev. kit, на которого много чего не сделаешь... у Blackfin'ов он, впрочем, стоит вообще запредельно - для 561-го в Москве обойдётся в 800+ $.

 

Поэтому, если задачу можно реализовать на процессоре - ее надо на нем и реализовывать. А вот если нельзя, то на нет и суда нет.

Ну это да. Хотя почему-то кажется, что Blackfin с MPEG так или иначе в итоге упрётся в память, с которой ничего не сделаешь... а у FPGA всегда можно синтезировать более широкий контроллер - 16 DDR... 32... 64... Что, правда, тоже выйдёт недёшево.

[alexdsp 0]

Хмм вот тут вы сильно ошибаетесь, есть стандарты, у стандартов есть имя.

Если есть 2 железки на одной вы указываете кодек © солянка сборная моя, на второй © mpeg4.10

(avc) support, то как вы думаете какое решение вы продадите быстрее ?

 

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

Тут я вас прекрасно понимаю. Но мы то как раз разрабатываем законченное изделие, а не технологию. Продаваться будет изделие, поэтому мы вправе навязать своё решение потребителю, благо оно не уступает продукции конкурентов. И блэкфин был выбран как раз из-за суммарной дешевизны платформы. Конкуренты, в принципе не могут сжимать 704x576 - 25 fps в многоканальном режиме. У них применяются аппаратные кодеки, рассчитанные на ограниченное количество каналов (1-4), и весьма ограниченный fps и (видимо) плохо поддающиеся масштабированию. Я (скоро) смогу. То есть 20 fps уже есть. Была ревизия алгоритма - будут и 25 fps.

dryadae

У S3E двадцать встроенных умножителей 18x18=36 бит, способных работать на частоте в 300 Мгц. Всё - за 30 баксов, не считая тех АЛУ, которые создаются на генераторах функций...А это - достаточно много. Плюс - возможность конвейеризировать всё это без лишних задержек. Так, по крайней мере, я это себе вижу.

Специфика таких дизайнов в FPGA в том, что эти ваши умножители будут очень жёстко привязаны к своей функции внутри блока и будут быстро расходоваться на каждое мало-мальски необходимое умножение, или вы полностью утонете в мультиплексорах и связанных с ними регистрах конвейеров. Плюс ОЧЕНЬ высокая сложность такой реализации. Есть немало проектов видео-сжатия в FPGA , бодро начавшихся несколько лет назад и продолжающихся до сих пор в стадии пре-альфа. И пока вы будете смаковать потенциальную, гипотетическую возможность разработки HDTV кодека на S3E или Stratix-е - корейцы при помощи китайцев испекут ASIC на 90 нанометрах. И куда вы потом денете ваш дизайн, да ещё жестко привязанный к вашим 20 умножителям и архитектуре Spartan? Уж не говоря о том сколько времени вы будете его делать. Понятное дело, такое же можно сказать и обо мне. Мол тоже, к блэкфину привязался - неотвяжешься. Да, именно так, но есть и отличие: 1) всё уже сделано и отлично видны перспективы развития моего кодека. Перспективы хорошие. Частоты процессоров растут, а потребление падает. Потом. Сжатие я сделал в одиночку за полгода. Такой же проект на FPGA я даже не знаю, не возьмусь оценить сколько времени у меня уйдёт, несмотря на мой очень немаленький опыт программирования FPGA. (Правда, я использую Альтеру) Я даже не смогу гарантировать конечный результат, который бы был коммерческим. Возможно, (такое нынче встречается) у вас очень сильная команда FPGA дизайнеров, каждый из которых по совместительству хороший математик, и вы справитесь. Возможно. Всякое бывает. На нашей фирме (меня ещё тут не было) тоже был хороший FPGA дизайнер, и он не справился. А начиналось всё очень радужно. Оценки были как у вас. Звучали слова "умножители", "мегагерцы" и прочая патетика, но проект не поместился в нужную микросхему. Никак. А микросхема бОльшего размера не помещалась в бюджет разрабатываемого девайса. Тоже никак. Ну... можно было (что и было предложено) подождать новой серии спартанов. Начальство эту новость восприняло без энтузиазма. А делался всего-навсего обыкновенный JPEG.

Самое разумное для вас - это поискать аналогичные решения в предложениях конкурентов, чтобы не оказаться в такой же ситуации. Чтоб было понятно - а реализуемо это в принципе или нет? Когда я начинал выбор платформы, я перелопатил много информации в интернете об аналогичных продуктах: в основном - библиотеки, где обычно сказано какие параметры достигаются, какой fps при каком разрешении, на какой тактовой и прочее... Это мне сильно помогло. Хотя, я тоже сильно рисковал, так как исходил из предположения, что всё равно смогу сделать немного лучше. :)

Пока - да. В референсном дизайне от Xilinx скорость DCT составляет 140 Мгц (S3E), RLE - 100, а Хаффмана вообще 70

Вот вы сами как себя ощущаете когда произносите подряд три слова: DCT, RLE, Huffman? :)

Технологии - то ведь отсталые, отсталее некуда. Да и Хаффман-то небось статитечский... И никакие примочки их уже не спасут IMHO.

[des00 25]

А с best match обращений получится ещё больше... Как раз рандомность-то с отсутствием burst reads и неплохо уживается - если память "широкая". Впрочем, в варианте с подвижной камерой ME понадобится намного хитрее...

 

Ну ну, смотрю на одну из наших реализаций и не вижу еще больше обращений. и src и ref кадр выкачиваються из памяти ровно 1 раз, а вот в случае рдо и квази-рандомного доступа вам 1 нужно проверить предсказаные точки начала поиска, а потом найдя лучшую сделать от нее поиск.

на сифе достаточно ограничить search range окном 32*32 пикселя от координаты макроблока, больше делать не имеет смысла, как показывает практика.

 

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

а еще вам не помешает оценивать скипы моду макроблоков, это вообще самая рульная мода, в битстрим ложиться 1 бит.

 

Вот вы сами как себя ощущаете когда произносите подряд три слова: DCT, RLE, Huffman? smile.gif

Технологии - то ведь отсталые, отсталее некуда. Да и Хаффман-то небось статитечский... И никакие примочки их уже не спасут IMHO.

 

DCT это собирательное название алгоримта, во всех ревизиях стандарта mpeg оно разное, мне больше нравиться avc дкт :)

RLE основа на которой живут baseline энкодеры, в avc трансформировалось в CAVLC.

Да и Хаффман не плохо поживает в Theora.

 

Но вот хилая реализация DCT такое гавно!!!, ощущение что сделано индусом наспех, лиш бы отвезались.

[alexdsp 0]

DCT это собирательное название алгоримта, во всех ревизиях стандарта mpeg оно разное, мне больше нравиться avc дкт :)

RLE основа на которой живут baseline энкодеры, в avc трансформировалось в CAVLC.

Да и Хаффман не плохо поживает в Theora.

 

Но вот хилая реализация DCT такое гавно!!!, ощущение что сделано индусом наспех, лиш бы отвезались.

 

Посмотрел бегло AVC. Впечатление такое, что разработчикам стандарта очень хочется перейти на DWT, но вот начальство не позволяет :))

Этот метод похож на блочный DWT 16х16, но только почему-то там опять DCT :). DWT же ЛУЧШЕ! Правда, только в случае неиспользования RLE. Там всякие "зигзаги" не прокатят. Видимо поэтому этот вариант и не прошёл.

Прежде чем перейти на DWT схемы, я сделал кодек типа JPEG для BF на DCT. Потом "тупо" заменил DCT 8x8 на блочный вэйвлет Хаара 8х8. Так, ради смеха. И о чудо! При равном битовом потоке, визуально картинка стала лучше, не так сильно "рассыпается" на "квадратики". Точнее, эти квадратики имеют не такую ярко выраженную блочность, так как они не все размера 8х8, а встречаются 4х4, 2х2. Из таких кирпичиков изображение и "мостится". Это при сильном квантовании. А при слабом - лослесс он и есть лослесс на вид :) Весь прикол в том, что при вычислении вэйвлета Хаара не происходит ни одного умножения, только сложения и вычитания. Беда только в том, что тут оказывается малоэффективен RLE, другие свойства у преобразования.

Потом я стал экспериментировать с другими вэйвлетами, более устойчивыми к ошибкам квантования, а потом уже придумал полноэкранную схему с низким трафиком. Так вот, на мой взгляд, при прочих равных условиях, у DCT нет ни малейшего шанса составить конкуренцию DWT. При прочих равных. Другое дело, DWT нужно брать конечно же не Хаара, а что-нибудь из высоких порядков Добеши или аналогичных биортогональных. Другое дело, на PC их считать довольно трудно и по времени вычисления они проигрывают схемам с DCT. Может поэтому их и избегают, а может ещё по каким причинам сложно поддающимся анализу... На DSP картина выравнивается. Быстрое DWT намного более регулярный алгоритм, чем быстрое DCT. Для быстрого вычисления DCT существует много разных схем - одна "корявее" другой. По крайней мере, на BF я просто запарился с этой несимметрией. Для вычисления DWT применяется (в реальных устройствах) в основном две схемы - лифтинговая и дерево Молла. В общем - дело вкуса. У каждой из них есть свои преимущества. У лифтинговой - меньше умножений, но некоторая кривизна присутствует. Дерево Молла - для современных DSP очень гармоничная и гибкая схема (IMHO).

Я просто хочу ещё раз сказать, что я имел возможность сравнить обе технологии (DCT vs DWT) при равных условиях. И результат сравнения был сильно не в пользу DCT.

 

Единственный аргумент "против" - это то о чём вы уже упоминали: "нестандартность". Против этого уже не попрёшь, конечно...