Ищем разработчика на С++

2012-10-05 в 11:34, admin, рубрики: directshow, SDK, windows, я пиарюсь, метки: directshow, SDK, windows

Ищем разработчика на С++

Если вы владете C++ и занимаетесь разработкой Directshow фильтров — добро пожаловать!

Всем добрый день!

IT компания, где я раньше работал дизайнером, ищет разработчика, который помог бы им в реализации одного из проектов.
Меня попросили разместить на хабре предложение о сотрудничестве. А также провести предварительный отбор кандидатов. Окончательный выбор проведёт уже компетентный специалист на собеседовании.

Суть работы сводится к следующему:
Необходимо разработать несколько Directshow-фильтров и/или WMF-фильтров на языке C++, а именно — сплиттер, детектор движения и виртуальный источник видео. На выходе от исполнителя требуется легко читаемый код, соответствующий некоторым требованиям.

Описание задачи
Разработка Directshow-фильтров и/или WMF-фильтров на языке C++.

Сплиттер

Сплиттер должен работать, как служба windows (windows service).
При запуске службы сплиттер должен читать настройки, сохранённые в реестре windows, а именно:
1. Перечень физических устройств, виртуализацию которых обеспечивает сплиттер, в виде аппаратных идентификаторов устройства (должен уметь работать в ситуации, когда в системе два и более одноимённых физических устройства).
2. Для каждого из устройств
  1. Тип исходящего сигнала (MediaType) из перечня предлагаемых устройством, а именно:
    1. Для устройств типа Video Capture Source:
      1. Разрешение
      2. Кодировка цвета
      3. Частота кадров
    2. Для устройств типа Audio Capture Source:
      1. Частота дискретизации
      2. Размер sample-ов
  2. Имя виртуального устройства, создаваемого сплиттером
  3. Идентификатор виртуального устройства, создаваемого сплиттером
Должно существовать отдельное приложение для редактирования настроек сплиттера. Оно же должно показывать список экземпляров виртуальных устройств, созданных в системе и позволять сохранять данные графов, в рамках которых эти устройства используются в формате GRF (microsoft graph editor).
Сплиттер должен уметь привязываться к физическим источникам типа Video Capture Source и Audio Capture Source, таким как USB web-камеры, порты Firewire, платы видео-захвата форматов SD SDI, HD SDI, S-Video, компонентный A/V, аудио-адаптер (линейный вход, микрофонный вход, цифровой вход, master-volume). Формат потока на выходе сплиттера должен совпадать с выбранным форматом на выходе физического устройства.
При запуске службы сплиттер должен регистрировать в операционной системе все виртуальные устройства в соответствии с настройками, но не создавать фильтры-экземпляры физических устройств.
При остановке службы сплиттер должен останавливать дочерние процессы и удалять регистрацию виртуальных устройств из операционной системы.
В случае аварийной остановки службы, при запуске, перед прочтением настроек, сплиттер должен найти в операционной системе все зарегистрированные им ранее виртуальные устройства и удалить их. Такая же функция должна быть доступна их приложения редактирования настроек.
Дочерние процессы должны регулярно мониторить жизнедеятельность главного процесса службы и завершаться при аварийной выгрузке службы.
В момент, когда приложение создаёт первый экземпляр виртуального устройства, служба сплиттера должна порождать дочерний процесс, изолирующий в себе работу с физическим устройством. Дочерний процесс должен инициализировать физическое устройство и подключаться к нему.
Для передачи данных между процессом, изолирующим физическое устройство, и процессом клиентского приложения должен использоваться механизм Named Shared Memory (in-memory file) или аналогичный по производительности механизм.
Должен присутствовать механизм, позволяющий получить сигнал о том, что клиентское приложение не справляется с потоком данных, толкаемых физическим устройством.
Все точки входа всех процессов должны быть снабжены системой перехвата исключений с записью сведений о них в файловый журнал. Должна быть реализована функция обработки необработанных исключений с записью сведений о них в файловый журнал.
Для работы клиентского приложения не должны требоваться административные права. Процесс не должен требовать системных ресурсов (жёсткого диска и реестра) за рамками доступных обычному пользователю (системная группа users) за исключением прав, необходимых для использования Named Shared Memory (in-memory file).

Детектор движения

Детектор движения должен быть разделён на два компонента:
1. SDK-библиотека (COM) реализующая «простой» интерфейс и собственно сам алгоритм обнаружения движения как разницы между поступающими кадрами. Результат эта библиотека должна выставлять «дёргая» callback-функции в отдельном от основной работы потоке.
  1. Функция, получающая управление при обнаружении движения
    1. Исходный кадр
    2. Кадр, снабженный отладочными данными (сетка, зоны и пр.)
    3. Данные о движении (зона, интенсивность и пр.)
  2. Функция, получающая управление после обработки каждого кадра
    1. Исходный кадр
    2. Кадр, снабженный отладочными данными (сетка, зоны и пр.)
2. Directshow фильтр, интегрирующий в себе работу библиотеки. Его задача – получать кадры из directshow графа, толкать их в экземпляр детектора, получать от неё сигналы об обнаружении движения и, возможно, толкать эти сигналы в сеть (UDP). На выходе фильтр должен иметь две выходные точки (pins):
  1. Немодифицированное видео
  2. Видео, снабженное отладочной информацией (сетка, зоны и пр.)
Необходимо иметь возможность подключать детектор движения к источникам разного разрешения и формата видео-потока (VideoInfoHeader, VideoInfoHeader2). Видео-поток не компрессированный, то есть все кадры полные (опорные), но сами кадры могут быть компрессированными. Желательно, чтобы фильтр детектора движения не требовал предварительной конвертации кодировки цвета в RGB.
Желательно, чтобы событие об обнаружении движения доставлялось не в виде строки, а в виде структуры с необходимыми полями. Формат – XML. Желательно, чтобы по событию об обнаружении движения, можно было получить контрольный кадр (bitmap), исходный и/или с отладочной информацией.
Должна быть возможность использовать несколько экземпляров детектора движения в одном системном процессе и запускать несколько таких процессов на одном компьютере одновременно. Должна быть возможность указать разные настройки для разных экземпляров детектора движения (в виде строки, содержащей XML-документ, а не пути к файлу).
Детектор движения не должен рассчитывать на наличие административных прав у системного процесса, в рамках которого он запущен. Не должен требовать системных ресурсов (жёсткого диска и реестра) за рамками доступных обычному пользователю (системная группа users).

Виртуальный источник видео

Суть виртуального источника в том, чтобы была возможность использовать выход фильтра детектора движения в отдельном приложении и работать с этим выходом, как с отдельным видео источником.
Виртуальный источник видео это directshow фильтр. На входе этого фильтра два пина, видео и аудио. После того, как экземпляр этого фильтра создан и подключен, должна быть возможность вызвать метод экземпляра этого фильтра, который регистрирует в системе видеоистоник с выходами, соответствующими подключенным входам фильтра. Должна быть возможность создавать экземпляры виртуального видеоисточника вне зависимости от того, запущен граф, поставляющий данные для видео источника, или нет. В случае, когда граф-поставщик не запущен, виртуальный источник должен толкать в свой граф «заглушечные» кадры.
После того, как граф-поставщик запущен, должна быть возможность «привязать» экземпляр фильтра-поставщика виртуального источника к виртуальному устройству-источнику по имени, указанному в заказе на регистрацию виртуального источника.
Обмен данными между процессами, содержащими граф-источник и граф-приёмник, должна быть организована через shared memory.

Требования к исполнителю

Знание английского языка на уровне чтения MSDN. На собеседовании будет предложено прочитать статью и своими словами изложить суть.
Опыт разработки коммерческих Directshow-фильтров и/или WMF-фильтров. Мы попросим продемонстрировать разработанный фильтр и привести пример куска кода из него.
Нам нужно, чтобы над нашим проектом работал, по меньшей мере, 1 человек практически постоянно, а именно: Уделял нашему проекту не менее 80% своего рабочего времени.

Требования к хранению и оформлению кода
Нам потребуется выяснить и согласовать с исполнителем следующие пункты:

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

Комментарии
Мы потребуем подробного комментирования кода.

Класс:
- Ответственность класса/типа.
- Переменные/константы уровня класса/типа.
Метод/свойство:
- Ответственность метода.
- Входящие параметры.
- Возвращаемое значение.
Логический блок:
- Любое ветвление (if, for, while, switch и пр.).
- Все переменные/константы.

Постановка задачи
Мы в письменной форме даём общее описание задачи. Исполнитель формализует требования, запрашивая дополнительную информацию устно или письменно, по своему усмотрению.
Далее исполнитель формирует письменное ТЗ. Изначально форму и уровень детализации выбирает исполнитель. Впоследствии мы можем потребовать увеличения детализации всего ТЗ или отдельной части.

Мониторинг процесса реализации

Прототипирование и проектирование:
Для некоторых задач мы можем потребовать проектирования и/или реализации прототипов. Наиболее типичные виды проектных диаграмм:
- Реализуемых прецедентов (usecase)
- Поточный сценарий (activity)
- Последовательность (sequence)
Реализация:
- Промежуточные версии кода должны оформляться по стандартам.
- Промежуточные версии кода должны становиться доступны для просмотра не реже, чем каждые 3 дня
- В случае необходимости приостановки работ по проекту, исполнитель должен своевременно уведомить нас об этом.
Поддержка:
Исполнитель должен вести журнал замечаний/ошибок, журнал изменений. Записи в журнале изменений должны содержать связи с журналом замечаний/ошибок в доступной для просмотра форме.

Приёмка результатов
Обработка и оценка результатов будет производиться по мере разработки, а не по завершении.

Сроки
Ориентировочные сроки выполнения работ — 2,5-3 месяца.

Оплата
Сумма оплаты за весь объём выполненной работы — 200 000р. Возможна некоторая обоснованная корректировка суммы в сторону её повышения.
Оплата ТЗ и предоплата разработки оговаривается.

Интересующиеся — пишите мне по следующим контактам