caxapa.ru :: Посоветуйте процессор. Нужно принимать цифровое видео (BT.656 параллельный интерфейс, 8 бит, кадр 700 с копейками на 500 с копейками), укладывать его в RTP пакеты и передавать по гигабитному Ethernet. Кроме RTP в системе должен быть реализован IP

Mebius (07.11.2015 13:47, просмотров: 10350)

Посоветуйте процессор. Нужно принимать цифровое видео (BT.656 параллельный интерфейс, 8 бит, кадр 700 с копейками на 500 с копейками), укладывать его в RTP пакеты и передавать по гигабитному Ethernet. Кроме RTP в системе должен быть реализован IP стек чуть меньше чем полностью. То есть и ICMP и прочее и прочее там должны быть. При этом нужно чтобы система потребляла по минимуму, ибо места под радиаторы и мощные DC-DC похоже что нет. Всё должно быть предельно плоским. Смотрел на Sitara но отпугивает потребление и радиатор. У SmartFusion2 тактовая микроконтроллера 166МГц. Потянет-ли? Можно, наверно, как-то складывать видеопоток ПЛИС-иной а потом заворачивать в IP обёртку, но что-то не найду чтобы кто-то так делал. Нет-ли подводных камней в таком подходе? Пионером быть не хочется.

Ответить

- А, кстати. Что там обычно в спутниковых декодерах стоит? Нельзя ли из старого ненужного сат-бокса себе сотворить отладочную плату для сего дела? - Николай Коровин(16.11.2015 10:34)
- Для сжатия в jpeg использовал SSD1928, который работал в связке с видеодекодером AK8856. Потребляемая мощность всего устройства, записывавшего видеопоток на SD-карту, составила 0,25Вт - Ozelot(08.11.2015 00:44)
- Если это обычное аналоговое видео, то речь будет идти еще и о процедуре деинтерлейса... - Ozelot(07.11.2015 22:49)
  - Сейчас есть декодеры уже со встроенной процедурой деинтерлейса. USSR(68 знак., 08.11.2015 03:30, )
    - К таким относятся еще TW9912 и S2S65P10 - Ozelot(09.11.2015 10:51)
  - Ойдаладно, мджпегать можно и полукадрами по принципу "за что купил, за то и продаю"... метить просто как-то, чёт или нечет. На той стороне пусть думают, в конце концов, никто не мешает вообще работать в полукадрах. - Николай Коровин(07.11.2015 22:56)
    - Этож надо так себя не уважать, чтоб такую фигню предлагать... - Ozelot(08.11.2015 00:19)
      - Не, надо себя не уважать, чтобы на такое предложение согласиться :-D В смысле работать потом с таким потоком %) Шучу, но частично: имел дело. - Николай Коровин(08.11.2015 00:24)
    - если с изображением нужно потом работать то деинтерлейс ДО(!) компрессии обязателен. - 3m(07.11.2015 23:55)
      - Некорректно. Деинтерлейс, если ему судьба вообще быть, будучи проведён до компрессии, увеличивает соотношение "качество/размер" весьма существенно. Вот так будет корректно. А, да, сжимать "полосатые" кадры, тупо составленные из соседних полукадров Николай Коровин(69 знак., 08.11.2015 00:21 - 00:27)
        
        Если ты не сделаешь деинтерлейс до (сильного) сжатия, то не факт, что получится качественно сделать после (из-за артефактов сжатия _с_ _потерями_). - fk0(08.11.2015 00:51)
        
        Сам не встречался с такими тупыми алгоритмами деинтерлейсинга, которые, наткнувшись на артефакт, теряются и начинают плодить артефакты-в-квадрате. Обычно сколько гэ на входе, столько и на выходе. Но не сомневаюсь в их существовании :) - Николай Коровин(08.11.2015 01:04)
        
        Почему? - Ozelot(08.11.2015 00:26)
        
        Да потому, что мы теряем возможность увидеть и безболезненно убрать всю ту избыточность, которая есть в корреляции буквально соседних строк. А в строках "через одну" корреляция уже слабее и сжатие менее эффективно. По второй части -- ну, Николай Коровин(112 знак., 08.11.2015 00:28)
        
        При правильно выполненном деинтерлейсе речи о полосатости идти не должно - Ozelot(08.11.2015 00:36)
        
        Полосатость имеется в виду ДО деинтерлейса, некоторые девайсы так делают -- тупо гонят фуллрез, совмещая полукадры в одном кадре. Такое, конечно, жать нельзя -- надо или деинтерлейсить, или разорвать обратно на полукадры. - Николай Коровин(08.11.2015 00:44)
        
        С этим согласен, почему то многие думают, что перемежение двух полукадров - это и есть деинтерлейс - Ozelot(08.11.2015 00:45)
        
        Кстати, жаль, что никакой нормальный способ хранения интерлейса не прижился... не дурацкое перемежение, а реально удвоенная кадровая, полукадры через один помечены как "vertical offset = +1 pixel". Чересстрочка -- не самое глупое изобретение... - Николай Коровин(08.11.2015 01:33)
        
        +1 - fk0(08.11.2015 02:06)
        
        Зря они так думают :) Самый тупой, как мне кажется -- это в каждом полукадре пропущенные строки дополнить средним арифметическим от соседних и так и пустить, на удвоенной кадровой. Хотя нет, можно ещё тупее: скопировать соседнюю строку в пустую :) - Николай Коровин(08.11.2015 01:23)
        
        Передавать поток сжатых полукадров оптимально только в случае последующего использования алгоритма деинтерлейса с удвоением частоты полных кадров (да и то только, если вы готовы к переоцифровке полукадров) - Ozelot(08.11.2015 00:33)
        
        Во-во. Если мы, например, делаем интерполяционный слоу-мо (как по ссылке), то нам на входе "сырые" полукадры на удвоенной частоте намного ценнее, чем интерполированное деинтерлейсом гладкое пространство. Если, конечно, алгоритм понимает их. - Николай Коровин(08.11.2015 00:53, ссылка)
- Может, поискать TMSкакой-нибудь-там с аппаратным ускорением DCT? В стародавние времена я что-то такое под что-то такое кодил. Готовое цифровое видео было, ч/б, фпс малый, зато кадр очень большой. IP, правда, придётся прилежно портировать. - Николай Коровин(07.11.2015 18:41)
  - Да похоже и из Ситар можно найти. 40 Ватт кушает A15. Борды с A8, A9 выглядят вполне приемлемо. - Mebius(07.11.2015 18:52)
    - Может 0,4\4? - saifullin2(09.11.2015 08:21)
    - Когда-то давно делал сжатие в JPEG и передачу по сети 100BASE-TX на BF527. Кушало меньше ватта. - USSR(07.11.2015 18:57, )
- Ты fps не указал, а от этого все зависит. - Evgeny_CD(07.11.2015 14:18)
  - Так я не знаю сколько надо для такой задачи. Никаких распознаваний образов не планируется. - Mebius(07.11.2015 14:27)
    - Сжимать-то кто будет? Без сжатия 720x576x24 bit x 50 fps == 60МБайт/сек. Сеть даже гигабитная не потянет. И тот кто будет принимать тоже не потянет. Плюс софт для сжатия нужен. Если опенсоурс, то кроме x86 вариантов думается нет. - fk0(07.11.2015 14:34)
      - Я так понимаю, что как раз наличие или отсутствие сжатия видеопотока и влияет на выбор процессора. - =L.A.=(09.11.2015 11:16)
      - бит не 24 а 8. Всё-равно сжимать надо? - Mebius(07.11.2015 14:51)
        
        Это ширина шины 8 бит. И вряд ли у тебя цвет даже 16-битный -- артефакты квантования слишком заметны на градиентах. Сейчас везде 24-битный цвет типично (ну или хотя бы 18-битный). - fk0(07.11.2015 15:18)
        
        Изображение чёрно-белое. - Mebius(07.11.2015 15:40)
        
        Только у тебя 2 8битных отсчета на пиксель будет. Схема 4:4:2 называется. - Evgeny_CD(07.11.2015 14:54)
        
        Схемы 4:4:2 в природе не существует вовсе. Есть форматы ITU-R.656 - YCbCr 4:2:0, 4:2:2 и 4:4:4. USSR(446 знак., 07.11.2015 18:25, )
        
        Спасибо! Я ошибся в нотации. - Evgeny_CD(07.11.2015 18:32)
        
        Я тоже.. Читать: "в формате Байера". :) - USSR(07.11.2015 18:43, )
        
        Это ты не про то. Это про пониженное цветовое разрешение (после сжатия, когда цвет от яркости отделён). - fk0(07.11.2015 15:18)
        
        Я просто кратко описал выход типичного сенсора, без подробностей, для оценки объема трафика. Но у человека все вообще ЧБ будет. - Evgeny_CD(07.11.2015 16:41)
        
        Это не выход сенсора, это описание способа сжатия цветовой составляющей. Выход сенсора никакого отношения не имеет. - fk0(07.11.2015 16:44)
        
        Странно, надо в Aptina, OmniVision написать что их выход YUV422 (2 байта на пиксель) никакого отношения к сенсору не имеет. Только 24бит, только хардкор. - Ralex(08.11.2015 00:08)
        
        Там не выход с сенсора как есть, это ж очевидно. А какой-то процессинг. Ибо как понизить вертикальное разрешение по цвету можно? Нужно как минимум памяти на строку иметь. - fk0(08.11.2015 00:53)
    - Ты понимаешь, что 1fps и 30fps - это разные задачи? - Evgeny_CD(07.11.2015 14:33)
      - fps это кадров в секунду что-ли? тогда где-то 25-50. Полное ТЗ на работе, потому такие размытые данные. - Mebius(07.11.2015 14:49)
        
        fk0 верно заметил, что 50 fps без сжатия - это будет суровый поток данных :) а дальше все зависит от того, во что жать надо. Evgeny_CD(95 знак., 07.11.2015 14:53)
        
        Ок. Спасибо всем кто откликнулся. - Mebius(07.11.2015 14:57)
    - У меня на STM32F407 работает камера, Ralex(218 знак., 07.11.2015 14:31)
      - Аналогично, только без доп памяти. Картинка отдается по udp. - Lightelf(07.11.2015 20:09)

Схемы, платы, компоненты