Статьи

Совместное использование различных средств межпроцессного взаимодействия отлично поддерживается в Python с помощью стандартных библиотек, таких как Threading и Multiprocessing. Однако, данные средства предназначены для организации различных механизмов IPC между родственными процессами, то есть такими, которые порождаются из общего предка и наследуют объекты IPC. Однако, часто возникает задача использования средств IPC между неродственными процессами, которые запускаются независимо. В этом случае применяются именованные объекты IPC (POSIX или SysV), которые позволяют неродственным процессам получить объект IPC по уникальному имени. Такое взаимодействие не поддерживается стандартными инструментами Python.

В Python 3.8 появилась библиотека multiprocessing.shared_memory, которая представляет собой первый шаг к реализации средств IPC, предназначенных для связи неродственных процессов. Данная статья как раз была задумана как проба этой библиотеки. Однако, все пошло не так. На 29 ноября 2019 года реализация разделяемой памяти в этой библиотеке некорректна – объект разделяемой памяти удаляется даже в том случае, если вы просто хотите прекратить использовать объект в одном из процессов, не удаляя его. Несмотря на наличие двух вызовов close() и unlink(), независимо от их вызова или невызова, объект удаляется когда любой из процессов-пользователей объекта завершает свою работу.

Задача, описываемая в данной статье часто встречается в решениях интеллектуальной видеоаналитики. В общем случае, пользователю требуется предоставить доступ к фрагменту, в котором содержатся некоторые события. Фрагмент – это набор из одного или более небольших видеофайлов, которые содержат как сам инцидент, так и связанную с ним историю и развитие ситуации.

Такую задачу удобно решать с помощью формирования циклического буфера из видеофрагментов, разбитых по небольшим файлам, например, по 30 секунд. В этом случае, когда приложение обнаруживает, что в некоторых из них содержатся важные сигналы, оно копирует файлы, которые формируют окружение сигнала из данного циклического буфера в постоянное хранилище. Буфер является циклическим, поскольку старые файлы, созданные давно, удаляются с диска (например, после прошествия 10 минут).

В данной статье мы рассмотрим реализацию такого циклического буфера, который подключается к основному пайплайну обработки видео и обслуживает создание и удаление видеофайлов. Для решения задачи будем использовать OpenCV, Python, LZ4 и ZeroMQ. Для простоты считаем, что FPS видеофайлов соответствует FPS потока, то есть все видеофреймы из основного потока пишутся в файлы. В реальных реализациях может иметь место удаление избыточных фреймов из потока, изменение разрешения и т.п.

Детекция движения – актуальная проблема в решении задач видеоаналитики. Часто она осуществляется за счет сравнения изменяемой части изображения с неизменяемой, что позволяет выделить фон и движущийся объект. Простой детектор движения можно легко найти на просторах интернета, например, на сайте Pyimagesearch.com. Это примитивный детектор, который не обрабатывает:

• изменчивость окружающей среды;
• шум видеопотока, который может возникать в связи с различными факторами.

В статье мы рассмотрим реализацию подвинутого детектора на Python, который подходит для использования на зашумленных потоках с высоким FPS. Реализация будет опираться на библиотеку OpenCV для работы с изображениями и видео, библиотеку NumPy, используемую для проведения операций над матричным представлением фреймов, и на Numba, которая применяется для ускорения части операций, которые выполняются в Python.

Шум – это природное или техническое явление, наблюдаемое в видеопотоке, которое не формирует полезного информационного фона, вызывая ложные срабатывания детектора. Пример шума:

• блики солнечного света;
• отражения предметов от прозрачных стеклянных поверхностей;
• колебания мелких объектов в кадре – листва, трава, пыль;
• дрожжание камеры за счет внешних мелких вибраций;
• мерцание осветительных приборов дневного света;
• дефекты изображения за счет низкой светосилы, качества матрицы камеры;
• рассыпание картинки из-за сетевых помех или наводок при использовании аналоговых камер.

Вариантов шума много, результат один – микроизменения в изображении, которые возникают даже в отсутствии явного движения в кадре. Базовые алгоритмы не обрабатывают данные эффекты. Алгоритм, рассматриваемый в данной статье позволяет успешно справляться с последствиями шума. Пример шума можно видеть на следующем фрагменте видео с частотой кадров 60 FPS:

OpenCV – популярный фреймворк, который широко используется при разработке продуктов для интеллектуальной видеоаналитики. Такие решения опираются как на классические алгоритмы компьютерного зрения, например, алгоритм определения оптического потока, так и на алгоритмы, использующие современный инструментарий искусственного интеллекта, в частности, нейронные сети.

Большая часть алгоритмов является ресурсоемкой, что, в зависимости от целей обработки, может требовать большого объема вычислительных ресурсов, для обработки даже одного видеопотока в режиме реального времени. Под ресурсами подразумеваются как вычислительные ядра CPU, так и GPU, а так же другие аппаратные ускорители.

Камера или другой источник поставляет видеопоток с определенным количеством кадров в секунду (FPS, Frames Per Second), которые должны быть обработаны аналитической платформой. Каждый кадр видео занимает существенный объем памяти, например, для кадра разрешения 4K глубиной цвета 24 бит, массив NumPy ndarray будет занимать 24 MB в RAM, а за 1 секунду буферизации при FPS равным 30, данных кадров накопится на 729 MB. При низкой производительности цепочки обработки можно столкнуться с ситуацией отказа из-за переполнения RAM, дискового пространства или потери кадров. Таким образом, цепочка обработки должна быть достаточно производительной, чтобы успеть обработать все кадры.

Apache Spark – довольно популярная среда для масштабируемой обработки данных. Для многих компаний это сердце систем обработки больших данных. Spark в равной степени удобен для вычислений на одиночной рабочей станции, одиночном сервере или высокопроизводительном кластере с тысячами узлов. Apache Spark имеет очень сложную архитектуру и, в то же время, простую модель разработки, что особенно важно на ранних этапах изучения продукта. Наиболее привлекательной особенностью Spark является то, что, когда вычисления хорошо спроектированы, Spark использует всю доступную вычислительную мощность. Инженеры не тратят время на организацию распараллеливания, многопоточности, многопроцессорной обработки и прочего – вся магия происходит внутри Spark.