Отправлено Kota 26 сентября 2003 г. 10:15

На какой DSP ориентироваться в задачах сжатия и распаковки видео в реальном времени? Разумеется DSP желателен подешевле. Сам пока метаюсь между с55х и BF53x. Примеры есть и там и там. Что посоветует уважаемое собрание? Может есть отладочные платы для этого дела. С алгоритмами тоже не понятно куда грести Weiwlet-Jpeg-Mpeg. Может еще что-нить еще есть? Математик вообще говорит, что поднимем все. Совместимость, четкое следование стандарту не грузит. Одна железка пакует - другая распаковывает. Хотелось бы получить радмер сжатого кадра на уровне 30..50 КБт.

• Задача есть, но он ее не понял!!! Перескажи нам тупым - может чего путное сможем предложить. — Пятничный хрен   (26.09.2003 18:53, пустое)
• Вопрос: какова цель (что на выходе устройства - системы безопастности, компьютер, vhs, svhs)? — Lucky   (26.09.2003 16:37, пустое)
  • Все что угодно, частота обновления кадров желательна не ниже 12 Гц — Kota   (26.09.2003 17:43, пустое)
    • Размер кадра 720*576 это и хотелось бы ужать до 30..50 килобайт — Kota   (26.09.2003 17:44, пустое)
      • SDTV -> H264(2Mbit)->SDTV. По сути не отличишь от оригинала. Так че надобно золотой рыбке? — Пятничный хрен   (26.09.2003 18:05, пустое)
        • Что заложить в качестве ядра проекта? — Kota   (29.09.2003 11:18, 56 байт)
• вообще интересно, что практически лучше - самому на ПЛИС делать или готовый чипсет брать (сомневаюсь в способностях DSP) — yes   (26.09.2003 15:07, пустое)
  • Для MPEG2 однозначно чипы. У MPEG4 куча разновидностей. Что то и готовое есть. Но для H264 SDTV и HDTV на FPGA очень дорого. Для SDTV как ни крутись пара 64x 600 + 6713 для звука и куча обвязки. Для кодера лучше Intrinsity F14M902A2000CAA ничего не придумать. Стоит немеряно правда, но зато в среде нормальной ос можно отлаживаться. — Пятничный хрен   (26.09.2003 15:28, пустое)
• Зависит от разрешения и качества картинки. DM64x специально для этого сделан. Видеопорты классные.Только дохловат для больших картинок. — Пятничный хрен   (26.09.2003 11:53, пустое)
  • И еще - в 5510 и 5509 есть сопроцессор видео-сжатия. (DCT, pixel interpolation, motion estimation). — SМ   (26.09.2003 13:24, пустое)
    • SM. Не порти воздух. Это для картинок на экране мобилы. Когда и прыщ от бородавки не отличить в статике. А если морда чуть губами шевелит, так они на части распадаются. — Пятничный хрен   (26.09.2003 14:04, пустое)
      • Он ничего не сказал про частоту кадров. Она может быть и раз в секунду. — SМ   (26.09.2003 14:23, пустое)
        • Он сказал про сжатие видео в реальном времени!. Я че то нигде не видел видео меньше 25 кадров. Это на компе можешь хоть раз в час или в сутки обновлять картинку на экране, когда уже все в памяти сидит. — Пятничный хрен   (26.09.2003 14:53, пустое)
          • Например для охранных систем реальное время бывает совсем не такое. — SМ   (26.09.2003 15:03, пустое)
            • В кино 24 кадра в секунду. Физиология уже ниже не позволяет смотреть.... Без ухищрений. — Пятничный хрен   (26.09.2003 15:51, пустое)
              • 2-4 кадра в сеунду (сист. безопастности) - тоже реальное время. — Lucky   (26.09.2003 16:23, пустое)
                • Именно. Так как более высокая частота во первых не нужна (хрен проскочишь мимо камеры так быстро), а во вторых места меньше при записи надо. — SМ   (26.09.2003 16:30, пустое)
              • "Броненосец Потемкин" снимали с частотой 16 кадров в секунду :))) — st256   (26.09.2003 16:09, пустое)
                • Блин! Один кадр в час можно и без сжатия передать в цифре по совершенно хламовной линии. — Пятничный хрен   (26.09.2003 16:29, пустое)
                  • Я только блеснул эрудицией :) — st256   (26.09.2003 16:32, пустое)
• В jpeg вполне реально, а ресурсов гораздо меньше нужно, чем в mpeg — Отделение 13   (26.09.2003 10:56, пустое)
  • Да еще. В mjpeg не нужно для каждого кадра передавать таблицу Хаффмана. Она общая для всех кадров. Это тоже уменьшает объем. — Отделение 13   (26.09.2003 11:04, пустое)
    • И еще :). Для сжатия в jpeg в памяти достаточно держать только 16 текущих строк, а не весь кадр. — Отделение 13   (26.09.2003 11:37, пустое)
      • Тут же про реальное видео вопрос задали. Какие там jpegи. И поток в несколько раз выше и картинка дерьмо. Тут по качество/поток лучше H264 ничего не придумаешь. Ресурсов жрет до хрена правда. — Пятничный хрен   (26.09.2003 11:59, пустое)
        • но есть граница JPEG где на газ не видно разницы. — Lucky   (26.09.2003 16:33, пустое)
          • опечатка - "на глаз" — Lucky   (26.09.2003 16:38, пустое)
      • Меня всегда учили, что в MPEG работают с изменениями к базовому кадру. Своеобразная дельта-модуляция. Неужели если жать все кадры JPEG, то можно что-то выиграть? Или жать как-то разницу между кадрами этим JPEG-ом? — st256   (26.09.2003 11:54, пустое)
        • Нет, конечно. jpeg у mpeg никогда не выиграет. Однако 50кБ на кадр получить от jpeg гораздо проще. Учитывая, что ключевые кадры в mpeg все равно сжимаются jpeg-ом. — Отделение 13   (26.09.2003 12:03, пустое)
          • Ну не надо туфту то гнать! Это может на заре цивилизации так делали. 50 кило на кадр это ж больше 1 мегабита поток небось при QCIF разрешении. H264 дает 50Кбит поток при QCIF. А на потоках 1-2 Мбита уже SDTV качество. — Пятничный хрен   (26.09.2003 12:19, пустое)
            • Ну слава Богу! А то я решил, что со мной плохо... — st256   (26.09.2003 12:45, пустое)
              • C тобой нормально все! Это у них с мозгами плохо. Особенно если 55 и bf собираются для реального видео пользовать. DM642 и то из за маленького кэша здорово тормозит. Для декодера еще туды сюды, а в кодере ни в какие ворота. Уж если особо поток и качество не волнуют, можно MPEG2 кодеры поставить. Cirrus там IBM до жопы уже наделали. Про декодеры так и речи нет. Для сопливой картинки Toshibu MP4 можно прикрутить. — Пятничный хрен   (26.09.2003 13:00, пустое)
                • Собственно, я удивился ни столько неэффективности компрессии, сколько... — st256   (26.09.2003 16:26, 794 байт)
                  • Если интересует стружка - почитай стандарт.(Пока draft на халяву сливается) Эволюцию от одного к другому. Сейчас и 20 пальцев не хватит, чтоб врубиться. Ой чего туфту несу - DivX - это почти H261.... — Пятничный хрен   (26.09.2003 16:44, пустое)
• "Хотелось бы получить радмер сжатого кадра на уровне 30..50 КБт. " - Чаво?! — st256   (26.09.2003 10:23, пустое)