2 Система обнаружения потерь в видеопотоках в GStreamer и уведомления администратора
🎯 Общая характеристика проекта
| Атрибут | Значение |
|---|
| Тип | Программный проект (учебный) |
| Максимальная оценка | 8,2 балла (учебный проект) |
| Описание | Исследование: анализ целостности видеопотока в GStreamer. Продукт: система, способная обнаруживать потери кадров, разрывы потока, артефакты и другие аномалии в реальном времени, с автоматической отправкой уведомлений администратору. |
| Цель продукта | Создание инструмента мониторинга качества видеопотока (QoE), который обеспечивает надёжность систем видеонаблюдения и трансляций за счёт своевременного обнаружения и оповещения о сбоях. |
| Целевая аудитория | Операторы СКУД, администраторы трансляций, ИТ-службы, службы эксплуатации, интеграторы, умный город, образовательные платформы. |
| Технологии (рекомендуемые) | GStreamer (Python/C), OpenCV, ONVIF, RTSP, FFmpeg, WebSocket, Flask/FastAPI, Prometheus и Grafana (опционально), Telegram/Email/SMS-уведомления, Docker, веб-интерфейс. |
📅 Поэтапные требования к проекту
📌 Этап 1: Выбор темы
Дата: 19.01.2026
Формат: Онлайн-форма
Документы: Форма
🔹 Требования к защите
- Подтверждён выбор темы 4-2.
- Сформирована команда (до 2 человек).
- Определены роли участников.
- Подтверждено понимание задачи: анализ видеопотока в GStreamer на предмет потерь и аномалий.
- Наличие доступа к ONVIF-камерам или RTSP-источникам.
| Критерий | Вес | Описание |
|---|
| Выбор темы | 1% | Формальное подтверждение выбора темы, формирования команды, распределения ролей и технической готовности. Оценка выставляется при условии своевременной подачи формы. |
📌 Этап 2: Представление проекта
Дата: 31.01.2026
Формат: Презентация
Документы: Слайды, ТЗ
🔹 Требования к защите
- Чётко сформулированы:
- Проблема: скрытые сбои в видеопотоках (потеря кадров, "зависания", артефакты), которые не видны при визуальном контроле, но приводят к утрате данных.
- Решение: система автоматического анализа потока в GStreamer с детекцией аномалий и уведомлением администратора.
- Целевая аудитория.
- Описаны технологии и архитектура системы.
- Представлен план реализации.
- Подтверждено согласование подхода с заказчиком.
| Критерий | Вес | Описание |
|---|
| Продукт | 25% | Постановка цели, видение законченного продукта: как работает система, где применяется (СКУД, трансляции, умный город) |
| Польза | 25% | Обоснование необходимости: повышение надёжности, снижение рисков, профилактика потери критичных данных, автоматизация мониторинга |
| Пользователь | 20% | Описание целевой аудитории внутри и вне МИЭМ, количественная оценка, рынки применения (безопасность, ИТ, транспорт) |
| Технологии | 20% | Обоснованный выбор стека: GStreamer (appsink, probes), OpenCV (анализ кадров), Python, Flask, Telegram-бот, логика детекции аномалий |
| Развитие | 10% | Перспективы развития: интеграция с Zabbix, Grafana, ИИ-анализ (например, классификация артефактов), коммерциализация, ВКР |
📌 Этап 3: PoC (Proof of Concept)
Дата: 21.02.2026
Формат: Демонстрация + видео + репозиторий
Документы: Git, видео
🔹 Требования к защите
- Экспериментально подтверждена техническая реализуемость:
- Построение GStreamer-пайплайна с получением RTSP-потока.
- Использование
appsink или probe для доступа к кадрам/метаданным.
- Обнаружение простых аномалий: отсутствие кадров (freeze), резкое падение FPS.
- Простейшее уведомление (вывод в консоль или лог).
- Демонстрация минимальной работоспособности.
- Видео (до 3 минут) с демонстрацией: нормальный поток → имитация сбоя → детекция → уведомление.
- Код выложен в репозиторий с README.
| Критерий | Вес | Описание |
|---|
| Техническая реализуемость | 60% | Подтверждение, что GStreamer позволяет анализировать поток в реальном времени и обнаруживать аномалии |
| Демонстрация | 20% | Наличие видео, показывающего: нормальную работу → имитацию потери кадров/зависания → срабатывание детектора |
| Код и документация | 20% | Наличие репозитория с рабочим кодом, README, инструкцией по запуску и описанием архитектуры PoC |
📌 Этап 4: Прототип
Дата: 16.03.2026
Формат: Демонстрация + отчет + репозиторий
Документы: Демо, отчет, git
🔹 Требования к защите
- Реализован прототип:
- Поддержка 1–2 RTSP-источников.
- Анализ: потеря кадров, freeze, артефакты (через сравнение кадров/энтропию).
- Уведомления: Telegram, email или лог-файл.
- Простейший веб-интерфейс с отображением статуса камер.
- Логирование событий.
- Демонстрация работы в реальном времени.
- Отчёт с описанием архитектуры, методов анализа, схемы пайплайнов.
| Критерий | Вес | Описание |
|---|
| Реализация функционала | 40% | Поддержка GStreamer-анализа, детекция аномалий, уведомления, веб-статус |
| Интеграция | 25% | Успешная интеграция GStreamer, OpenCV, системы уведомлений, веб-интерфейса |
| Демонстрация | 20% | Работающий демо-стенд, показ детекции разных типов сбоев |
| Документация | 15% | Наличие отчёта с описанием архитектуры, GStreamer-пайплайнов, алгоритмов анализа, API, инструкций по запуску |
📌 Этап 5: MVP (Minimal Viable Product)
Дата: 11.04.2026
Формат: Работающий продукт + отзыв + отчет + git
Документы: Отзыв, отчет, git
🔹 Требования к защите
- Продукт может быть запущен и использован без участия разработчика.
- Поддержка всех базовых функций:
- Настройка камер через веб-интерфейс (IP, логин/пароль, порт).
- Настраиваемые пороги детекции (например, "freeze > 3 сек").
- Уведомления через Telegram/email.
- Веб-интерфейс с картой камер: зелёный/жёлтый/красный статус.
- Журнал событий с временными метками.
- Автозапуск (systemd/Docker).
- Наличие документации пользователя и разработчика.
- Получен отзыв пользователя.
| Критерий | Вес | Описание |
|---|
| Продукт | 30% | Готовность продукта: отчуждаемость, выполнение базовых функций, работа в фоне |
| Документация разработчика | 20% | Наличие спецификации MVP/MUP, описание архитектуры, GStreamer-пайплайнов, API, алгоритмов, текущего результата |
| Запуск и работа | 30% | Продукт запускается без разработчика, не требует несвойственных действий от пользователя, работает в фоне |
| Документация пользователя | 20% | Полная инструкция по установке, настройке камер, порогов, уведомлений, интерпретации статусов и устранению неисправностей |
📌 Этап 6: MUP (Minimal Usable Product)
Дата: 16.05.2026
Формат: Асинхронная защита + консультация
Документы: Отзыв, отчет, git
🔹 Требования к защите
- Продукт внедрён в тестовую среду (например, в лаборатории).
- Пользователь самостоятельно использует весь функционал.
- Получен отзыв о реальном использовании.
- Документация дополнена на основе фидбэка.
- Созданы маркетинговые материалы.
| Критерий | Вес | Описание |
|---|
| Отзыв пользователя | 30% | Удобство интерфейса, точность детекции, своевременность уведомлений, ложные срабатывания, простота настройки |
| Функциональность | 30% | Полная реализация всех функций: настройка, анализ, уведомления, визуализация, автозапуск |
| Документация пользователя | 20% | Наличие полной, понятной документации с установкой, навигацией, сценариями использования и устранением неисправностей |
| Маркетинг | 20% | Наличие лендинга, продуктового ролика, раздатки или презентации, адаптированных под целевую аудиторию |
📌 Этап 7: Защита проекта
Дата: 06.06.2026 или 13.06.2026
Формат: Презентация + демо + отзывы
Документы: Слайды, демо, отзывы
🔹 Требования к защите
- Презентация пользовательского опыта.
- Демонстрация работы продукта (включая сценарии сбоев и уведомлений).
- Представление отзывов пользователей.
- Подача заявки на РИД.
- Ответы на вопросы.
| Критерий | Вес | Описание |
|---|
| Представление | 20% | Маркетинговый стиль, ясность, логичность, отсутствие научного стиля, фокус на пользе и кейсах |
| Маркетинг | 20% | Качество лендинга, ролика, раздатки — соответствие продуктовому жанру, наличие кейсов применения |
| Впечатления пользователей | 30% | Удобство, точность, своевременность, простота установки и использования, качество визуализации |
| Завершённость | 30% | Полная документация, функциональность, наличие дистрибутива (Docker, deb), ссылки на код, расширенный функционал (например, интеграция с Prometheus, Grafana, ИИ-фильтрация ложных срабатываний) |
Вложения