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

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

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

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

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

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

Сплиттер

1. Сплиттер должен работать, как служба windows (windows service).
2. При запуске службы сплиттер должен читать настройки, сохранённые в реестре windows, а именно:
   1. Перечень физических устройств, виртуализацию которых обеспечивает сплиттер, в виде аппаратных идентификаторов устройства (должен уметь работать в ситуации, когда в системе два и более одноимённых физических устройства).
   2. Для каждого из устройств
      1. Тип исходящего сигнала (MediaType) из перечня предлагаемых устройством, а именно:
         1. Для устройств типа Video Capture Source:
            1. Разрешение
            2. Кодировка цвета
            3. Частота кадров

         2. Для устройств типа Audio Capture Source:
            1. Частота дискретизации
            2. Размер sample-ов

      2. Имя виртуального устройства, создаваемого сплиттером
      3. Идентификатор виртуального устройства, создаваемого сплиттером

3. Должно существовать отдельное приложение для редактирования настроек сплиттера. Оно же должно показывать список экземпляров виртуальных устройств, созданных в системе и позволять сохранять данные графов, в рамках которых эти устройства используются в формате GRF (microsoft graph editor).
4. Сплиттер должен уметь привязываться к физическим источникам типа Video Capture Source и Audio Capture Source, таким как USB web-камеры, порты Firewire, платы видео-захвата форматов SD SDI, HD SDI, S-Video, компонентный A/V, аудио-адаптер (линейный вход, микрофонный вход, цифровой вход, master-volume). Формат потока на выходе сплиттера должен совпадать с выбранным форматом на выходе физического устройства.
5. При запуске службы сплиттер должен регистрировать в операционной системе все виртуальные устройства в соответствии с настройками, но не создавать фильтры-экземпляры физических устройств.
6. При остановке службы сплиттер должен останавливать дочерние процессы и удалять регистрацию виртуальных устройств из операционной системы.
7. В случае аварийной остановки службы, при запуске, перед прочтением настроек, сплиттер должен найти в операционной системе все зарегистрированные им ранее виртуальные устройства и удалить их. Такая же функция должна быть доступна их приложения редактирования настроек.
8. Дочерние процессы должны регулярно мониторить жизнедеятельность главного процесса службы и завершаться при аварийной выгрузке службы.
9. В момент, когда приложение создаёт первый экземпляр виртуального устройства, служба сплиттера должна порождать дочерний процесс, изолирующий в себе работу с физическим устройством. Дочерний процесс должен инициализировать физическое устройство и подключаться к нему.
10. Для передачи данных между процессом, изолирующим физическое устройство, и процессом клиентского приложения должен использоваться механизм Named Shared Memory (in-memory file) или аналогичный по производительности механизм.
11. Должен присутствовать механизм, позволяющий получить сигнал о том, что клиентское приложение не справляется с потоком данных, толкаемых физическим устройством.
12. Все точки входа всех процессов должны быть снабжены системой перехвата исключений с записью сведений о них в файловый журнал. Должна быть реализована функция обработки необработанных исключений с записью сведений о них в файловый журнал.
13. Для работы клиентского приложения не должны требоваться административные права. Процесс не должен требовать системных ресурсов (жёсткого диска и реестра) за рамками доступных обычному пользователю (системная группа users) за исключением прав, необходимых для использования Named Shared Memory (in-memory file).

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

1. Детектор движения должен быть разделён на два компонента:
   1. SDK-библиотека (COM) реализующая «простой» интерфейс и собственно сам алгоритм обнаружения движения как разницы между поступающими кадрами. Результат эта библиотека должна выставлять «дёргая» callback-функции в отдельном от основной работы потоке.
      1. Функция, получающая управление при обнаружении движения
         1. Исходный кадр
         2. Кадр, снабженный отладочными данными (сетка, зоны и пр.)
         3. Данные о движении (зона, интенсивность и пр.)

      2. Функция, получающая управление после обработки каждого кадра
         1. Исходный кадр
         2. Кадр, снабженный отладочными данными (сетка, зоны и пр.)

   2. Directshow фильтр, интегрирующий в себе работу библиотеки. Его задача – получать кадры из directshow графа, толкать их в экземпляр детектора, получать от неё сигналы об обнаружении движения и, возможно, толкать эти сигналы в сеть (UDP). На выходе фильтр должен иметь две выходные точки (pins):
      1. Немодифицированное видео
      2. Видео, снабженное отладочной информацией (сетка, зоны и пр.)

2. Необходимо иметь возможность подключать детектор движения к источникам разного разрешения и формата видео-потока (VideoInfoHeader, VideoInfoHeader2). Видео-поток не компрессированный, то есть все кадры полные (опорные), но сами кадры могут быть компрессированными. Желательно, чтобы фильтр детектора движения не требовал предварительной конвертации кодировки цвета в RGB.
3. Желательно, чтобы событие об обнаружении движения доставлялось не в виде строки, а в виде структуры с необходимыми полями. Формат – XML. Желательно, чтобы по событию об обнаружении движения, можно было получить контрольный кадр (bitmap), исходный и/или с отладочной информацией.
4. Должна быть возможность использовать несколько экземпляров детектора движения в одном системном процессе и запускать несколько таких процессов на одном компьютере одновременно. Должна быть возможность указать разные настройки для разных экземпляров детектора движения (в виде строки, содержащей XML-документ, а не пути к файлу).
5. Детектор движения не должен рассчитывать на наличие административных прав у системного процесса, в рамках которого он запущен. Не должен требовать системных ресурсов (жёсткого диска и реестра) за рамками доступных обычному пользователю (системная группа users).

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

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

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

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

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

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

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

• Класс:
  • Ответственность класса/типа.
  • Переменные/константы уровня класса/типа.

• Метод/свойство:
  • Ответственность метода.
  • Входящие параметры.
  • Возвращаемое значение.

• Логический блок:
  • Любое ветвление (if, for, while, switch и пр.).
  • Все переменные/константы.

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

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

• Прототипирование и проектирование:
  Для некоторых задач мы можем потребовать проектирования и/или реализации прототипов. Наиболее типичные виды проектных диаграмм:
  • Реализуемых прецедентов (usecase)
  • Поточный сценарий (activity)
  • Последовательность (sequence)

• Реализация:
  • Промежуточные версии кода должны оформляться по стандартам.
  • Промежуточные версии кода должны становиться доступны для просмотра не реже, чем каждые 3 дня
  • В случае необходимости приостановки работ по проекту, исполнитель должен своевременно уведомить нас об этом.

• Поддержка:
  Исполнитель должен вести журнал замечаний/ошибок, журнал изменений. Записи в журнале изменений должны содержать связи с журналом замечаний/ошибок в доступной для просмотра форме.

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

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

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

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

или в личные сообщения.

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

PS Распространение этого поста приветствуется!

Автор: Compazavr