Поиск разработчика С++


Если вы владете 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р. Возможна некоторая обоснованная корректировка суммы в сторону её повышения. Оплата ТЗ и предоплата разработки оговаривается.
Интересующиеся — пишите мне по следующим контактам image image image

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

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

Комментариев нет:

Отправить комментарий

Всегда рад приятному общению…

Подписаться на: Комментарии к сообщению (Atom)